This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430 USB suspends after 50 seconds

Other Parts Discussed in Thread: MSP430F5638

Hello

I'm facing a problem with the USB module and I can't find the answer in other posts.

My aplication uses a MSP430F5638 to send data continuosly into the USB port to be processed by the host. This is done using CDC.

This works great except in a particular situation. If I don't open the associated virtual serial port in the host side for more than 50 seconds after the enumeration preocess has concluded, the MSP430 goes to the ST_ENUM_IN_PROGRESS state and stays there indefinitely.

Suspecting that the computer was suspending the device, I tried to disable selective suspend in windows 7. It didn't solved my problem.

Ideas?

EDIT: I found that this has something to be with transmitting data into the USB port without being receiving the data in the host side. I suspect that some buffer used by windows overflows and causes a suspend or no enumeration state. How can I workarround this? (assume that msp430 never knows if the data is being received)

Thank you.

  • Monitor USB traffic using both of software and hardware analyzer, and get valid clue of the cause. There are so many root causes which bring up symptom you mentioned.

    On the PC side - software sniffer will catch these accidents,
    a) Race condition on transfer timeout
    When the timeout value (by SetCommTimeouts() API) is too short, race condition often occurs between transfer completion and transfer cancel by timeout. Windows CDC driver can't manage this accident well. Longer timeout (or no timeout) is prefered.

    b) Selective suspend
    Windows CDC driver doesn't support Selective suspend. It should not occur. But some note PC force Selective suspend on every USB port, regardless of driver support.

    On the device side - A hardware bus analyzer gets clue,
    c) Noise on USB line
    Burst noise on bus line easily disturbs bulk transfer, defeating retries by the USB hardwares.

    d) The firmware accidentally disables USB engine, and re-enables it (such as watch dog reset)

    etc.

    Tsuneo

**Attention** This is a public forum