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

 

Interesting issue! While debugging USB signals, I also like using reliable simulators and test tools—pk365 game has some surprisingly handy utilities for quick testing and practice.

[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!

[Harry0709]

Hi @FBL 

1. I don't run my bin file in debug mode.

2. The STM32F407 board is configured as a USB device mode rather than a USB host mode.

3. The USB_OTG_DSTS_SUSPSTS bit is checked to determine whether the core is in the suspend state. Is this correct?

4. After checking RM0090, no reference is found indicating that the USB controller sets GINTSTS.WKUINT when the core exits suspend due to a remote wakeup initiated by the device itself. Could you provide a reference?

[FBL]

Hi @Harry0709 

Bit 31 by definition in RM0090, WKUPINT: Resume/remote wake-up detected interrupt.

Per USB specifications, we have two valid wakeup paths and any time the host is the active side, the correct term is resume, not remote wakeup.

So, if the device has configured the remote wake up feature set after at least 5ms in suspend state, the device can initiate the process of resuming normal operation. In that case, the example provided can help.

[Harry0709]

Hi @FBL 

I have already tried this example, but the problem remains the same.

When the user button is pressed, the STM32 board can wake up the PC (bringing it to the login screen), but it still does not trigger GINTSTS.WKUINT interrupt. This is verified by turning on the red LED in HAL_PCD_ResumeCallback. However, when a real mouse is used, it can wake up the PC (bringing it to the login screen) and successfully trigger GINTSTS.WKUINT interrupt.

Enabling or disabling low_power_enable in USBD_LL_Init has also been tried, but the behavior remains the same as described above.

[FBL]

Hi @Harry0709 

The USB wakeup interrupt USB_OTG_GINTSTS_WKUINT cannot be triggered from USB OTG controller for STM32F411. This is because the wakeup interrupt is managed via the EXTI signal (FS OTG line 18) to CPU, which is not mapped directly to the OTG controller. So reading the GINTSTS register in the OTG_FS_WKUP_IRQHandler will not show any interrupt status changes from the USB OTG controller perspective.

Looking at Figure 250 in RM0383, there are two separate interrupts:

1. USB OTG FS global interrupt : dedicated to the USB OTG IP and handling all USB events except wakeup/resume. Its ISR calls HAL_PCD_IRQHandler().
2. USB OTG FS Wakeup interrupt (EXTI line) : dedicated only to device wakeup/resume. Its ISR is OTG_FS_WKUP_IRQHandler(), where you must first clear the EXTI pending flag, then execute the resume sequence by calling HAL_PCD_ResumeCallback(hpcd).