USBX CDC-ACM + Sleep Mode: How to wake STM32U5 on USB activity?

[j_filipe]

Hi everyone,

I'm working with an STM32U5 and using USBX with the CDC-ACM class.

My setup is as follows:

• I have a USBX CDC ACM receive thread that calls usbx_cdc_acm_read_thread_entry() in ux_device_cdc_acm.c file.

• Alongside, I have a state machine running in another context (main loop).

• If the device stays idle (no USB activity) for a certain timeout, the state machine puts the MCU into Sleep Mode using:

HAL_SuspendTick();
HAL_PWR_EnterSLEEPMode(PWR_LOWPOWERREGULATOR_ON, PWR_SLEEPENTRY_WFI);
HAL_ResumeTick();

The goal is to wake up the MCU only when data is received on the USB.

To achieve this, I tried relying on USB interrupts:

• OTG_FS_IRQn is enabled in NVIC.

• The USB OTG FS peripheral is initialized properly via HAL_PCD_Init().

• OTG_FS_IRQHandler() is defined and calls HAL_PCD_IRQHandler()

But I'm not getting out from the Sleep mode, I'm completely stuck and running out of ideas. 
Any assistance would be greatly appreciated. 
Thank you! 

[TDK]

Should be working. Any interrupt is able to wake the processor out of sleep mode from WFI. No special setup required.

If you don't disable systicks, do systicks wake it up?

> But I'm not getting out from the Sleep mode

How exactly are you determining this? Have an LED light up only when you're in sleep mode. Ensure it goes off.

Are you entering sleep within the main thread? It may not work as you expect if you're in an interrupt.

[j_filipe]

Greetings TDK, 
I'm determining this by toggling a GPIO signal in the OTG_FS_IRQHandler callback. While it is not in sleeping mode, I can watch the signal changing in the osciloscope, but when I enter in sleep mode, I cannot watch any signal changes. 
But yes, even if I don't disable systicks, it doesn't wake up from sleep. 
So, basically I've a receive usb data thread that generates the interrupt, if it's not in sleep mode, it generates an interrupt, but if I go into sleep mode (disabling or not the systicks), it doesn't generate the interrupt. 

[j_filipe]

More... 
If I use debug mode, it gets out from sleep.

[j_filipe]

Ok what is happening: So I start the debug mode, it goes to sleep mode. I press any key from the keyboard to generate the interrupt , nothing happens, I can't see anything in the osciloscope. I press the pause button and it is on __WFI(); in the HAL_PWR_EnterSLEEPMode. As soon as I press the resume button, it generates the interrupt (cause I see the signal in the osciloscope) and wakes up from sleep. So I can only manage to exit the sleep mode in debug mode.

[FBL]

Hi @j_filipe 

Would you attach minimum firmware to reproduce the issue? Are you using a reference board?

[j_filipe]

Greetings FBL, 
Unfortunately I can't attach minimum firmware to reproduce the issue due to the possibility of copyright infringement. I'm not using any reference board, just making use of the STM32U5 series MCU. At least I would like to know which front I should look on, or what could be the possible cause of this issue. 
Best regards!

[FBL]

Hi @j_filipe 

For STM32U5 there isn’t a dedicated USB line in the vector table to wake up the MCU, as was available in older products like the STM32F429 : OTG_HS_WKUP.

Instead, you can use simple resistor divider combined with GPIO to trigger a wake up via USB controller. Check section 2.6.1 Simple resistor divider in AN4879 for better details.

Make sure main regulator voltage scale is not in range 4 (or 3 depending on your product). Otherwise, this won't be possible as detailed in corresponding datasheet.

[j_filipe]

Thank you for the insight FBL. 
However I checked the RM0456, which is referred to the STM32U5 series MCUs and it shows the the OTG_FS_WKUP / OTG_HS_WKUP line. 

[FBL]

Hi @j_filipe 

In footnote, it is noted:

1. OTG_FS_WKUP becomes active (high state) when resume condition occurs during L1 SLEEP or L2 SUSPEND states.

This is not direct EXTI wakeup. 

You can refer also to Table 190: EXTI line connections: we don't have direct USB wakeup over EXTI on STM32U5. 

You have 40ms to detect vbus cable loss.

With aggressive low power mode, we can poll SESSVLD in OTG_GCCFG for about 40 ms every 25us to monitor vbus state. There should be no event generated.