The same thing happens with some USB memory sticks.
When one of our MCF5329-based devices boots it is able to have its code reloaded by plugging in a USB stick. We don't want this to delay the boot for too long, so the code turns the 5V USB power on, waits for a while and then looks to see if the device is present before trying to perform the file-system open.
The maximum time is detailed in:
Universal Serial Bus Specification Revision 2.0
7.1.7.3 Connect and Disconnect Signaling
Figure 7-29. Power-on and Connection Events Timing
Δt2 (TSIGATT) This is the maximum time from when VBUS is up to valid level
(4.01 V) to when a device has to signal attach. Δt2 represents the time required
for the device’s internal power rail to stabilize and for D+ or D- to reach VIH
(min) at the hub. Δt2 must be less than 100 ms for all hub and device implementations.
So we were waiting for double the above - 200ms. That wasn't enough.
Here's the measure time from power-on until the key pulls the pin down for various USB memory sticks:
0 = Alcor Micro 64M Key <1ms
1 - Old White + Heat Shrink: 27ms
2 - Bare White: 27ms
3 - Bare Write "test": 61ms
4 - 2GB Blue (Flakey) 66ms
5 - Corsair: 72ms
6 - DSE: 73ms
7 - Miscreant 1 150ms
8 - Miscreant 2:330ms
9 - Miscreant 3 (8GB): 366ms
Our device doesn't have an external hub. The key plugs directly into the MCF5329's USB port. Our USB stack supplier said that an external hub may mask this problem, which is why others may not be seeing this.
Tom