USB HID device does not exit suspend state in enumeration

[irenas]

Hello,

We are developing an HID device using TI MSP430F5528 MCU and using TI provided example code for this MCU family.

The code works fine on TI evaluation board with TI MSP430F5529 MCU, however on our board, we see that host suspends the device and never resumes it, thus enumeration completes with no data about the device (PID/VID are 0) and device is reported as unknown device. On evaluation board, during debugging, we see that host sends suspend event, then resume event and enumeration proceeds correctly.

Our board USB circuit closely follows the evaluation board design, the only difference is that our device has 8MHz external clock, rather than 4MHz on the evaluation board. In the code we have made amendments to adjust for this (at we think so).

Our question is: what can cause host to avoid sending resume event to HID device? Knowing what can be possible error conditions we will be able to eliminate them in our application.

Thank you in advance.

Irena

[Jan Axelson]

If the host isn't even sending a reset following suspend, it doesn't think there is anything there to enumerate, so check the voltages, etc. on the port.

[mdlayt]

An observation:  The host does not "send a suspend."  The host simply fails to service the USB within 3ms and well behaved USB devices suspend after 3ms of inactivity.

My guess is this doesn't actually have anything to do with suspend.  It is just that the host doesn't like your device--although this might be because of the behavior of your device around suspend.

I have had tons of fun trying to find out why a Windows box isn't enumerating my device successfully.  Usually it has been that there is some inconsistency or variation in a descriptor that Microsoft code finds unacceptable.  [Might help if someone published a grammar for HID report descriptors--instead of a novel.]  Another thing I recall was a bug down in the sequence like Clear Feature responded with the wrong number of bytes, or something like that.

Obviously almost any form of debugging you can come up with is better than testing by plugging into Device Manager over and over and getting "device failed to start."