USB enumeration timeout?
in [Device Drivers]
|
From: Hannes on 20 Nov 2009 05:23 The 1s requirement only seems valid if the USB device has been powered on during standby (but with VBUS off). In our case, all power has been cut off to our device during standby. The USB spec does not specify any startup time in that case, which is why we are turning to Microsoft to see what timing requirement(s) they have on USB devices coming back after standby. / Hannes.
From: Hannes on 20 Nov 2009 05:25 Hi Tim, Please correct me if I am wrong, but the scenario discussed here (USB device completely powered off during system standby) is not covered by the USB spec. This is why we instead turn to Microsoft for answers on their startup timeout requirements. / Hannes.
From: Dan Ellis on 22 Nov 2009 18:32 On Nov 20, 10:23 am, Hannes <hannes.n...(a)newsgroup.nospam> wrote: > The 1s requirement only seems valid if the USB device has been powered on > during standby (but with VBUS off). > > In our case, all power has been cut off to our device during standby. > > The USB spec does not specify any startup time in that case, which is why we > are turning to Microsoft to see what timing requirement(s) they have on USB > devices coming back after standby. > > / Hannes. USB has no comprehension of a term called standby, it has suspend and detached. It is covered by the USB spec - Windows has detached the device. If windows has turned off VBUS then you are detached regardless of the state of the OS - you then have 1 second to reconnect when VBUS is reasserted. I guess there may be a well defined period after which Windows decides that a device is not there after it reasserts VBUS after resume from standby (which in USB terms is not resume, but attach), but I'm not sure its documented anywhere - it's not the 100ms that's been quoted here and on NTDEV, that's the time to attach after VBUS valid (i.e. bring up D+ - or D- for a low speed device), which was recently extended to 1s. To be honest, I would have thought that Windows should _always_ be unloading your driver if it's cut the power to it and reenumerated it (which it will have done) when coming our of standby, although I must admit I have seen the behaviour you are describing where it somehow knows that your device is still similar enough when it's reenumerated to have the same driver loaded - I would call this a dangerous assumption! If you want your software to behave in this manner, then you could implement a layer on top of the driver you are using (or if you have full control of your driver you could split it in two parts) and allow the raw USB driver to come and go with the top layer maintaining persistence if it can establish the circumstances under which the device was reattached (e.g. after standby or perhaps after a fast unplug replug, or brown-out on the device). You will find variance with different hardware in this behaviour. Some laptops will cut VBUS, others will actually assert suspend, and so won't need to reenumerate when coming out of standby (and indeed don't). If you look carefully you'll also sometimes on some hardware see some buggy behaviour, like a reenumeration when coming out of standby, 'illegal' short reset pulses and other bits of cruft. As such on some platforms you may find that your driver always gets unloaded, whereas on other platforms you may find your driver never gets unloaded. Dan.
From: Tim Roberts on 22 Nov 2009 23:39 Hannes <hannes.news(a)newsgroup.nospam> wrote: > >Please correct me if I am wrong, but the scenario discussed here (USB device >completely powered off during system standby) is not covered by the USB spec. I think you are wrong. The standby thing is completely irrelevant to this situation. Power is being applied to your device, and you are being through enumeration. You are REQUIRED to respond to that within 500ms. It's just that simple. -- Tim Roberts, timr(a)probo.com Providenza & Boekelheide, Inc.
From: Hannes on 24 Nov 2009 11:07
Hi Dan, Thanks a lot for your thorough description and different view points of the USB spec. I guess what I will take home from this discussion, is the fact that no well-specified timeout does not appear to exist in Windows, but it is rather up to the individual OS and PC hardware. The 1 second you quote from the USB spec probably has to be our design goal for now. I appreciate your help, thanks a lot!! / Hannes. |