RE: IMXRT 1060 USB Device (copy of LPC43/LPC31 driver) - Set-up buffer problems

2020-02-21 Thread Thomas Axelsson 
Hi David,

I'm a bit new to the Github/upstreaming flow, so please forgive any mistakes.

I have created a draft PR here: 
https://github.com/apache/incubator-nuttx/pull/347

I have correctly enumerated the board as a USB serial port and as an RNDIS 
device. I figured that D-Cache without write-through would be the toughest case.

TODO:
Extract PLL setup code.
Style.
License/header stanza.

BR
Thomas

-Original Message-
From: David Sidrane  
Sent: den 20 februari 2020 15:51
To: dev@nuttx.apache.org
Subject: RE: IMXRT 1060 USB Device (copy of LPC43/LPC31 driver) - Set-up buffer 
problems

DTCM and D-cache are different

You will need to add the cache clean and invalidate in the write/read functions 
to support D-cache. If you open a PR on Git hub, I will have a look at it.

For comparison an STM32F7/H7 have these functions in the correct palces.

David

-Original Message-
From: Thomas Axelsson [mailto:thomas.axels...@actia.se]
Sent: Thursday, February 20, 2020 6:12 AM
To: dev@nuttx.apache.org
Subject: RE: IMXRT 1060 USB Device (copy of LPC43/LPC31 driver) - Set-up buffer 
problems

That seems to be it! Thanks!

I was under the impression that not having DTCM enabled would mean no caching, 
but after finding and turning off D-Cache in menuconfig, my board enumerates as 
a USB device. Now to fix it for real.

BR
Thomas

-Original Message-
From: spudaneco 
Sent: den 20 februari 2020 13:41
To: dev@nuttx.apache.org
Subject: RE: IMXRT 1060 USB Device (copy of LPC43/LPC31 driver) - Set-up buffer 
problems

This sounds like a data cache problem.  One difference between the i.MXRT and 
the LPC43 is that it has a data cache.  So you must flush the cache before 
starting any DMA operation and invalidate the cache before reading any 
DMAdata.GregSent from Samsung tablet.
 Original message From: Thomas Axelsson 
 Date: 2/20/20  5:24 AM  (GMT-06:00) To:
dev@nuttx.apache.org Subject: IMXRT 1060 USB Device (copy of LPC43/LPC31
driver) - Set-up buffer problems

Hi,

I’m trying to get the IMXRT1060-EVK working as a USB device using the USB
OTG1 peripheral.

By comparing reference manuals, I’ve figured that the USB peripheral seems to 
be identical to the one found in NXP LPC43xx (and LPC31xx). As such, I’ve 
copied lpc43_usb0dev.c, replaced all the registers with the IMX RT registers 
and tweaked the initialization. I have made some ugly copies (throwing in the 
PLL init in the driver) that will need to be cleaned up, once the driver is 
working. Also, it is currently full of small hacks, trying to get it to work. I 
have included  the almost unmodified, copied
LPC43 driver, in the patch as well, for comparison.

The driver is almost working, but I’ve stumbled on a problem with reading the 
Set-up buffer in the EP0 Queue Head (g_qh[0].setup) (struct that resides in 
RAM).

What I’ve found is that

The host sends Get Descriptor and the device responds correctly. (Green line in 
USB trace image)The host sends Set Address (not visible in Linux usbmon
trace!) but the device reads the old Get Descriptor packet from g_qh[0].setup 
and responds as if Get Descriptor  was sent. (Blue line and following red text 
in USB trace image)

When playing around with the code I have sometimes found .setup to be all 
zeroes, when the host does  Get Descriptor, Reset, . Meaning that 
the zeroes written by imxrt_usbreset() has not been overwritten by  the USB 
controller.

I have also at one time managed to read .setup repeatedly, after the 
ENDPTSETUPSTAT has been set, until the value changed and gotten the Set 
Address. However, I’m having a hard time to reproduce it.

So it seems that the data in g_qh[0].setup is only filled correctly for the 
first setup package and not updated again, or sometimes updated with a large 
delay.

I have tried sprinkling some volatile, in case the imxrt_readsetup() code would 
skip the memory access, without success.


Any ideas on what might be going wrong or where to dig?

