H7 USB doesn't work with Core WFI

[David Littell]

The USB Host seems to not work if WFI is executed in the FreeRTOS Idle task.  Is it not possible to use USB with a WFI Core sleep?

Thanks for any insight.  A forum search yielded mention of similar problems on other devices (over years!) but no definitive (or even helpful) answers/solutions/explanations.

[Piranha]

Show the exact and complete code of the vApplicationIdleHook() function.

[David Littell]

Hi Piranha,

void vApplicationIdleHook( void )
{

 HAL_PWR_EnterSLEEPMode( PWR_MAINREGULATOR_ON /* Regulator */,
 PWR_SLEEPENTRY_WFI /* SLEEPEntry */ );

} /* close vApplicationIdleHook( ... */

Not much to it...other peripherals, SPI, UART, I2C, etc., seem to be operating just fine.

[Piranha]

Oh, the self torture by the broken bloatware again... Apart from being useless and bloated by design, that HAL function is also broken, because it is missing a DSB instruction. This is how the correct implementation looks like:

 

void vApplicationIdleHook(void)
{
	__DSB();
	__WFI();
}

 

[David Littell]

Seriously?  That's it?  Just curious, how does that convince USB to play nice?

I'm guessing I can do the DSB before the HAL call and it'll still work?

[David Littell]

Tried the __DSB() with the same USB (mis)behavior.  Any other suggestions, please?

[Piranha]

Couldn't be more serious - that is an ARM architectural requirement and on Cortex-M7 it is mandatory. Instead of clicking Cube and spending a time on broken bloatware made by incompetent fools, I read the documentation and implement decent code - that's why I know this! ;) DSB keeps away instruction reorder, data pre-fetch and drains the write buffer. Imagine the CPU going to sleep before some important store instruction is actually written out. Or the CPU reading some data, which should be read after wake-up, before executing the WFI. That is the "fun" the broken bloatware provides! And no, the DSB is a barrier instruction and must be executed right before WFI.

Is the USB stack also the broken bloatware? In that case, are you using it correctly? Read more about it in this post and further discussion:

https://community.st.com/t5/stm32-mcus-products/issue-with-stm32-usb-transmit-interrupted-by-receive/m-p/588507/highlight/true#M222512

[David Littell]

Oh, I never doubted that the DSB is absolutely required and I fully agree it's pure sloppy stupidity for it to not be in the HAL from the outset.  I'll have to look further into your USB stack comments - up to this point someone else has (thankfully) wrestled with USB.  However, attempting to reduce power consumption with the WFI renders USB inoperable and guess what gets blamed?  Hahaha, yeah, the WFI.  Go figure.

[peterdonchev]

I just found the solution.
It seems I faced the same problem 8 years ago. :) lol

https://community.st.com/t5/stm32-mcus-embedded-software/stm32f756-usb-and-wfi/td-p/373465

Now, I just add the following code at the beginning:

 

 __HAL_RCC_USB_OTG_FS_ULPI_CLK_SLEEP_DISABLE();
 __HAL_RCC_USB_OTG_FS_CLK_SLEEP_ENABLE();
 /* Prepare to sleep until interrupt */
 SCB->SCR &= (uint32_t) (~((uint32_t) (SCB_SCR_SLEEPDEEP_Msk | SCB_SCR_SLEEPONEXIT_Msk)));

or for the HS USB:

 __HAL_RCC_USB_OTG_HS_ULPI_CLK_SLEEP_DISABLE();
 __HAL_RCC_USB_OTG_HS_CLK_SLEEP_ENABLE();
 /* Prepare to sleep until interrupt */
 SCB->SCR &= (uint32_t) (~((uint32_t) (SCB_SCR_SLEEPDEEP_Msk | SCB_SCR_SLEEPONEXIT_Msk)));

 

 

[peterdonchev]

Hi @David Littell,

Did you make any progress on this topic? I hit the same wall with the __WFI instruction. The behavior is the same on both cores (CM7 and CM4).