Posted on July 24, 2012 at 00:31I am using a STM32F103 that has implemented a USB device stack based on the Joystick Mouse HID demo code from STM. My app is able to go into USB selective suspend and to resume successfully, both from host-initiated resumes and to do device-initiated USB resume.
I've found that when the interrupt load is very high on the MCU (due to other, lower priority interrupts than USB), that sometimes a device-initiated USB resume won't stick - usb_pwr.c::Resume(RESUME_INTERNAL) will be called, and will toggle CNTR_RESUME on for 10 eSof times, and give up. Repeatedly calling Resume(RESUME_INTERNAL) doesn't help - the host never detects me requesting the USB resume, so I never see SOF messages.
The entire time the Windows host says my device is in D2 (USB selective suspend). Note that the host remains in S0 the whole time, so it isn't like it is turning off the USB port. If I then perform a host-initiated USB resume, things go back to normal - the device can now talk to the host (until the next time the problem occurs).
Has anyone seen anything like this? It seems to only happen if I have lots of other interrupts going on...
