RE: NAND R/W support
Thanks, Greg, Alan for your replies. I will have to ponder on this a bit. To answer your question, Alan, the MCU is an IMXRT 1060. > There is an FTL, but it will not work with either NAND or LittleFS. FTL is a > "Flash Translation Layer" and there can be many different types of FTLs. Looking at the code, it seems that hooking in another FTL would basically be to provide a file that can provide the ftl_initialize() function and the filesystem block_operations struct? I'm not sure if an external FTL will fit with the NuttX MTD (my interpretation is that ftl.c uses an MTD instance to talk to the NAND (via a driver)). Looking closer, the "MTD" looks to be the drivers talking directly to the memory devices, in in nuttx/drivers/mtd. BR Thomas -Original Message- From: Alan Carvalho de Assis Sent: den 25 september 2020 16:48 To: dev@nuttx.apache.org Subject: Re: NAND R/W support Sorry for the typo: will be use a bad block -> will not use a bad block On 9/25/20, Alan Carvalho de Assis wrote: > Hi Thomas, > > According to drivers/mtd/README.txt the NAND support is only partial > because there is not a FS to handle it correctly. > > Normally for NAND you will need to scan the NAND to update the bad > block table during the boot (could be on NuttX or in a bootloader) to > guarantee the FS will be use a bad block (remember that NAND normally > comes with bad blocks from factory). Note that the nand_devscan() > function at mtd_nand.c just try to retrieve this information, it > doesn't update the Bad Block Table. > > Also your MCU needs to have some support in hardware to communicate > with NAND (parallel model), for SPI NAND it is not necessary. It > appears that currently only SAMA5 has support to it. > > Of course, this should be a very useful thing to have on NuttX because > as application become more complex we need more space for them. > > What MCU are you planing to use? > > BR, > > Alan > > On 9/25/20, Thomas Axelsson wrote: >> Hi, >> >> I'm trying to understand what level of NAND memory support currently >> exists in NuttX. The intention is to read and write files on the NAND >> memory. >> >> I have found CONFIG_MTD_NAND and there seems to be a NAND driver for >> the >> SAMA5 built-in NAND. All other MTD drivers appear to be for NOR? The >> intention is to use a Winbond W25N NAND memory, but I'm assuming the >> SAMA5 >> driver will be closer to what I need than the W25QxxxJV NOR driver >> (NAND vs NOR)? >> >> Regarding a file system, the NuttX About page mentions "NXFFS. The >> tiny NuttX wear-leveling FLASH file system." and there is also the >> option to enable littlefs. >> >> https://github.com/ARMmbed/littlefs/issues/11 indicates that one >> wants an FTL below littlefs. Going by the existence of >> CONFIG_FTL_READAHEAD and CONFIG_WRITEBUFFER, it seems that the FTL is >> integrated in MTD in NuttX? >> >> Is SMART File System (CONFIG_FS_SMARTFS) related to the "Really Tiny >> (SMART) Flash" (CONFIG_MTD_SMART) option? The latter says that it is >> only usable for really small memories. >> >> 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/> >> >> >
NAND R/W support
Hi, I'm trying to understand what level of NAND memory support currently exists in NuttX. The intention is to read and write files on the NAND memory. I have found CONFIG_MTD_NAND and there seems to be a NAND driver for the SAMA5 built-in NAND. All other MTD drivers appear to be for NOR? The intention is to use a Winbond W25N NAND memory, but I'm assuming the SAMA5 driver will be closer to what I need than the W25QxxxJV NOR driver (NAND vs NOR)? Regarding a file system, the NuttX About page mentions "NXFFS. The tiny NuttX wear-leveling FLASH file system." and there is also the option to enable littlefs. https://github.com/ARMmbed/littlefs/issues/11 indicates that one wants an FTL below littlefs. Going by the existence of CONFIG_FTL_READAHEAD and CONFIG_WRITEBUFFER, it seems that the FTL is integrated in MTD in NuttX? Is SMART File System (CONFIG_FS_SMARTFS) related to the "Really Tiny (SMART) Flash" (CONFIG_MTD_SMART) option? The latter says that it is only usable for really small memories. 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/>
RE: i.MX RT 1060 ADC
Hi,
I have now created a PR for a simple IMXRT ADC driver. (
https://github.com/apache/incubator-nuttx/pull/1868 )
The names of register bit values for ADC_CFG:ADSTS do not match between IMXRT
1020 and 1050/1060.
This PR changes them to match for 1050/1060, but I guess it should be split
into two files - or possibly have an ifdef for the chip? Please provide advise
on this issue.
https://github.com/apache/incubator-nuttx/pull/1868/files#diff-d732b4fa83e7f3fbf6ac34c1203cef60
BR
Thomas
-Original Message-
From: Thomas Axelsson
Sent: den 16 september 2020 09:05
To: dev@nuttx.apache.org
Subject: RE: i.MX RT 1060 ADC
Thank you, David,
It's good to have a working example.
Regarding the existing ADC code, I realized that I had only diffed over the
various LPCxxx drivers. My current starting point is the LPC driver with things
picked from the STM32. The LPC driver is simpler (STM32 handles many variants),
while the STM32 driver has a clearer multi-ADC and multi-channel structure
(although I just realized that mask in the LPC driver might be the channel
selector). Just writing this here in case someone wants to point me in another
direction.
BR
Thomas
-Original Message-
From: David Sidrane
Sent: den 15 september 2020 12:15
To: dev@nuttx.apache.org
Subject: RE: i.MX RT 1060 ADC
Hi Thomas,
If you structure the driver like any of the other ADC drivers in tree you
should be able to reference px4_arch_adc_init and px4_arch_adc_sample
from
https://github.com/PX4/Firmware/blob/master/platforms/nuttx/src/px4/nxp/im
xrt/adc/adc.cpp to get the required logic.
To fill in the meat, but you will have to do it in nuttx style using the
{get|set}reg32 calls.
David
-Original Message-
From: Thomas Axelsson [mailto:thomas.axels...@actia.se]
Sent: Tuesday, September 15, 2020 2:55 AM
To: dev@nuttx.apache.org
Subject: i.MX RT 1060 ADC
Hi,
I'm looking into using the ADC on IMXRT 1060. I have found imxrt_adc.h and some
examples in nuttx-apps using /dev/adcXX. However, it seems that the actual
functionality is not yet implemented for IMXRT.
So I'm looking into implementing this driver, based on e.g. lpc17_40_adc.c
(diffing all *_adc.c files turned up almost no differences). I tried grepping
for some register names to see if the IP block is already implemented for
another chip, but without luck.
I'm sending this e-mail to see if someone else is already working on the same
thing. I did see that imxrt_adc.h has gotten some updates.
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/>
RE: i.MX RT 1060 ADC
Thank you, David,
It's good to have a working example.
Regarding the existing ADC code, I realized that I had only diffed over the
various LPCxxx drivers. My current starting point is the LPC driver with things
picked from the STM32. The LPC driver is simpler (STM32 handles many variants),
while the STM32 driver has a clearer multi-ADC and multi-channel structure
(although I just realized that mask in the LPC driver might be the channel
selector). Just writing this here in case someone wants to point me in another
direction.
BR
Thomas
-Original Message-
From: David Sidrane
Sent: den 15 september 2020 12:15
To: dev@nuttx.apache.org
Subject: RE: i.MX RT 1060 ADC
Hi Thomas,
If you structure the driver like any of the other ADC drivers in tree you
should be able to reference px4_arch_adc_init and px4_arch_adc_sample
from
https://github.com/PX4/Firmware/blob/master/platforms/nuttx/src/px4/nxp/im
xrt/adc/adc.cpp to get the required logic.
To fill in the meat, but you will have to do it in nuttx style using the
{get|set}reg32 calls.
David
-Original Message-
From: Thomas Axelsson [mailto:thomas.axels...@actia.se]
Sent: Tuesday, September 15, 2020 2:55 AM
To: dev@nuttx.apache.org
Subject: i.MX RT 1060 ADC
Hi,
I'm looking into using the ADC on IMXRT 1060. I have found imxrt_adc.h and some
examples in nuttx-apps using /dev/adcXX. However, it seems that the actual
functionality is not yet implemented for IMXRT.
So I'm looking into implementing this driver, based on e.g. lpc17_40_adc.c
(diffing all *_adc.c files turned up almost no differences). I tried grepping
for some register names to see if the IP block is already implemented for
another chip, but without luck.
I'm sending this e-mail to see if someone else is already working on the same
thing. I did see that imxrt_adc.h has gotten some updates.
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/>
i.MX RT 1060 ADC
Hi, I'm looking into using the ADC on IMXRT 1060. I have found imxrt_adc.h and some examples in nuttx-apps using /dev/adcXX. However, it seems that the actual functionality is not yet implemented for IMXRT. So I'm looking into implementing this driver, based on e.g. lpc17_40_adc.c (diffing all *_adc.c files turned up almost no differences). I tried grepping for some register names to see if the IP block is already implemented for another chip, but without luck. I'm sending this e-mail to see if someone else is already working on the same thing. I did see that imxrt_adc.h has gotten some updates. 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/>
RE: NuttX on the IMXRT1060-EVK
Hi Erdem,
I'm not actively developing using IMXRT at the moment, but one thing that lead
to problems with debugging was NuttX entering the ARM low-power mode Wait For
Interrupt.
The quick fix is to comment out the following line in
arch/arm/src/imxrt/imxrt_idle.c:
asm("WFI");
Maybe it will help you.
I don't have the user guides at hand, but I suspect J46 and J47, that you
mention, are the jumpers for bypassing the on-board debugger - so you have
overcome that hurdle.
BR
Thomas
-Original Message-
From: Erdem MEYDANLI
Sent: den 19 maj 2020 14:41
To: dev@nuttx.apache.org
Subject: NuttX on the IMXRT1060-EVK
Hello,
I've been playing with the IMX1060-EVK board for some time. I wanted to test it
by running NuttX on it with networking support enabled.
./tools/configure.sh -l imxrt1060-evk/netnsh
The configurations below have been enabled, referring to the explanation in the
README file.
CONFIG_IMXRT_ENET_PHYINIT=y
CONFIG_IMXRT_GPIO1_0_15_IRQ=y
CONFIG_IMXRT_GPIO_IRQ=y
CONFIG_NETDEV_IOCTL=y
CONFIG_NETDEV_PHY_IOCTL=y
CONFIG_NSH_NETINIT_MONITOR=y
CONFIG_NSH_NETINIT_RETRYMSEC=2000
CONFIG_NSH_NETINIT_SIGNO=18
CONFIG_NSH_NETINIT_THREAD=y
CONFIG_NSH_NETINIT_THREAD_PRIORITY=80
CONFIG_NSH_NETINIT_THREAD_STACKSIZE=1568
In addition to the items above, I also changed the IPv4 address.
CONFIG_NETINIT_IPADDR=0xc0a8b2fa
CONFIG_NETINIT_DRIPADDR=0xc0a8b201
Then, I built the code. Flashed it (via J-Link). The NSH console appears and
works well. Here is the output of 'ifconfig':
eth0Link encap:Ethernet HWaddr 00:e0:de:ad:be:ef at DOWN
inet addr:192.168.178.250 DRaddr:192.168.178.1 Mask:255.255.255.0
inet6 addr: fc00::2/112
inet6 DRaddr: fc00::1/112
RX: Received Fragment Errors
IPv4 IPv6 ARP Dropped
TX: Queued Sent Errors Timeouts
Total Errors:
The addresses seem fine, but the eth0 interface is DOWN. To bring up eth0, I
use ifup eth0. But this time, the NSH becomes irresponsive, and I have to
perform hard-reset.
I doubted that there was a problem with the hardware. Therefore, I also tried
with the examples (i.e., lwip_httpsrv_freertos) of the MCUXpresso IDE, and
everything worked as expected. I can do step by step debugging with the help of
J-Link and the IDE.
Why I also mentioned J-Link? Because I, too, would like to debug via J-Link to
be able to understand the issue. However, when I try to debug NuttX via J-Link,
the adapter gets disconnected, an I get some weird errors. This is another
story though... (Optimizations suppressed. Debug symbols enabled.)
I spent too much time on it but still haven't come to a solution. Any hints and
tips from the experts on IMXRT platform would be appreciated.
(Here is my setup: Ubuntu 18, Segger J-Link Base, the board is powered through
USB. J46 and J47 are removed. SW7 OFF-OFF-ON-OFF -> QSPI flash is
enabled.)
Best regards,
Erdem
RE: IMXRT 1060 USB Device (copy of LPC43/LPC31 driver) - Set-up buffer problems
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
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
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
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<mailto:thomas.axels...@actia.se> Web: www.actia.se<http://www.actia.se/> [cid:image001.png@01D5E7E9.029B3520]
