Skip to content

AT32F405 gets stuck in a suspended state even though the bus is resumed #3315

@peppapighs

Description

@peppapighs

Operating System

Windows 11

Commit SHA

4dfac3f

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions