PORTS Forum
Ports and Interfaces => USB => Topic started by: nobbyv on March 30, 2015, 01:06:53 pm
-
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).
(http://i59.tinypic.com/33ccgib.jpg)
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.
(http://i61.tinypic.com/6z7vkh.jpg)
I'm a bit stumped here. Any ideas are appreciated.
-
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.
-
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.