Usb OTG Host Driver

[tsybezoff]

Hi to all !!!
I develop usb otg host driver for mass storage device (generic scsi, bulk-only) based on analog device BF-527. I have problem with some usb flashes. I want to know what kind of my problem - it deal with algorythm of initialization or not correct using USB specification model.
So, this is my sequence of working usb driver:
1. Enumeration process:
    - set address;
    - get device descriptor;
    - get config descriptor;
    - set configuration;
    - set interface;
    - get max lun;
2. Configuration process:
    - inquiry (retry 5 times);
    - test unit ready (retry 10 times);
    - read capacity (retry 3 times);
Then Fat File System works.
So, some usb flashes can't take inquiry responce, and i get RX_Error (error when device can't take packet 3 times). Help me please, inquiry responce is correct!

[Jan Axelson]

Some flash drives function under Windows but don't comply fully with the USB mass-storage specs. A host that emulates what Windows does when accessing drives can have a better chance of success with off-the-shelf flash drives.

Also see:

http://www.janaxelson.com/device_errors.htm

[tsybezoff]

Thanx, Jan.
I heard 'bout that some flashes works under Windows. I read about device errors and i have some question. After completing enumeration, the device requires a few seconds before it responds properly to received CBWs. When I need to get delay a few seconds? After Set_configuration or before? And what is delay need it?

Now I get interrupt RX_ERROR, which means that device didn't take my responce by bulk-in EP = 5. I tried to send clear_feature, set_port_feature, bulkOnly_Reset there is no result, also i have interrupt RX_ERROR.

[Jan Axelson]

Enumeration completes when the device ACKs a Set_Configuraton request > 0.

To debug RX_ERROR, if the device works under Windows, use a protocol analyzer to compare your host and Windows.

[tsybezoff]

Hi to all.
I solved my problem with RX_ERROR. I counld not understand for a long time why does error happen. I also captured usb bus by agillent oscilloscope, but it was failure. Now I know what's the problem - enumeration procedure! I leaned usb packet dumps of MS DOS, Win XP and make typical enumeration & configuration procedures for USB Host Driver. So, as you know, enumeration procedure can be different for different OS, therefore host developer must make universal enumeration & configuration sequences for all devices.

My enumeration sequence:

1. Get Device Descriptor (18 bytes) by default address (0)
Of course, you can responce maximum bytes for EP0 (64) like MS DOS. It will be also correct request. Pay attention, some OS responce only 8 bytes at first, It is not so right, 'cause there are flashes don't like it. In any book I read standard enumeration procedure should start with Set Address. I have the usb flash which crashes by setting address at first.

2. Set Address by device registration number
You can set any address to device beside default (0) and more than 0x7F.

3. Get Configuration Descriptor (9 bytes then the whole size of transaction)

4. Get String Descriptor (option)

5. Set Configuration
You must select the number of configuration which device sends to host at config descriptor (bConfigurationValue).

6. Set Interface (option)
You have set interface only after Set Configuration, and you must select interface with bInterfaceNumber & bAlternateSetting at interface descriptor. Pay attention, this parameters must be 0! I read that some flashes crash after this request, but all versions of OS Windows select and set interface for usb msd.

And one more... if you did all that and procedure is failed on any enumeration step, it means you should give more time to flashes between enumeration steps (10-50 ms), 'cause some devices have to alive after your request.

My configuration sequence (for SCSI Bulk-Only):

1. Get Max LUN (retry 3)
This is standard class-specific request, but not all usb devices support it. You can get STALL from device or no data, so you should use Clear Feature request for EP0 Halt. If usb device didn't reply for LUNs after retry 3, it means device doesn't support this request and max lun = 0.

2. Inquiry (retry 5, 36 bytes responce size)
This is standard request for all usb scsi bulk-only device, so you have get reply on it. If you have no relpy - send Request Sense command, and send Inquiry again. There are some flashes which not support this request (you can find them at special linux header/source file). Now many usb devices (specially usb 3.0) contains more inquiry sense data. This fact is indicated by usb devices in field "additional length" of inquiry sense data.

3. Test Unit Ready (retry 10)
This is standard request for all usb scsi bulk-only device, so you have get reply on it. If you have no relpy - send Request Sense command, and send Test Unit Ready again.

4. Read Capacity (option) (retry 3)
There are some flashes which not support this request (you can find them at special linux header/source file). Also now we have many file systems which work without read capacity data, 'cause FS read boot sector & MBR by itself.


Thanx Jan. From russia with love)

[Jan Axelson]

You had many issues to work through! This is very useful, thanks for posting it.

Good point that enumeration can also cause problems because some devices are (improperly) programmed to expect a specific sequence of enumeration requests and events.

[Bret]

It would certainly be nice if Microsoft would publish the code (at least pseudo-code) they use for USB devices, though I don't see that ever happening.  The way it is now, everybody has the guess how Microsoft does it by trying to reverse-engineer the final result, which is an unbelievably huge waste of resources from a global perspective.

It would also be nice if device manufacturers tried to comply with the USB specifications, instead of merely being satisfied that their devices work with the latest version of Windows.  But, alas, I don't see that happening, either (at least not on a widespread basis).

I just felt the need to rant a little bit -- sorry if this offends anyone.

[tsybezoff]

Hi, Bret)
I guess you're right. The all usb developers think about it like you. I developed usb host driver for hid, msd and hub devices on lm92XXXX controller by Luminary. It was the same situation - the basic usb host driver was really raw. Besides, I found many errors in their driver.
I suggest this situation is normal, because device manufacturers use us as additional labor to find their errors, defects, to get the way of source optimazation  and etc.
Yep, it would be nice if Windows would publish pseudo-algorythm of enumeration & configuration procedures at least. But I think it's a business. Many people earn money by programming usb drivers.