I have included the current state of the driver (imxrt_usbdev.c) and a
patch+defconfig if someone wants to play on an IMXRT EVK. The patch was
generated against NuttX master branch.


Here is a snippet from the console output on the device, showing how the device 
reacts to Get Descriptor followed by Set Address.
Please note that ENTRY and EP0SETUP is doubly traced since I’ve duplicated the 
trace lines in the code.

Interrupt decode8: IMXRT_TRACEINTID_EP0SETUP0001
Interrupt decode8: IMXRT_TRACEINTID_EP0SETUP0001
Interrupt decode   18: IMXRT_TRACEINTID_GETSETDESC  
Interrupt decode5: IMXRT_TRACEINTID_DISPATCH ...
Interrupt entry 1: ENTRY
Interrupt entry 1: ENTRY0081
Interrupt decode8: IMXRT_TRACEINTID_EP0SETUP0001
Interrupt decode8: IMXRT_TRACEINTID_EP0SETUP0001
Interrupt decode

RE: IMXRT 1060 USB Device (copy of LPC43/LPC31 driver) - Set-up buffer problems

2020-02-20 Thread David Sidrane 
DTCM and D-cache are different

You will need to add the cache clean and invalidate in the write/read
functions to support D-cache. If you open a PR on Git hub, I will have a
look at it.

For comparison an STM32F7/H7 have these functions in the correct palces.

David

-Original Message-
From: Thomas Axelsson [mailto:thomas.axels...@actia.se]
Sent: Thursday, February 20, 2020 6:12 AM
To: dev@nuttx.apache.org
Subject: RE: IMXRT 1060 USB Device (copy of LPC43/LPC31 driver) - Set-up
buffer problems

That seems to be it! Thanks!

I was under the impression that not having DTCM enabled would mean no
caching, but after finding and turning off D-Cache in menuconfig, my board
enumerates as a USB device. Now to fix it for real.

BR
Thomas

-Original Message-
From: spudaneco 
Sent: den 20 februari 2020 13:41
To: dev@nuttx.apache.org
Subject: RE: IMXRT 1060 USB Device (copy of LPC43/LPC31 driver) - Set-up
buffer problems

This sounds like a data cache problem.  One difference between the i.MXRT
and the LPC43 is that it has a data cache.  So you must flush the cache
before starting any DMA operation and invalidate the cache before reading
any DMAdata.GregSent from Samsung tablet.
 Original message From: Thomas Axelsson
 Date: 2/20/20  5:24 AM  (GMT-06:00) To:
dev@nuttx.apache.org Subject: IMXRT 1060 USB Device (copy of LPC43/LPC31
driver) - Set-up buffer problems

Hi,

I’m trying to get the IMXRT1060-EVK working as a USB device using the USB
OTG1 peripheral.

By comparing reference manuals, I’ve figured that the USB peripheral seems
to be identical to the one found in NXP LPC43xx (and LPC31xx). As such, I’ve
copied lpc43_usb0dev.c, replaced all the registers with the IMX RT
registers and tweaked the initialization. I have made some ugly copies
(throwing in the PLL init in the driver) that will need to be cleaned up,
once the driver is working. Also, it is currently full of small hacks,
trying to get it to work. I have included  the almost unmodified, copied
LPC43 driver, in the patch as well, for comparison.

The driver is almost working, but I’ve stumbled on a problem with reading
the Set-up buffer in the EP0 Queue Head (g_qh[0].setup) (struct that resides
in RAM).

What I’ve found is that

The host sends Get Descriptor and the device responds correctly. (Green line
in USB trace image)The host sends Set Address (not visible in Linux usbmon
trace!) but the device reads the old Get Descriptor packet from
g_qh[0].setup and responds as if Get Descriptor  was sent. (Blue line and
following red text in USB trace image)

When playing around with the code I have sometimes found .setup to be all
zeroes, when the host does  Get Descriptor, Reset, . Meaning that
the zeroes written by imxrt_usbreset() has not been overwritten by  the USB
controller.

I have also at one time managed to read .setup repeatedly, after the
ENDPTSETUPSTAT has been set, until the value changed and gotten the Set
Address. However, I’m having a hard time to reproduce it.

So it seems that the data in g_qh[0].setup is only filled correctly for the
first setup package and not updated again, or sometimes updated with a large
delay.

