FS USB Device Fails to Resume After Suspend

[nobbyv]

I've implemented a FS USB device using a STM32F427 from STMicro. It's currently failing CH9 testing (for suspend/resume). Using my USB Beagle, I can see the suspend request from the host, and then the resume some ~250mS later. My device *thinks* it has resumed successfully: I am able to put a break point in my code and see the device receive and process the resume request from the host. However, on this device, the host decides a short time later (~20uS) to send a bus reset, which screws everything up (see trace capture).



I have another set of code that works fine running on the same device/board, so there HW is fine. As can be seen in this trace, there should NOT be a bus reset after resuming; the host should transition directly into sending SOFs. 



I'm a bit stumped here. Any ideas are appreciated.

[Jan Axelson]

A host can send a reset whenever it wants, and the device should be able to handle it.

I don't know whether the reset you're seeing is due to a problem the host has detected or whether it's a test to see if the device can handle the reset.

[Barry Twycross]

What a full speed device should not do is send a remote wakeup in response to a reset. This can have hilarious consequences. For a high speed capable host the remote wakeup is interpreted as a chirp and the device is briefly enumerated at high speed. A full speed remote wakeup is the same signal as a chirp K.

I'm wondering if you've found a different case, I see that the device in the first example is re-enumerated as a low speed device. A full speed remote wakeup and a low speed connect are the same signal. Though I would wonder why the remote wakeup is still there 6 seconds later.