USB device as MSC - Atmel SAME70 board

[[e-mail] [nuttx]]

Hello,
I'm using Nuttx version 7.17 for a project that needs the atmel same70 board to act as a mass storage device.
am using memory card which mounts correctly to /dev/mmcsd0. i used the menuconfig to configure the nuttx to
1- use the USBHS peripheral
2- i enabled the use of D-Cache write through
3- in USB High Speed Device Controller driver (DCD) options i only modified the Pre-allocate DMA transfer descriptors to 32 as mentioned in README doc and enabled the EP7 DMA errata workaround
4- in the USB Device Driver Support i chose to Enable high and full speed as msc use bulk transfer type
5- Enabled DMA methods and Board DMA Allocation Hooks
6- finally i enabled the USB Mass storage class device and increased the Bulk IN and OUT request size to 512
then configured the MSC Nuttx-Shell Commands (msconn and msdis)
i also added a file sam_usbmsc.c in /nuttx/configs/same70-xplained/src/ with a function do nothing called board_usbmsc_initialize() because the the memory card has been already initialized by the system.


The Problem is:
when i type the command msconn to nsh the windows detect the usb and HANG FOR LONG TIME a couple of minutes configured it as mass storage device then HANG again then configure it as Disk then HANG again for a longer period to open the memory card in explorer window the whole process takes up to 15 minutes maybe more to open the memory card and show its files
when i checked the events tab from the disk properties in the device manager of the windows, i saw that the windows keeps staring the device the configure then delete it !.
so what is the solution for this problem?


Note i tried to configure the usb as a CDC/ACM and it works that the windows configured it and gave it a COM to communicate through.

[[e-mail] [nuttx]]

My suspicion would be the HSMCI driver. Have you tested that separately. Before you do msconn, you should be able to mount it and read and write files from it.


You might try enabling CONFIG_DEBUG_FS to see if any errors are coming from the SD card.

[[e-mail] [nuttx]]

Hello Spudarnia,

Actually i have tested the HSMCI driver and am able to perform mount read write umount to the card, so the card is working properly using the SDIO
The Problem is the LONG period the system takes to open the Board as a disk to make me able to read and write the files stored on it, i think it is a problem in the MSC driver as the USB worked and configured properly as a CDC/ACM, But i can't find where is the problem or the source of this hang.


thank you.

[[e-mail] [nuttx]]

Additionally when i type the command PS in the nsh it gives this output


PID PRI POLICY TYPE NPX STATE EVENT SIGMASK STACK COMMAND
0 0 FIFO Kthread Ready 00000000 0 Idle Task
1 224 FIFO Kthread Waiting Signal 00000000 2028 hpwork
2 100 FIFO Task Running 00000000 4076 init
4 128 FIFO Kthread Waiting Semaphore 00000000 2028 scsid


the SCSI thread appears to be waiting fir a semaphore every time i print the tasks statues!?

[[e-mail] [nuttx]]

The long delays typically have nothing to do with USB (especially since CDC/ACM is working normally). With MSC it normally occurs because the host PC is reading garbage from the disk and retries numerous times.

[[e-mail] [nuttx]]

Well, Normal delays would be in seconds not minutes up to 10 minutes to just open the disk. and after opening it takes along time to copy into or delete from it.
Also there is another thing that i found while searching in the readme of version 7.17


- USB MSC Device Class: Add locks when removing request from queue. From Wolfgang Reissnegger. - USB MSC Device Class: Fix reversed logic on waiting for SCSI thread start. The scsi thread was waiting for the wrong condition. However, this was masked by the fact that the code creating the scsi thread was also holding usbmsc_scsi_lock(priv) while initializing data, hence this lock synchronized the scsi thread start with init completion. From Wolfgang Reissnegger.

https://sourceforge.net/projects/nuttx/files/nuttx/nuttx-7.17/ https://sourceforge.net/projects/nuttx/files/nuttx/nuttx-7.17/

that is what i think is happening in my case the thread is waiting for event that occur every long period !
so how overcome that since i already have been using the 7.17 version.

[[e-mail] [nuttx]]

No, if it is reading garbage from the disk, then normal delays will be minutes.

[[e-mail] [nuttx]]

Okay, I will format the SD Card as FAT32 and try again Thanks for your help

[[e-mail] [nuttx]]

I formatted the SD card and the system gives me the same behavior .. it hangs for long periods what do you think about the SCSID thread that waits for a semaphore ?

[Alan Carvalho de Assis [e-mail] [nuttx]]

Enable the DEBUG then you could gather more information.

Also you can use other device as mass storage for tests. I have used
SPI NOR Flash with USB Mass Storage but I think it could be possible
to create a RAM Disk formatted as FAT and use it as USB MSD.

BR,

Alan

Post by ***@yahoo.com [nuttx]
I formatted the SD card and the system gives me the same behavior .. it
hangs for long periods what do you think about the SCSID thread that waits
for a semaphore ?

[[e-mail] [nuttx]]

Hello Alan,
I have read the NOR Flash topic in your blog, it is great work. I will use a RAM formatted with FAT instead of the SD CARD to check if it is a Card Problem or it is really the SCSI thread in the MSC driver that hang the connection and i will let you know the results

Thank You

[[e-mail] [nuttx]]

Hello Alan,

I have tried as you recommended to use the ram disk as the media for the MSC USB but it is giving the same behavior !!


I traced it in the usbmsc_scsi.c i found that the waiting is in the function usbmsc_scsi_wait at the step where it waits for a SCSI event to be signalled to be more specific at this line :
ret = sem_wait(&priv->thwaitsem);



I don't know how to solve it, could you help PLEASE.

[Alan Carvalho de Assis [e-mail] [nuttx]]

Hi Ebny,

Maybe other people with a SAME70 board could help you, I don't have this board.

Did you try to use other computer host to do your tests? Try it using
other host as well and other OS. It is always a good idea to test in
other condition, because it could be something specific to your host
computer (improvable, but possible).

If you have a STM32F4Discovery board you could try compare the logic
inside usbmsc_scsi.c to see what is happening differently.

I think Atmel SAME70 is very well supported by NuttX because Atmel
contracted Mr. Greg to port NuttX to this microcontroller. The STM32
is very well supported as well because there is more people using it
than any other microcontroller arch (AFAIK).

BR,

Alan

Post by ***@yahoo.com [nuttx]
Hello Alan,
I have tried as you recommended to use the ram disk as the media for the
MSC USB but it is giving the same behavior !!
I traced it in the usbmsc_scsi.c i found that the waiting is in the
function usbmsc_scsi_wait at the step where it waits for a SCSI event to be
ret = sem_wait(&priv->thwaitsem);
I don't know how to solve it, could you help PLEASE.

[[e-mail] [nuttx]]

There has been a recent change the the USB MSC device side driver.

commit 88539a7497e5c4880edffa0df2501a537ab1dd86
Author: Wolfgang Reißnegger <***@jupiterfoundation.org>
Date: Fri Nov 18 16:57:24 2016 -0800
USBMSC: Fix length of mode6 sense reply packet.

It might be worth backing that out as a test so assure that nothing was broken. Other than that, I don't see any significant changes that should effect the behavior of the driver. Still going back to an older version and seeing it works might be helpful.

I case you haven't noticed, you are getting a lot of help. If you want someone to dedicate engineering time to work on your hardware you will need to contract someone.

Northshore Design Group and Offcode Ltd both do a lot of NuttX contracting. Contact information is here: http://www.nuttx.org/doku.php?id=links#commercial_sites

Alan himself does contracted work too.

[[e-mail] [nuttx]]

Along with the change Greg mentioned there is also a change in the way the SAM3/4 code handles a stall resume as the USB endpoint on the SAM3/4 wasn't reset properly:

https://bitbucket.org/nuttx/nuttx/commits/c7ef82c546636daa4cc1b831019afb5ecec69f4e https://bitbucket.org/nuttx/nuttx/commits/c7ef82c546636daa4cc1b831019afb5ecec69f4e

There's an equivalent code section in the SAMv7 code, arch/arm/src/samv7/sam_usbdevhs.c, line 4030:

/* Reset the endpoint */

regval = sam_getreg(SAM_USBHS_DEVEPT);
regval |= USBHS_DEVEPT_EPRST(epno);
sam_putreg(regval, SAM_USBHS_DEVEPT);

regval &= ~USBHS_DEVEPT_EPRST(epno);
sam_putreg(regval, SAM_USBHS_DEVEPT);

It's worth a try to add a short delay between those two register writes and see if that fixes the problem. If you have an USB analyzer you can first confirm that you get an out of sequence Data Toggle bit in the case of the hang which indicates that the endpoint is not being properly reset when the stall is cleared.

Wolfgang

[[e-mail] [nuttx]]

find configs -name defconfig | xargs grep USBMSC=y

configs/spark/nsh/defconfig:CONFIG_USBMSC=y
configs/spark/usbmsc/defconfig:CONFIG_USBMSC=y
configs/spark/usbmsc/defconfig:CONFIG_SYSTEM_USBMSC=y
configs/spark/composite/defconfig:CONFIG_USBMSC=y
configs/teensy-2.0/usbmsc/defconfig:CONFIG_USBMSC=y
configs/teensy-2.0/usbmsc/defconfig:CONFIG_SYSTEM_USBMSC=y
configs/sama5d3x-ek/demo/defconfig:CONFIG_USBMSC=y
configs/sama5d3x-ek/demo/defconfig:CONFIG_SYSTEM_USBMSC=y
configs/hymini-stm32v/nsh2/defconfig:CONFIG_USBMSC=y
configs/hymini-stm32v/nsh2/defconfig:CONFIG_SYSTEM_USBMSC=y
configs/hymini-stm32v/usbmsc/defconfig:CONFIG_USBMSC=y
configs/hymini-stm32v/usbmsc/defconfig:CONFIG_SYSTEM_USBMSC=y
configs/pic32mx7mmb/nsh/defconfig:CONFIG_USBMSC=y
configs/pic32mx7mmb/nsh/defconfig:CONFIG_SYSTEM_USBMSC=y
configs/olimex-lpc1766stk/usbmsc/defconfig:CONFIG_USBMSC=y
configs/olimex-lpc1766stk/usbmsc/defconfig:CONFIG_SYSTEM_USBMSC=y
configs/fire-stm32v2/nsh/defconfig:CONFIG_USBMSC=y
configs/fire-stm32v2/nsh/defconfig:CONFIG_SYSTEM_USBMSC=y
configs/olimexino-stm32/composite/defconfig:CONFIG_USBMSC=y
configs/mcu123-lpc214x/usbmsc/defconfig:CONFIG_USBMSC=y
configs/mcu123-lpc214x/usbmsc/defconfig:CONFIG_SYSTEM_USBMSC=y
configs/mcu123-lpc214x/composite/defconfig:CONFIG_USBMSC=y
configs/stm3210e-eval/nsh2/defconfig:CONFIG_USBMSC=y
configs/stm3210e-eval/nsh2/defconfig:CONFIG_SYSTEM_USBMSC=y
configs/stm3210e-eval/usbmsc/defconfig:CONFIG_USBMSC=y
configs/stm3210e-eval/usbmsc/defconfig:CONFIG_SYSTEM_USBMSC=y
configs/stm3210e-eval/composite/defconfig:CONFIG_USBMSC=y
configs/lpcxpresso-lpc1768/usbmsc/defconfig:CONFIG_USBMSC=y
configs/lpcxpresso-lpc1768/usbmsc/defconfig:CONFIG_SYSTEM_USBMSC=y

I tried the stm3210e-eval/nsh2 configuration. The behavior is below. If you want to skip to the chase, it works fine as it always has:

Target:

Aï¿œCDF
Initializing SDIO slot 0
Bind SDIO to the MMC/SD driver, minor=0
Successfully bound SDIO to the MMC/SD driver

NuttShell (NSH) NuttX-7.18
nsh> msconn
mcsonn_main: Creating block drivers
mcsonn_main: Configuring with NLUNS=1
mcsonn_main: handle=20004110
mcsonn_main: Bind LUN=0 to /dev/mmcsd0
mcsonn_main: Connected
nsh>

dmesg