I have tried sprinkling some volatile, in case the imxrt_readsetup() code
would skip the memory access, without success.


Any ideas on what might be going wrong or where to dig?

I have included the current state of the driver (imxrt_usbdev.c) and a
patch+defconfig if someone wants to play on an IMXRT EVK. The patch was
generated against NuttX master branch.


Here is a snippet from the console output on the device, showing how the
device reacts to Get Descriptor followed by Set Address.
Please note that ENTRY and EP0SETUP is doubly traced since I’ve duplicated
the trace lines in the code.

Interrupt decode8: IMXRT_TRACEINTID_EP0SETUP0001
Interrupt decode8: IMXRT_TRACEINTID_EP0SETUP0001
Interrupt decode   18: IMXRT_TRACEINTID_GETSETDESC  
Interrupt decode5: IMXRT_TRACEINTID_DISPATCH ...
Interrupt entry 1: ENTRY
Interrupt entry 1: ENTRY0081
Interrupt decode8: IMXRT_TRACEINTID_EP0SETUP0001
Interrupt decode8: IMXRT_TRACEINTID_EP0SETUP0001
Interrupt decode   18: IMXRT_TRACEINTID_GETSETDESC   <<---
This should have been SETADDRESS!
Interrupt decode5: IMXRT_TRACEINTID_DISPATCH


Testing the patch:
git checkout 90839b41f92aa01f1b0b24d18ee62e6efa4077d5  # or current master
apply the patch tools/configure.sh imxrt1060-evk:nsh cp downloads/defconfig
defconfig make olddefconfig make

Flash board
Connect USBOTG1 (connector J9) to host.
Press  in nsh to see the usbtrace (I did not manage to use the USB
Monitor with NSH).

