We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I write simple test programm (host mode, full speed) to work with USB stick. In the begining this program do: - get descriptor form USB stick (with numbers of IN and OUT end-points in the device), - set this number of IN, OUT endpoints in the USB controller, - set Address 1, - set Configuration 1, - set Interface 0. It's works correct. Than program send CBW with any SCSI command (inquory/read10/write10) and recive ACK. But when it send IN (or OUT for write10 command) request, than device answer STALL. Where is my mistake? For only one USB stick (A-Data 2 Gb) my programm work correct - I can read or write sector from/to USB stick (I don't undestand why!).
Alex.
Your question may get a better answer on the forums at usb.org. But...
Do you read the sense data after the stall? Is the stick write-only?
There are a couple different subclasses a usb memory stick can have. Are you checking the subclass? All of the subclasses may support the same command, but there can be subtle differences in the formatting of the command. Last I checked, there were six subclasses. You'll likely only come across three of them, though: UFI, RBC, and SCSI transparent (which is a subset of RBC).
Also, some devices have non-compliance issues and need special pampering. For example, I have a SanDisk 4Gb that needs an extra delay after the CSW and before the data stage. Also, most SanDisk's that I've used need a delay after the INQUIRY command, or they'll stall. We use a SuperTalent 2Gb that needs a delay before the data stage for the inquiry command only.
Jonathan, thanks for your answer.
All testing USB sticks have descriptor: class = 0x08 (MSC), subclass = 0x06 (SCSI), protocol = 0x50 (bulk only).
What delay (in ms) is needed after INQUIRY (or after CSW)? Where I can read about this extra delay? I used 10-20 ms delay, but result is the same - SCSI commands don't work.
I believe the spec says 10ms, but to find the actual delay needed can be a trial and error thing. I use 100ms and that has worked fine for all devices so far.
http://www.lvr.com/ covers various USB devices and a lot of their non-compliance quirks.
A typical (simplified) sequence of enumeration of MSC is as follows,
1) Get_Descriptor( Device ) for the first 8 bytes - you get bMaxPacketSize0 field for following Requests. 2) Set_Address 3) Get_Descriptor( Device ) for full descriptor 4) Get_Descriptor( Config ) for the first 4 bytes, at least - the size of config descriptor (wTotalLength field) is known 5) Get_Descriptor( Config ) for full descriptor set 6) Parse the config descriptor set. Confirm mass storage - Bulk-Only Transport interface. 7) Set_Configuration 8) Get_Max_LUN - you may get STALL for this request. In this case, Max LUN = 0
> Than program send CBW with any SCSI command (inquory/read10/write10) and recive ACK. But when it send IN (or OUT for write10 command) request, than device answer STALL.
When you get STALL on data transport, recover the pipe using Clear_Feature( ENDPOINT_HALT ) request. And then, read CSW. Retry the SCSI command after appropriate interval, repeatedly, at least three times.
Tsuneo
Tsuneo, thanks for your answer.
Yes, I used Clear_Feature( ENDPOINT_HALT ). Than if I do GET_STATUS for this end-point (0x81 for example), I receive 0 (i.e. all is OK!). This requests are sended from host end-point number 0 to device end-point number 0.
But when I send IN request (for read CSW) I get STALL again. This request is sended from host end-point number 1 to device IN end-point number 1 (0x81).