How to delay USB device recognition?

Hi,

I have a problem. I am developing a USB device based on a AT91
MCU. The problem is the the boot-up time of the device is relatively slow,
because the device must do “lengthy” operations to read out its serial number.
The reason why I need to read out the serial at MCU boot is that I wish to
set the serial number descriptor of the USB to the real serial number of the device.
But because of the “lengthy” MCU boot-up the USB stack initialization is delayed.
But as a side-effect I get “USB device not recognized” by XP.
Guess after device is presented on the USB bus, it takes “more” compared to
“normal devices” for my device to respond to USB bus commands.

Are there any solution to this issue?
Or shall I read out the serial as fast as I can?
Thanks,

Tibor

Tibor Harsszegi wrote:

The problem is the the boot-up time of the device is relatively
slow, because the device must do “lengthy” operations to read
out its serial number. The reason why I need to read out the
serial at MCU boot is that I wish to set the serial number
descriptor of the USB to the real serial number of the device.

How much power does your device need to read its serial number out of its “innards”? I suppose you could steal a little power from the bus without actually enumerating yourself. Once you’re ready to talk on the bus, you can actually present yourself for enumeration, serial number in hand.

I like Chris’ idea.

Another thought might be to overlap the process of obtaining the serial number with “other stuff” that takes place. You don’t really *need* the serial number until the SECOND request for the Device Descriptor (the FIRST request never gets to return it), right? So, from the time your device is attached to the time you get that second request for the device descriptor, you do have SOME time.

Another thought (though an ugly one) might be to start getting the ID as soon as possible, and if you’re too late to “make it” for the second Device Descriptor, do a device reset and have your device be re-enumerated (this time, WITH the serial number). You could even return entirely different descriptors at that first no-serial-number enumeration. I’m thinking of something like the way the FX2 does its “re-numeration” or whatever it’s called.

I guess it depends on how “slow” the process really is,

Peter
OSR

xxxxx@chello.hu wrote:

I have a problem. I am developing a USB device based on a AT91
MCU. The problem is the the boot-up time of the device is relatively slow,
because the device must do “lengthy” operations to read out its serial number.
The reason why I need to read out the serial at MCU boot is that I wish to
set the serial number descriptor of the USB to the real serial number of the device.
But because of the “lengthy” MCU boot-up the USB stack initialization is delayed.
But as a side-effect I get “USB device not recognized” by XP.
Guess after device is presented on the USB bus, it takes “more” compared to
“normal devices” for my device to respond to USB bus commands.

The maximum enumeration delay is mandated by the USB specification.
This is not just some capricious timeout invented by XP.

Are there any solution to this issue?
Or shall I read out the serial as fast as I can?

I encountered this exact same problem with a Cypress FX2 chip – loading
the firmware from EEPROM delayed the enumeration too long. Earlier USB
host controllers didn’t care, but later ones did. The FX2 has a
configuration bit that says whether its EEPROM I2C bus should run at 100
kHz or 400 kHz. I solved my problem by switching to the faster I2C speed.

The only solution is to fix your device.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Bus enumeration will not start until the device asserts its presence on the
bus. You can take power (100mA max) before this and boot up the device. If
you only assert the data lines after that, the host will see the device and
start enumeration then. Of course, if you have hardwired to the bus you may
not be able to delay the enumeration, but some recent bus interfaces are
programmable and float the bus until you choose to assert. The USB 2.0 spec
says that you should assert attach within 100ms of hot plugging, but in
practice you can probably take longer, as I have not seen a hub turn off the
power in some sort of electronic huff at the delay (this may be more likely
on low power hosts like laptops). Even if you don’t want to do this, it
gives you an extra 100ms which may give you time to get the serial number
data you need… M

xxxxx@chello.hu wrote:

I have a problem. I am developing a USB device based on a AT91
MCU. The problem is the the boot-up time of the device is relatively slow,
because the device must do “lengthy” operations to read out its serial
number.
The reason why I need to read out the serial at MCU boot is that I wish to
set the serial number descriptor of the USB to the real serial number of
the device.
But because of the “lengthy” MCU boot-up the USB stack initialization is
delayed.
But as a side-effect I get “USB device not recognized” by XP.
Guess after device is presented on the USB bus, it takes “more” compared
to
“normal devices” for my device to respond to USB bus commands.

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Thursday, November 12, 2009 7:09 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] How to delay USB device recognition?

The USB 2.0 spec
says that you should assert attach within 100ms of hot
plugging, but in
practice you can probably take longer, as I have not seen a
hub turn off the
power in some sort of electronic huff at the delay (this may
be more likely
on low power hosts like laptops). Even if you don’t want to
do this, it
gives you an extra 100ms which may give you time to get the
serial number
data you need… M

The device which doesn’t fulfil 100 ms limit won’t pass USB-IF
certification if I remember correctly. We had this problem in the past
and had to fix firmware to enable USB block in earlier phase of boot
which took longer.

Anyway, good idea. Extra 100 ms could be enough to read serial number.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@osr.com
Sent: Thursday, November 12, 2009 4:11 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to delay USB device recognition?

Another thought (though an ugly one) might be to start
getting the ID as soon as possible, and if you’re too late to
“make it” for the second Device Descriptor, do a device reset
and have your device be re-enumerated (this time, WITH the
serial number). You could even return entirely different
descriptors at that first no-serial-number enumeration. I’m
thinking of something like the way the FX2 does its
“re-numeration” or whatever it’s called.

It would work but… I’m affraid there is a good chance to invoke some
bug in USB stack or function driver loaded and get BSOD. Re-enumeration
would have to be done within relatively short time (one sec?) after
plug-in (to avoid bad user experience) and there would be surprise
removal during stack initialization. Nothing bad in principle but in
practice it is asking for problems. In addition, user would probably
complain about sound of device disappearing.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Michal Vodicka wrote:

Re-enumeration would have to be done within relatively short
time (one sec?) after plug-in (to avoid bad user experience)
and there would be surprise removal during stack initialization.
Nothing bad in principle but in practice it is asking for problems.
In addition, user would probably complain about sound of device
disappearing.

Not to mention the “failed device installation” tooltip that would inevitably appear in the system tray.

Hi guys,

thank you all for the good hints, I’ve decided not to mumble-jumble with the
USB bus, instead I changed the serial number logic, and speeded up (cached)
the “lengthy” operations.
Thanks again,