Suspend prior to configuration

[mdlayt]

I keep running into sample device code that waits until it is configured to start checking for suspend.  My recollection is that later compliance tests do check for this by allowing a suspend early and failing a device if it doesn't.

I asked about it at [a certain company that provides USB chips that shall remain nameless] and no one seems to have a clue.

It is kind of annoying to have to keep fixing people's code for this problem because it generally requires fixing the top level architecture so that init processes are state based without busy waits, rather than blocking.   (Which is generally a bigger change than the sales department was hoping for.)

It looks to me like this is hidden in the Microchip libraries in LVR's generic HID sample (and probably works properly).
  pic_usb_device_hid_generic_10.zip

I didn't see anything in this forum about it, so I thought I would check for your input, Jan.

Mike

[Tsuneo]

Hi mdlayt,

My recollection is that later compliance tests do check for this by allowing a suspend early and failing a device if it doesn't.

As of compliance test, "USB 2.0 Connect Timing ECN" tells on this issue as follows.

USB 2.0 Connect Timing ECN.pdf
(included in http://www.usb.org/developers/docs/usb_20_081810.zip)
Post-connect current timing
The Battery Charging spec allows devices to draw 100mA for 1 second after the connect event, regardless of what is happening on the bus.

The USB 2.0 spec currently requires devices to drop down to suspend current within 10ms of no bus activity, during both the attach debounce time (TATTDB) and during the reset time (TDRST). In practice, no devices do this. During USB compliance testing, suspend current is not tested until several seconds after the connect event.

The USB 2.0 spec would be modified such that a device is not required to drop down to the suspend current during the 1 second immediately following the connect event.


I have an impression that this issue is still in transition.

Tsuneo

[mdlayt]

In practice, no devices do this.

Well, that is probably the least valid statement in the ECN.

 ***

Nice info, Tsuneo.  Thanks.

This takes my esteem for these programmers to a whole new level.  Only pretenders write to today's spec.  Real programmers write to the spec as it exists in the future when we are debugging their code.