USB enumeration timeout?
Hannes
later it is expected to appear on the USB bus, or its drivers will get
unloaded (I guess Windows assumes the device has been removed during sleep).
What is the timeout requirement to avoid driver unload?
We have a heavy composite USB device with a CPU and boot ROM etc, and it may
take several secons to boot up and start its USB stack.
Pavel A.
news:9EDE147F-F181-4F8B...@microsoft.com...
See the thread "How to delay USB device recognition?" in NTDEV, less than a
week ago.
The timeout is 100ms.
Regards,
-- pa
Hannes
Let me try again:
When you resume a Windows (7) PC from sleep, it will power its embedded USB
devices. Shortly thereafter, Windows will detect all attached USB devices,
and load/unload device drivers as appropriate.
Our device implements its USB stack in software, and so needs a few seconds
to bring up its USB stack. This appears to be too long, and the USB
enumeration is already missed. We therefore see our drivers getting unloaded
every time the PC resumes from sleep.
Just a second later, our USB device is ready, and our drivers get loaded
again.
I assume we need to redesign our device to bring up its USB stack quicker -
but what is the actual time requirement from power-on to
ready-for-enumeration? We need a target requirement to know what to design.
(I guess the 100ms refered to in USB-IF are from "toggling its data lines,
to enumeration". Our device will toggle its lines when ready, so those 100ms
are not an issue for us.)
Thanks,
/ Hannes.
"Pavel A." wrote:
> .
>
Tim Roberts
>
>Thanks for that reference. It is possible I did not ask the right question.
>Let me try again:
>
>When you resume a Windows (7) PC from sleep, it will power its embedded USB
>devices. Shortly thereafter, Windows will detect all attached USB devices,
>and load/unload device drivers as appropriate.
>
>Our device implements its USB stack in software, and so needs a few seconds
>to bring up its USB stack. This appears to be too long, and the USB
>enumeration is already missed. We therefore see our drivers getting unloaded
>every time the PC resumes from sleep.
>Just a second later, our USB device is ready, and our drivers get loaded
>again.
>
>I assume we need to redesign our device to bring up its USB stack quicker -
>but what is the actual time requirement from power-on to
>ready-for-enumeration? We need a target requirement to know what to design.
>
>(I guess the 100ms refered to in USB-IF are from "toggling its data lines,
>to enumeration". Our device will toggle its lines when ready, so those 100ms
>are not an issue for us.)
This is all spelled out in the USB specification. You get 10ms "recovery"
time after a reset or resume, and you are required to respond to a control
request within 500ms.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
Hannes
This could be very alarming for us and our products.
Our device currently takes a few seconds from power-on to start up its USB
stack.
Is the requirement really <500ms, i.e. is our device is completely
unacceptable?
/ Hannes.
Pavel A.
All devices belong to either of two kinds: compatible with Windows
and not compatible.
Your device is "alternatively compatible" as they say in the USA :)
--pa
Leo Havmøller
The timing requirements start when you attach to the bus.
Your device may take as long as it wants to startup and then attach when
your USB stack is ready.
Leo Havmøller
Pavel A.
news:B0AA57FA-F579-42F8...@microsoft.com...
> The timing requirements start when you attach to the bus.
> Your device may take as long as it wants to startup and then attach when
> your USB stack is ready.
>
> Leo Havmøller
No, this is a much worse scenario: resume. The device has been attached
before standby.
The intent is that it won't disappear after resume.
--pa
Hannes
Our device was attached and with drivers loaded, before sleep.
Then, after resume, our drivers get unloaded because we take too long to
attach to the bus.
So - how long can we wait, max, from resume power-on, to attaching to the
USB bus, in order for our drivers NOT to get unloaded? 1sec? 2secs? 1.5secs?
(I guess this might also be covered as part of Velocity testing.)
/ Hannes.
Leo Havmøller
> Exactly, Pavel. Thanks!
> Our device was attached and with drivers loaded, before sleep.
> Then, after resume, our drivers get unloaded because we take too long to
> attach to the bus.
In that case you are already attached to be bus, and the requirements are
much stricter.
The USB specs require the following for suspend/resume:
- Device must be in low-power state (max draw 2.5 mA) maximum 7 ms after
suspend is ordered.
- Device must be able to respond after resume has been signalled - and
resume is 10 ms long.
Leo Havmøller.
Hannes
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.
Pavel A.
> 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
Hannes
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?
Dan Ellis
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.
Tim Roberts
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.
Hannes
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.
Hannes
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.
Dan Ellis
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.
Tim Roberts
>
>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.
Hannes
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.
Hannes
Thanks for your reply. My understandings of USB are not to-notch, why my
questions may seem silly at times.
My take from this discussion is that there is no clear requirement stated in
Windows, why we'll have to assume the USB spec sets the startup time
requirement.
Dan Ellis say the maximum time is 1s, while you say 500ms.
Either way, we will have to heavily re-architect our USB device and/or
drivers in order to solve our current issues, which occur due to the driver
unload after resume.
Again, thanks a lot for your replies and efforts in explaining these things
to me.
Thanks!
/ Hannes.
Hannes
> 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!
Dan, to be honest - wouldn't there on any given PC be A LOT of devices
unloading/relaoding (with the accompanying bing-bong sounds) every time you
sleep/resume a regular PC? Many devices inside a PC are USB based, and they
should, just like our built-in USB device, get unloaded upon sleep...?
There is some logic in Windows that today, and likely also in the future,
decided to keep the drivers loaded in memory - and we would absolutely LOVE
to figure out the requirement for this, so that also our device can enjoy the
same treatment.
/ Hannes.
Doron Holan [MSFT]
low power and do not fall off of the bus. there is no logic in windows to
keep drivers loaded in memory (or their associated device stacks which is
the underlying issue) on return from resume if their devices are gone. you
don't hear the device removal sounds b/c the devices are not being removed.
d
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Hannes" <hanne...@newsgroup.nospam> wrote in message
news:094FAB85-8F91-445E...@microsoft.com...
Hannes
1. Let's assume that while the PC sleeps, the embedded USB devices are
completely powered off. Dead. Supply voltage, USB bus voltage, everything.
2. Someone then presses the power button to resume the PC.
3. All embedded USB devices are powered on.
4. Windows resumes
5. At some point, Windows, or each device stack, checks if a device is still
present.
I see 2 possible outcomes:
> 5a. The device is present (i.e. speaks USB), and the driver remains loaded.
> 5b. The device is NOT present (i.e. does not respond to USB communication) and its driver gets unloaded. Bing-bong.
On Windows 7, what is the minimum time step-3-to-step-5 ?
(i.e. for how long can a USB device boot without getting unloaded?)
Please let me know if:
- I have gotten it all completely backwards
- we should direct this question to a different newsgroup or forum
- we should open a support case to get this time figure
Thanks a lot for your efforts this far.
/ Hannes.
Tim Roberts
>
>1. Let's assume that while the PC sleeps, the embedded USB devices are
>completely powered off. Dead. Supply voltage, USB bus voltage, everything.
>2. Someone then presses the power button to resume the PC.
>3. All embedded USB devices are powered on.
>4. Windows resumes
>5. At some point, Windows, or each device stack, checks if a device is still
>present.
>I see 2 possible outcomes:
>> 5a. The device is present (i.e. speaks USB), and the driver remains loaded.
>> 5b. The device is NOT present (i.e. does not respond to USB communication) and its driver gets unloaded. Bing-bong.
>
>On Windows 7, what is the minimum time step-3-to-step-5 ?
>(i.e. for how long can a USB device boot without getting unloaded?)
You need to stop thinking like this, because the answer to this question is
not useful. Just because you happen to get a time that works in Windows 7
does NOT mean, for example, that it will work in Vista or XP or Windows 8,
or even Windows 7 SP1, or even Windows 7 with a different motherboard.
Microsoft is never going to give you a number. It's not part of their
contract.
The FACT is that your allowable time lag is dictated very clearly in the
USB specification. If you violate the specification, you are not USB
compliant, whether or not your device happens to work in some circumstances
on some releases of some operating systems.
>Please let me know if:
>- I have gotten it all completely backwards
>- we should direct this question to a different newsgroup or forum
>- we should open a support case to get this time figure
I would argue for the first answer.
Pavel A.
In addition to reply of Tim, maybe the Windows Logo program document
can give you more clues.
For example, see in the recent updates:
<quote>
CONNECT-0126: All USB devices and host controllers work properly upon resume
from sleep,
hibernation or restart without a forced reset of the USB host controller.
Clarified wording, added justification to design notes.
</quote>
Regards,
--pa
"Hannes" <hanne...@newsgroup.nospam> wrote in message
news:A4227441-B0FD-4F44...@microsoft.com...