USB enumeration timeout?
in [Device Drivers]
|
From: Hannes on 18 Nov 2009 10:07 Thanks for the figures. But 10ms in the case I am describing - power on to USB stack ready - seems unreasonable, no? Since USB power is off during PC sleep, this is essentially a cold boot for our USB device. I also doubt Windows is really scanning the USB bus for devices already 10ms after the USB devices have been powered. And those not responding afer 10ms, their drivers get unloaded?? 10ms does not seem reasonable to me. The real-world timeout on a Windows (e.g. 7) machine must be much longer, probably closer to 1 second? / Hannes.
From: Pavel A. on 18 Nov 2009 10:48 "Hannes" <hannes.news(a)newsgroup.nospam> wrote in message news:6AFC087E-C09D-4748-BB8B-80419F13CF47(a)microsoft.com... > 10ms does not seem reasonable to me. The real-world timeout on a Windows > (e.g. 7) machine must be much longer, probably closer to 1 second? But you wrote that this device needs few seconds, that's, much more than one second? --pa
From: Hannes on 19 Nov 2009 04:26 Yes, so I guess we need to redesign. But we MUST know the target requirement, so we know what to design for. There is a huge difference between 10ms and "about 1 second". -What is the power-on to USB-ready requirement?
From: Dan Ellis on 19 Nov 2009 05:59 On Nov 19, 6:26 pm, Hannes <hannes.n...(a)newsgroup.nospam> wrote: > Yes, so I guess we need to redesign. > > But we MUST know the target requirement, so we know what to design for. > There is a huge difference between 10ms and "about 1 second". > > -What is the power-on to USB-ready requirement? If Windows has dropped VBUS when going into standby then it has detached you and to be a compliant device you must reattach within 1 second of VBUS coming up. If it wants you to come up quickly then it will keep you in USB suspend, i.e. VBUS will still be present but it will just stop sending you SOFs, to be compliant in this scenario you should have remained attached but drawing less than 2.5mA. Section 7.1.7.7 of the USB 2.0 spec actually seems to give you 30ms from the signalling of resume. Resume signalling must be held for 20ms, then 10ms must be provided by the host before talking to the device. If Windows wants to keep its drivers loaded when it has detached your device, hoping that you will enumerate quickly when reattached then it is optimistic. If you dowload the latest version of the USB 2.0 zip pack, you'll find the USB 2.0 Connect Timing ECN. This spells out clearly the 1 second requirement which was previously only mentioned in compliance: to provide a good user experience a device is required to connect (raise D +) within 1 second of VBUS being valid. Although if you can prove that you've got a dead/weak battery then you've got 45 minutes. You'll also need the battery charging spec 1.1 to get the values for the symbols. Dan.
From: Tim Roberts on 20 Nov 2009 00:47
Hannes <hannes.news(a)newsgroup.nospam> wrote: > >But 10ms in the case I am describing - power on to USB stack ready - seems >unreasonable, no? Since USB power is off during PC sleep, this is essentially >a cold boot for our USB device. > >I also doubt Windows is really scanning the USB bus for devices already 10ms >after the USB devices have been powered. And those not responding afer 10ms, >their drivers get unloaded?? > >10ms does not seem reasonable to me. The real-world timeout on a Windows >(e.g. 7) machine must be much longer, probably closer to 1 second? I'm not sure why you are refusing to believe me, but even if you don't, the USB specification is freely available for anyone to download. NO ONE who is considering building a USB device should take the first step without have the spec readily available, and without having read much of it. Even if you are only doing drivers, chapters 5 and 9 of the specification MUST be read and understood. Resume lasts 10ms. After that, your device must be prepared to go through speed negotiaton. Once you have a device number, you're in "active" state, and you have 500ms to respond to control endpoint requests, which is what the descriptor requests are. -- Tim Roberts, timr(a)probo.com Providenza & Boekelheide, Inc. |