How to receive USB resume signal from host when STM32F407 send remote wakeup signal

[Harry0709]

Environment:

STM32F407VGTX 

USB HID mouse, Full Speed

Problem:

Hi, I’m using a STM32F407VGTX board. I send a USB remote wakeup signal to the host and then try to receive a resume signal from the host. The STM32 board can wake up the host (bringing it to the login screen), but it cannot trigger the USB_OTG_GINTSTS_WKUINT interrupt. I have already configured my STM32 board as a HID mouse. However, if I use a real mouse instead, it can wake up the host and successfully trigger the USB_OTG_GINTSTS_WKUINT interrupt. Is there any suggestion or workaround for this problem?

void usb_remote_wakeup()
{
    if (hUsbDeviceFS.dev_remote_wakeup == 1)
    {
        __HAL_PCD_UNGATE_PHYCLOCK(&hpcd_USB_OTG_FS);
        HAL_PCD_ActivateRemoteWakeup(&hpcd_USB_OTG_FS);
        HAL_Delay(5);
        HAL_PCD_DeActivateRemoteWakeup(&hpcd_USB_OTG_FS);
    }
}

[T_Hamdi]

Hello @Harry0709 

You can refer to the USB HID application available in the STM32CubeF4 firmware:

HID application support remote wakeup 

If you are not able to trigger the USB_OTG_GINTSTS_WKUINT interrupt, you can share with me how you are trying to trigger it, and I will help you

best regards,

hamdi

[FBL]

Hi @Harry0709 

In your application, you want the host initiates resume (external resume), or the device wakes up (remote wakeup). Some minor details could lead to 2 different scenarios. In general, here is how it works in device mode:

1. USB controller sets GINTSTS.WKUINT when:
   • A resume is detected on the bus initiated by host, or
   • The core exits suspend due to remote wakeup initiated by the device itself.
2. An interrupt is generated.
3. HAL_PCD_IRQHandler() runs, reads GINTSTS, sees WKUINT, services it, calls callbacks, and clears the interrupt flag.

This whole sequence takes only a few microseconds. When you halt the CPU and single‑step, you may not be able to single step in debug to see this wakeup interrupt flag get triggered. See here. Actually, this is because USB controller is polling in handler mode (inside PCD interrupt handler ..) and you cannot visually read registers in a watch window, etc.
I hope this is clear!