USB Mass Storage Device

[DeusExMachina]

It seems that all MAC OS and Linux problems are related to an unhandled MSD_REQ_RESET

As required by the BOT specification, the Bulk-only mass storage reset request (classspecific
request) is implemented. This request is used to reset the mass storage device and
its associated interface. This class-specific request should prepare the device for the next
CBW from the host.
To generate the BOT Mass Storage Reset, the host must send a device request on the
default pipe of:
• bmRequestType: Class, interface, host to device
• bRequest field set to 255 (FFh)
• wValue field set to ‘0’
• wIndex field set to the interface number
• wLength field set to ‘0’

Giovanni, Is it possible to reset all endpoints? I have looked for this in the USB driver and found nothing like that.

[DeusExMachina]

Well, some results so far...
I got USB-IF USB20CV compliance tool and ran tests for the MSC device.
The main trouble is in the error recovery:
[spoil]Starting Test: USB Mass Storage Error Recovery Test (Configuration Index 0)

Configuring device, set configuration = 0x1
NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call
Setting device interface, interface number = 0x0 and alternate setting = 0x0
NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call
Issuing Get Max LUN request
Max LUN value = 0
Issue CBW with invalid signature
Issuing invalid CBW
CBW successful
Issuing CSW 2 times, CSW should stall in every case
Issuing CSW 1
Issuing CSW 2
Retrieving status on CSW endpoint
CSW endpoint status = 0x1
CSW endpoint stalled
Clearing stalled CSW endpoint
Issuing CSW 2 times, CSW should stall in every case
Issuing CSW 1
Invalid response, CSW should STALL
*************************
(5.2.1) Devices receiving a CBW with an invalid signature should stall
further traffic on the Bulk In pipe, and either stall further traffic
or accept and discard further traffic on the Bulk Out pipe, until
reset recovery. If the device does not react in this manner, it
should at least respond correctly to a Reset Recovery.
*************************
Issuing BOT MSC Reset, reset should always succeed
Retrieving status on CBW endpoint
CBW endpoint status = 0x0
Retrieving status on CSW endpoint
CSW endpoint status = 0x0
Issuing required command (Test Unit Ready) to verify device has recovered
Issuing CBW (attempt #1):
|----- CBW LUN = 0x0
|----- CBW Flags = 0x0
|----- CBW Data Transfer Length = 0x0
|----- CBW CDB Length = 0x6
|----- CBW CDB-00 = 0x0
|----- CBW CDB-01 = 0x0
|----- CBW CDB-02 = 0x0
|----- CBW CDB-03 = 0x0
|----- CBW CDB-04 = 0x0
|----- CBW CDB-05 = 0x0
Issuing CSW : try 1
CSW Bulk Request timed out!
Failed CSW phase : should have been success or stall
(5.3.4) The CSW status value must be 0x00, 0x01, or 0x02.
BOTCommonMSCRequest failed: error=80004000
Re-enumerating device
Detected hard error, issuing BOT MSC Reset
Failed to execute required command (Test Unit Ready) after BOT MSC Reset
(5.7.2) All devices must either support or properly fail the commands marked
as optional in 4.2 based on PDT. Devices that support or properly fail all the commands
marked as optional for Bootable devices will be reported as Bootable.
ValidateCBWErrorTest failed: Re-enumerating device
Unconfiguring the device

Stopping Test [ USB Mass Storage Error Recovery Test (Configuration Index 0):
Number of: Fails (2); Aborts (0); Warnings (1) ]

**
Device is NOT considered compliant with the Bootability specification.
**[/spoil]

[barthess]

Hello there.
In our new project we need to store debug data in NAND and read it later. Writing to
ring buffer organized in NAND is not a big deal but downloading it from device to PC is.
Doing it via UART looks ugly so we decided to use USB mass storage class. I have
working proof of concept driver running on Nucleo-F767zi board. I can
move further development to community repository if any body interested.

[DeusExMachina]

I think that the standard MSD driver will be very useful. My driver works but cannot pass USB consortium tests. I will upload the latest version soon

[barthess]

I have pushed code to community repo. Code has many places to cleanups and improvements.
Any way it works fine in my Gentoo Linux:

Code: Select all

[  567.208067] usb 3-1: USB disconnect, device number 3
[  587.420015] usb 3-1: new full-speed USB device number 4 using uhci_hcd
[  587.595112] usb 3-1: New USB device found, idVendor=0483, idProduct=5740
[  587.595115] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  587.595117] usb 3-1: Product: ChibiOS/RT Mass Storage Device
[  587.595119] usb 3-1: Manufacturer: STMicroelectronics
[  587.595121] usb 3-1: SerialNumber: AECCECCCC400
[  587.599163] usb-storage 3-1:1.0: USB Mass Storage device detected
[  587.600241] scsi host3: usb-storage 3-1:1.0
[  588.644124] scsi 3:0:0:0: Direct-Access     Chibios  Mass Storage     v4.0 PQ: 0 ANSI: 4
[  588.651114] sd 3:0:0:0: [sdc] 700 512-byte logical blocks: (358 kB/350 KiB)
[  588.654110] sd 3:0:0:0: [sdc] Write Protect is on
[  588.654113] sd 3:0:0:0: [sdc] Mode Sense: 03 00 80 00
[  588.657107] sd 3:0:0:0: [sdc] No Caching mode page found
[  588.657110] sd 3:0:0:0: [sdc] Assuming drive cache: write through
[  588.699113] sd 3:0:0:0: [sdc] Attached SCSI removable disk
[  588.797104] romfs: Mounting image 'rom 57fca96e' through the block layer

But it windose it locks in debug trap

Code: Select all

  osalDbgAssert(!usbGetTransmitStatusI(usbp, ep), "already transmitting");

in usbStartTransmitI() function. I have no ideas why but I did not do any investigations there.

I use NUCLEO-F767 board for development. I think code may run on any Nuclen-144 board.
Any suggestions/bugreports you can submit in this topic on directly on github.

[Giovanni]

hi,

Is the state checker enabled too?

Apparently a transmission is attempted while the endpoint is not yet ready.

Giovanni

[barthess]

Is the state checker enabled too?

Yes, all checks enabled.

[barthess]

@Giovanni
Are there any "standard" switchable debug printing macros somewhere in ChibiOS?
They would be very useful for debugging such subsystems like SCSI, mass storage, etc.

[Giovanni]

Not yet, that would be useful, it should go in the HAL probably. I'll add it to the things to do next in the HAL. The others are a critical errors handler and a runtime errors events handler.

Giovanni

[DeusExMachina]

@bartness, have you tried the USB compliance tool USB20CV?
http://www.usb.org/developers/tools/usb20_tools/
There are many MSD drivers now, but the main purporse should be compliance with the standard...