-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Description
Operating System
Windows 11
Commit SHA
Board
ArteryTek AT32F405 Custom Board
Firmware
Custom firmware with this tusb_config.h
What happened ?
When the bus is suspended, the device does not receive the event DCD_EVENT_SUSPEND event received. However, when the bus is resumed, the device receives both DCD_EVENT_RESUME and DCD_EVENT_SUSPEND in two consecutive interrupts, but DCD_EVENT_RESUME was processed first here then DCD_EVENT_SUSPEND, so _usb_dev now get stuck in a suspended state perpetually when it should not.
The current workaround I have is to modify TinyUSB locally to ignore the event DCD_EVENT_SUSPEND, but this seems like a very hacky solution. I also cannot reproduce this issue on AT32F405 evaluation board since it seems my PC refuses to suspend the evaluation board (maybe because of its lower current draw?).
Edit: I verified that the suspended status in the dsts register is consistent with the actual suspended state. Not sure why the interrupt handler is not called when the device gets suspended.
I found the cause of the issue. On initialization, AT32F405 receives a suspend interrupt once (usbsusp = usbsuspm = 1) before the device is connected. As a result, dcd_int_handler disables the suspend interrupt, even though the device is still unconnected. Subsequently, when the bus is suspended, no suspend interrupt is received. When the bus is resumed, dcd_int_handler handles the wakeup interrupt, and enable the suspend interrupt, causing the pending suspend interrupt from before to suspend the device indefinitely.
I suppose the correct implementation is to only disable suspend interrupt when the device is connected, but dcd_int_handler has no access to _usb_dev.connected, so I'm not sure what should be done here. At least preventing dcd_int_handler from disabling the suspend interrupt entirely works.
How to reproduce ?
Flash the firmware here, and suspend the board.
Debug Log as txt file (LOG/CFG_TUSB_DEBUG=2)
I don't have a J-LINK, but I can put a breakpoint to inspect the memory manually if needed.
Screenshots
No response
I have checked existing issues, discussion and documentation
- I confirm I have checked existing issues, discussion and documentation.