USB Host Reset Recover Delay Time

[avitresearch]

I am currently integrating a Freescale MQX USB Host into an Automotive Product.
In the Host Stack the first command (Get_Device_Descriptor) is sent out 11ms after the High-Speed Chirp/Reset Detection sequence.  (the USB spec says that devices should be ready within 10ms - so 11ms is technically to spec I guess).

We have tested with a 'USB MSB' Test Kit of many devices and found that some devices (mainly Transcend devices) fail.

If we increase the so called Reset_Recover_Delay to 100ms then the devices work.  I have snooped on other automotive HOSTs and found they range from 100ms (volvo) to 500ms (toyota).

Does anyone have any experience of this ? and could anyone suggest a delay time that is perhaps a 'standard' time to use. 

Sincererly,
Adrian

[Jan Axelson]

Sometimes it's in the interest of hosts to be tolerant of non-compliant devices.

If you're finding that some devices need more time after reset, and if there is no harm in waiting longer, why not wait?

Following what other vendors do, especially if they are market leaders, can be a good strategy, since some devices are designed so they will work with the dominant hosts (for example, Windows) rather than being designed to be 100% compliant with the relevant USB specs.

[Barry Twycross]

There's also the reset length to consider. 1.x was 10ms, 2.x was 50ms. Its quite reasonable to expect that the device might not be ready until 20ms, or 60ms after the start of the reset.

I'm pretty sure we used to use 10ms after a 10ms reset and most devices worked, but then I had recovery which lengthened all delays if the device didn't successfully respond the first time.

[avitresearch]

HI Jan, Barry,

Thank you for your replies... yes we too found that most devices worked with the original 11ms (I guess those to spec), but I just wondered whether there was an "industrial standard" of what to use for those devices that don't meet the spec.  As I say, we have now plumped for 100ms and all the devices that we found to fail with 11ms now work...  I guess any device taking more than 10 times the spec doesn't deserve to work in our applicaiton !

Thanks agian,
Adrian.