...
[ 938.177909] usb 5-4: new full-speed USB device number 2 using ohci-pci
[ 938.335198] usb 5-4: New USB device found, idVendor=03eb, idProduct=2022
[ 938.335208] usb 5-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 938.335215] usb 5-4: Product: Composite Device
[ 938.335221] usb 5-4: Manufacturer: NuttX
[ 938.335226] usb 5-4: SerialNumber: 0101
[ 938.341255] usb-storage 5-4:1.2: USB Mass Storage device detected
[ 938.341414] scsi7 : usb-storage 5-4:1.2
[ 938.394384] cdc_acm 5-4:1.0: ttyACM0: USB ACM device
[ 938.396928] usbcore: registered new interface driver cdc_acm
[ 938.396931] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[ 939.347416] scsi 7:0:0:0: Direct-Access NuttX Composite Device 0101 PQ: 0 ANSI: 2
[ 939.348471] sd 7:0:0:0: Attached scsi generic sg7 type 0
[ 939.353243] sd 7:0:0:0: [sdg] 7626752 512-byte logical blocks: (3.90 GB/3.63 GiB)
[ 939.572455] sd 7:0:0:0: [sdg] Write Protect is off
[ 939.572459] sd 7:0:0:0: [sdg] Mode Sense: 0b 00 00 00
[ 939.792350] sd 7:0:0:0: [sdg] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 940.252063] sdg: sdg1
[ 940.701816] sd 7:0:0:0: [sdg] Attached SCSI removable disk
[ 1099.888849] SFW2-INext-DROP-DEFLT IN=enp3s0 OUT= MAC= SRC=fe80:0000:0000:0000:92fb:a6ff:fe89:61b9 DST=ff02:0000:0000:0000:0000:0000:0000:00fb LEN=84 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=UDP SPT=5353 DPT=5353 LEN=44
[ 1195.677521] nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead.
[ 1207.198732] usb 5-4: USB disconnect, device number 2
[ 1207.203255] sd 7:0:0:0: [sdg] Synchronizing SCSI cache
[ 1207.203313] sd 7:0:0:0: [sdg]
[ 1207.203319] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
[ 1207.228386] FAT-fs (sdg1): unable to read boot sector to mark fs as dirty
[ 1235.532699] usb 5-4: new full-speed USB device number 3 using ohci-pci
[ 1235.690983] usb 5-4: New USB device found, idVendor=584e, idProduct=5342
[ 1235.690994] usb 5-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1235.691001] usb 5-4: Product: USBdev Storage
[ 1235.691007] usb 5-4: Manufacturer: NuttX
[ 1235.691011] usb 5-4: SerialNumber: 0101
[ 1235.696763] usb-storage 5-4:1.0: USB Mass Storage device detected
[ 1235.696959] scsi8 : usb-storage 5-4:1.0
[ 1236.706422] scsi 8:0:0:0: Direct-Access NuttX USBdev Storage 0101 PQ: 0 ANSI: 2
[ 1236.707054] sd 8:0:0:0: Attached scsi generic sg7 type 0
[ 1236.716114] sd 8:0:0:0: [sdg] 7626752 512-byte logical blocks: (3.90 GB/3.63 GiB)
[ 1236.929332] sd 8:0:0:0: [sdg] Write Protect is off
[ 1236.929344] sd 8:0:0:0: [sdg] Mode Sense: 0f 00 00 00
[ 1237.149181] sd 8:0:0:0: [sdg] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 1237.620872] sdg: sdg1
[ 1238.078374] sd 8:0:0:0: [sdg] Attached SCSI removable disk
[ 1242.997758] FAT-fs (sdg1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

Linux is complaining about some minor issues with the FAT file system which, apparently, was not properly unmounted before. (This will not connect at all on Windows unless you provide a properly driver CNF file.)

mount

...
/dev/sdg1 on /run/media/patacongo/34C4-0237 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
/dev/sdg1 on /var/run/media/patacongo/34C4-0237 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro)
...

ls -l /var/run/media/patacongo/34C4-0237

total 128
drwx------ 3 patacongo users 32768 Jan 1 1980 APM
-rw-r--r-- 1 patacongo users 46692 Jan 1 1980 px4io.loaded
-rw-r--r-- 1 patacongo users 62 Jan 1 1980 px4io_update.log

I grabbed a random microSD card out of a pile. Looks like I got an old PX4 microSD card.

This example uses the same USBMSC driver but different SD card and USB device drivers. Above you will note that there is a verified SAMA5 USBMSC configuration but otherwise USBMSC has not been verified on any other SAM configuration. So you will get that job for the SAME70.

[[e-mail] [nuttx]]

... Above you will note that there is a verified SAMA5 USBMSC configuration but otherwise USBMSC has not been verified on any other SAM configuration. So you will get that job for the SAME70.

The SAMA5 HSMCI and USB device are, I think, identical to the SAME70. You might compare you configuration file with configs/sama5d3x-ek/demo/defconfig to see if the driver settings at different.

[[e-mail] [nuttx]]

The SAMA5D3x-xplained example is kind of interesting because it uses an AT25 serial FLASH.


You did remember to create a file at configs/same70/src/sam_usbmsc.c. You have to have one. The example at configs/sam4e-ek/src/sam_usbmsc.c is probably pretty close to what you want.

[[e-mail] [nuttx]]

Hello All,

Thanks for all the help you provide, I was Sick for the past Two Weeks, I will try EVERY solution you posted and let you know the results as soon as possible.
I know am getting a lot of help and I deeply thank Every one for his engineering time.


Allam