(I've found that I have to toggle the boot config to  on SW7 and reset,
to be able to flash with J-Link after starting this NuttX conf

RE: IMXRT 1060 USB Device (copy of LPC43/LPC31 driver) - Set-up buffer problems

2020-02-20 Thread Thomas Axelsson 
That seems to be it! Thanks!

I was under the impression that not having DTCM enabled would mean no caching, 
but after finding and turning off D-Cache in menuconfig, my board enumerates as 
a USB device. Now to fix it for real.

BR
Thomas

-Original Message-
From: spudaneco  
Sent: den 20 februari 2020 13:41
To: dev@nuttx.apache.org
Subject: RE: IMXRT 1060 USB Device (copy of LPC43/LPC31 driver) - Set-up buffer 
problems

This sounds like a data cache problem.  One difference between the i.MXRT and 
the LPC43 is that it has a data cache.  So you must flush the cache before 
starting any DMA operation and invalidate the cache before reading any 
DMAdata.GregSent from Samsung tablet.
 Original message From: Thomas Axelsson 
 Date: 2/20/20  5:24 AM  (GMT-06:00) To: 
dev@nuttx.apache.org Subject: IMXRT 1060 USB Device (copy of LPC43/LPC31 
driver) - Set-up buffer problems 

Hi,
 
I’m trying to get the IMXRT1060-EVK working as a USB device using the USB OTG1 
peripheral.
 
By comparing reference manuals, I’ve figured that the USB peripheral seems to 
be identical to the one found in NXP LPC43xx (and LPC31xx). As such, I’ve 
copied lpc43_usb0dev.c, replaced all the registers with the IMX RT  registers 
and tweaked the initialization. I have made some ugly copies (throwing in the 
PLL init in the driver) that will need to be cleaned up, once the driver is 
working. Also, it is currently full of small hacks, trying to get it to work. I 
have included  the almost unmodified, copied LPC43 driver, in the patch as 
well, for comparison.
 
The driver is almost working, but I’ve stumbled on a problem with reading the 
Set-up buffer in the EP0 Queue Head (g_qh[0].setup) (struct that resides in 
RAM).
 
What I’ve found is that

The host sends Get Descriptor and the device responds correctly. (Green line in 
USB trace image)The host sends Set Address (not visible in Linux usbmon trace!) 
but the device reads the old Get Descriptor packet from g_qh[0].setup and 
responds as if Get Descriptor  was sent. (Blue line and following red text in 
USB trace image)
 
When playing around with the code I have sometimes found .setup to be all 
zeroes, when the host does  Get Descriptor, Reset, . Meaning that 
the zeroes written by imxrt_usbreset() has not been overwritten by  the USB 
controller.
 
I have also at one time managed to read .setup repeatedly, after the 
ENDPTSETUPSTAT has been set, until the value changed and gotten the Set 
Address. However, I’m having a hard time to reproduce it.
 
So it seems that the data in g_qh[0].setup is only filled correctly for the 
first setup package and not updated again, or sometimes updated with a large 
delay.
 
I have tried sprinkling some volatile, in case the imxrt_readsetup() code would 
skip the memory access, without success.
 
 
Any ideas on what might be going wrong or where to dig?
 
I have included the current state of the driver (imxrt_usbdev.c) and a 
patch+defconfig if someone wants to play on an IMXRT EVK. The patch was 
generated against NuttX master branch.
 
 
Here is a snippet from the console output on the device, showing how the device 
reacts to Get Descriptor followed by Set Address.
Please note that ENTRY and EP0SETUP is doubly traced since I’ve duplicated the 
trace lines in the code.
 
Interrupt decode    8: IMXRT_TRACEINTID_EP0SETUP    0001 Interrupt 
decode    8: IMXRT_TRACEINTID_EP0SETUP    0001 Interrupt decode   
18: IMXRT_TRACEINTID_GETSETDESC   Interrupt decode    5: 
IMXRT_TRACEINTID_DISPATCH     ...
Interrupt entry 1: ENTRY     Interrupt 
entry 1: ENTRY    0081 Interrupt decode    
8: IMXRT_TRACEINTID_EP0SETUP    0001 Interrupt decode    8: 
IMXRT_TRACEINTID_EP0SETUP    0001 Interrupt decode   18: 
IMXRT_TRACEINTID_GETSETDESC   <<--- This should have been 
SETADDRESS!
Interrupt decode    5: IMXRT_TRACEINTID_DISPATCH    
 
 
Testing the patch:
git checkout 90839b41f92aa01f1b0b24d18ee62e6efa4077d5  # or current master 
apply the patch tools/configure.sh imxrt1060-evk:nsh cp downloads/defconfig 
defconfig make olddefconfig make
 
Flash board
Connect USBOTG1 (connector J9) to host.
Press  in nsh to see the usbtrace (I did not manage to use the USB 
Monitor with NSH).
 
(I've found that I have to toggle the boot config to  on SW7 and reset, to 
be able to flash with J-Link after starting this NuttX config. It does not 
happen in my dev code, so I'm ignoring that
 issue.)
 
 
Thomas Axelsson
SW Developer
ACTIA Nordic AB
(part of ACTIA Group)
 
Mail:
thomas.axels...@actia.se

Web:
www.actia.se

 

 

RE: IMXRT 1060 USB Device (copy of LPC43/LPC31 driver) - Set-up buffer problems

2020-02-20 Thread spudaneco 
This sounds like a data cache problem.  One difference between the i.MXRT and 
the LPC43 is that it has a data cache.  So you must flush the cache before 
starting any DMA operation and invalidate the cache before reading any 
DMAdata.GregSent from Samsung tablet.
 Original message From: Thomas Axelsson 
 Date: 2/20/20  5:24 AM  (GMT-06:00) To: 
dev@nuttx.apache.org Subject: IMXRT 1060 USB Device (copy of LPC43/LPC31 
driver) - Set-up buffer problems 

Hi,
 
I’m trying to get the IMXRT1060-EVK working as a USB device using the USB OTG1 
peripheral.
 
By comparing reference manuals, I’ve figured that the USB peripheral seems to 
be identical to the one found in NXP LPC43xx (and LPC31xx). As such, I’ve 
copied lpc43_usb0dev.c, replaced all the registers with the IMX RT
 registers and tweaked the initialization. I have made some ugly copies 
(throwing in the PLL init in the driver) that will need to be cleaned up, once 
the driver is working. Also, it is currently full of small hacks, trying to get 
it to work. I have included
 the almost unmodified, copied LPC43 driver, in the patch as well, for 
comparison.
 
The driver is almost working, but I’ve stumbled on a problem with reading the 
Set-up buffer in the EP0 Queue Head (g_qh[0].setup) (struct that resides in 
RAM).
 
What I’ve found is that

The host sends Get Descriptor and the device responds correctly. (Green line in 
USB trace image)The host sends Set Address (not visible in Linux usbmon trace!) 
but the device reads the old Get Descriptor packet from g_qh[0].setup and 
responds as if Get Descriptor
 was sent. (Blue line and following red text in USB trace image)
 
When playing around with the code I have sometimes found .setup to be all 
zeroes, when the host does  Get Descriptor, Reset, . Meaning that 
the zeroes written by imxrt_usbreset() has not been overwritten by
 the USB controller.
 
I have also at one time managed to read .setup repeatedly, after the 
ENDPTSETUPSTAT has been set, until the value changed and gotten the Set 
Address. However, I’m having a hard time to reproduce it.
 
So it seems that the data in g_qh[0].setup is only filled correctly for the 
first setup package and not updated again, or sometimes updated with a large 
delay.
 
I have tried sprinkling some volatile, in case the imxrt_readsetup() code would 
skip the memory access, without success.
 
 
Any ideas on what might be going wrong or where to dig?
 
I have included the current state of the driver (imxrt_usbdev.c) and a 
patch+defconfig if someone wants to play on an IMXRT EVK. The patch was 
generated against NuttX master branch.
 
 
Here is a snippet from the console output on the device, showing how the device 
reacts to Get Descriptor followed by Set Address.
Please note that ENTRY and EP0SETUP is doubly traced since I’ve duplicated the 
trace lines in the code.
 
Interrupt decode    8: IMXRT_TRACEINTID_EP0SETUP    0001
Interrupt decode    8: IMXRT_TRACEINTID_EP0SETUP    0001
Interrupt decode   18: IMXRT_TRACEINTID_GETSETDESC  
Interrupt decode    5: IMXRT_TRACEINTID_DISPATCH    
...
Interrupt entry 1: ENTRY    
Interrupt entry 1: ENTRY    0081
Interrupt decode    8: IMXRT_TRACEINTID_EP0SETUP    0001
Interrupt decode    8: IMXRT_TRACEINTID_EP0SETUP    0001
Interrupt decode   18: IMXRT_TRACEINTID_GETSETDESC   <<--- This 
should have been SETADDRESS!
Interrupt decode    5: IMXRT_TRACEINTID_DISPATCH    
 
 
Testing the patch:
git checkout 90839b41f92aa01f1b0b24d18ee62e6efa4077d5  # or current master
apply the patch
tools/configure.sh imxrt1060-evk:nsh
cp downloads/defconfig defconfig
make olddefconfig
make
 
Flash board
Connect USBOTG1 (connector J9) to host.
Press  in nsh to see the usbtrace (I did not manage to use the USB 
Monitor with NSH).
 
(I've found that I have to toggle the boot config to  on SW7 and reset, to 
be able to flash with J-Link after starting this NuttX config. It does not 
happen in my dev code, so I'm ignoring that
 issue.)
 
 
Thomas Axelsson
SW Developer
ACTIA Nordic AB
(part of ACTIA Group)
 
Mail:
thomas.axels...@actia.se

Web:
www.actia.se

 

 

RE: IMXRT 1060 USB Device (copy of LPC43/LPC31 driver) - Set-up buffer problems

2020-02-20 Thread Thomas Axelsson 
Excuse the spam. I have added a .txt extension to defconfig. I'm hoping it will 
be included now.

From: Thomas Axelsson 
Sent: den 20 februari 2020 12:27
To: dev@nuttx.apache.org
Subject: RE: IMXRT 1060 USB Device (copy of LPC43/LPC31 driver) - Set-up buffer 
problems

Adding missing defconfig

From: Thomas Axelsson 
mailto:thomas.axels...@actia.se>>
Sent: den 20 februari 2020 12:24
To: dev@nuttx.apache.org<mailto:dev@nuttx.apache.org>
Subject: IMXRT 1060 USB Device (copy of LPC43/LPC31 driver) - Set-up buffer 
problems

Hi,

I'm trying to get the IMXRT1060-EVK working as a USB device using the USB OTG1 
peripheral.

By comparing reference manuals, I've figured that the USB peripheral seems to 
be identical to the one found in NXP LPC43xx (and LPC31xx). As such, I've 
copied lpc43_usb0dev.c, replaced all the registers with the IMX RT registers 
and tweaked the initialization. I have made some ugly copies (throwing in the 
PLL init in the driver) that will need to be cleaned up, once the driver is 
working. Also, it is currently full of small hacks, trying to get it to work. I 
have included the almost unmodified, copied LPC43 driver, in the patch as well, 
for comparison.

The driver is almost working, but I've stumbled on a problem with reading the 
Set-up buffer in the EP0 Queue Head (g_qh[0].setup) (struct that resides in 
RAM).

What I've found is that

  1.  The host sends Get Descriptor and the device responds correctly. (Green 
line in USB trace image)
  2.  The host sends Set Address (not visible in Linux usbmon trace!) but the 
device reads the old Get Descriptor packet from g_qh[0].setup and responds as 
if Get Descriptor was sent. (Blue line and following red text in USB trace 
image)

When playing around with the code I have sometimes found .setup to be all 
zeroes, when the host does  Get Descriptor, Reset, . Meaning that 
the zeroes written by imxrt_usbreset() has not been overwritten by the USB 
controller.

I have also at one time managed to read .setup repeatedly, after the 
ENDPTSETUPSTAT has been set, until the value changed and gotten the Set 
Address. However, I'm having a hard time to reproduce it.

So it seems that the data in g_qh[0].setup is only filled correctly for the 
first setup package and not updated again, or sometimes updated with a large 
delay.

I have tried sprinkling some volatile, in case the imxrt_readsetup() code would 
skip the memory access, without success.


Any ideas on what might be going wrong or where to dig?

I have included the current state of the driver (imxrt_usbdev.c) and a 
patch+defconfig if someone wants to play on an IMXRT EVK. The patch was 
generated against NuttX master branch.


Here is a snippet from the console output on the device, showing how the device 
reacts to Get Descriptor followed by Set Address.
Please note that ENTRY and EP0SETUP is doubly traced since I've duplicated the 
trace lines in the code.

Interrupt decode8: IMXRT_TRACEINTID_EP0SETUP0001
Interrupt decode8: IMXRT_TRACEINTID_EP0SETUP0001
Interrupt decode   18: IMXRT_TRACEINTID_GETSETDESC  
Interrupt decode5: IMXRT_TRACEINTID_DISPATCH
...
Interrupt entry 1: ENTRY
Interrupt entry 1: ENTRY0081
Interrupt decode8: IMXRT_TRACEINTID_EP0SETUP0001
Interrupt decode8: IMXRT_TRACEINTID_EP0SETUP0001
Interrupt decode   18: IMXRT_TRACEINTID_GETSETDESC   <<--- This 
should have been SETADDRESS!
Interrupt decode5: IMXRT_TRACEINTID_DISPATCH


Testing the patch:
git checkout 90839b41f92aa01f1b0b24d18ee62e6efa4077d5  # or current master
apply the patch

tools/configure.sh imxrt1060-evk:nsh

cp downloads/defconfig defconfig

make olddefconfig

make



Flash board

Connect USBOTG1 (connector J9) to host.

Press  in nsh to see the usbtrace (I did not manage to use the USB 
Monitor with NSH).



(I've found that I have to toggle the boot config to  on SW7 and reset, to 
be able to flash with J-Link after starting this NuttX config. It does not 
happen in my dev code, so I'm ignoring that issue.)



Thomas Axelsson
SW Developer
ACTIA Nordic AB (part of ACTIA Group)

Mail: thomas.axels...@actia.se<mailto:thomas.axels...@actia.se>
Web: www.actia.se<http://www.actia.se/>

[cid:image001.png@01D5E7E9.3B6B6D70]

#
# This file is autogenerated: PLEASE DO NOT EDIT IT.
#
# You can use "make menuconfig" to make any modifications to the installed 
.config file.
# You can then do "make savedefconfig" to generate a new defconfig file that 
includes your
# modifications.
#
CONFIG_ARCH="arm"
CONFIG_ARCH_BOARD="imxrt1060-evk"
CONFIG_ARCH_BOARD_IMXRT1060_EVK=y
CONFIG_ARCH_CHIP="imxrt"
CONFIG_ARCH_CHIP_IMXRT=y
CONFIG_ARC

RE: IMXRT 1060 USB Device (copy of LPC43/LPC31 driver) - Set-up buffer problems

2020-02-20 Thread Thomas Axelsson 
Adding missing defconfig

From: Thomas Axelsson 
Sent: den 20 februari 2020 12:24
To: dev@nuttx.apache.org
Subject: IMXRT 1060 USB Device (copy of LPC43/LPC31 driver) - Set-up buffer 
problems

Hi,

I'm trying to get the IMXRT1060-EVK working as a USB device using the USB OTG1 
peripheral.

By comparing reference manuals, I've figured that the USB peripheral seems to 
be identical to the one found in NXP LPC43xx (and LPC31xx). As such, I've 
copied lpc43_usb0dev.c, replaced all the registers with the IMX RT registers 
and tweaked the initialization. I have made some ugly copies (throwing in the 
PLL init in the driver) that will need to be cleaned up, once the driver is 
working. Also, it is currently full of small hacks, trying to get it to work. I 
have included the almost unmodified, copied LPC43 driver, in the patch as well, 
for comparison.

The driver is almost working, but I've stumbled on a problem with reading the 
Set-up buffer in the EP0 Queue Head (g_qh[0].setup) (struct that resides in 
RAM).

What I've found is that

  1.  The host sends Get Descriptor and the device responds correctly. (Green 
line in USB trace image)
  2.  The host sends Set Address (not visible in Linux usbmon trace!) but the 
device reads the old Get Descriptor packet from g_qh[0].setup and responds as 
if Get Descriptor was sent. (Blue line and following red text in USB trace 
image)

When playing around with the code I have sometimes found .setup to be all 
zeroes, when the host does  Get Descriptor, Reset, . Meaning that 
the zeroes written by imxrt_usbreset() has not been overwritten by the USB 
controller.

I have also at one time managed to read .setup repeatedly, after the 
ENDPTSETUPSTAT has been set, until the value changed and gotten the Set 
Address. However, I'm having a hard time to reproduce it.

So it seems that the data in g_qh[0].setup is only filled correctly for the 
first setup package and not updated again, or sometimes updated with a large 
delay.

I have tried sprinkling some volatile, in case the imxrt_readsetup() code would 
skip the memory access, without success.


Any ideas on what might be going wrong or where to dig?

I have included the current state of the driver (imxrt_usbdev.c) and a 
patch+defconfig if someone wants to play on an IMXRT EVK. The patch was 
generated against NuttX master branch.


Here is a snippet from the console output on the device, showing how the device 
reacts to Get Descriptor followed by Set Address.
Please note that ENTRY and EP0SETUP is doubly traced since I've duplicated the 
trace lines in the code.

Interrupt decode8: IMXRT_TRACEINTID_EP0SETUP0001
Interrupt decode8: IMXRT_TRACEINTID_EP0SETUP0001
Interrupt decode   18: IMXRT_TRACEINTID_GETSETDESC  
Interrupt decode5: IMXRT_TRACEINTID_DISPATCH
...
Interrupt entry 1: ENTRY
Interrupt entry 1: ENTRY0081
Interrupt decode8: IMXRT_TRACEINTID_EP0SETUP0001
Interrupt decode8: IMXRT_TRACEINTID_EP0SETUP0001
Interrupt decode   18: IMXRT_TRACEINTID_GETSETDESC   <<--- This 
should have been SETADDRESS!
Interrupt decode5: IMXRT_TRACEINTID_DISPATCH


Testing the patch:
git checkout 90839b41f92aa01f1b0b24d18ee62e6efa4077d5  # or current master
apply the patch

tools/configure.sh imxrt1060-evk:nsh

cp downloads/defconfig defconfig

make olddefconfig

make



Flash board

Connect USBOTG1 (connector J9) to host.

Press  in nsh to see the usbtrace (I did not manage to use the USB 
Monitor with NSH).



(I've found that I have to toggle the boot config to  on SW7 and reset, to 
be able to flash with J-Link after starting this NuttX config. It does not 
happen in my dev code, so I'm ignoring that issue.)



Thomas Axelsson
SW Developer
ACTIA Nordic AB (part of ACTIA Group)

Mail: thomas.axels...@actia.se
Web: www.actia.se

[cid:image001.png@01D5E7E9.029B3520]