STM32F0: Re-configure clocks after exiting stop mode

[RWebe.3]

Hi All,

I'm working with an STM32f091xC on a new design and I'm currently trying

to enable stop mode to conserve power without fully entering standby

mode. I seem to be entering stop mode properly, but I'm having quite a

bit of trouble exiting stop mode.

I created a sample application using Zephyr RTOS that targets the nucleo_f091rc. It configures

the user button as an interrupt source. The Main thread goes into stop mode after 5 seconds

and the user has to press the button to wake it up. I also configured the main thread to toggle

the on-board LED every 100ms to indicate the main thread is running. I have attached the

source code for the example for your review. Although this was implemented with an

unaffiliated RTOS, the STM32 LL and HAL support is pretty identical to the STM32Cube libraries

and other CMSIS code that's available for STM32 development.

The general pattern I'm following for entering/exiting stop mode is as follows:

* Set the regulator state in STOP mode: LL_PWR_SetPowerMode(LL_PWR_MODE_STOP_LPREGU)

* set SLEEPDEEP bit of Cortex System Control Register: SCB->SCR |= SCB_SCR_SLEEPDEEP_Msk

* Wait for events or interrupts: __WFE()

* Reconfigure clocks upon waking up (not confident I implemented this correctly)

Once the __WFE hint instruction is called, I see a decrease in power

consumption and no activity from the main thread. If I press the user

button to generate an interrupt, I see a bunch of garbage characters

over the serial terminal as if it's trying to print it's usual "button

pressed" statement. but there seems to be no proper re-initialization

after sleep mode. The LED then begins to toggle again, but this time at a much

slower rate. nowhere near 100ms like before.

This leads me to believe that I need to reconfigure the system clocks in

order to resume main thread execution properly. The reference manual

for this chip states that the HSI, HSE, and PLL clocks are disabled upon

entering stop mode, so this makes sense.

How could I reconfigure the system clocks to resume normal execution? I would ideally

like to rely on the previously configured values that might already be configured

in memory.

The LL and HAL API in Zephyr is very similar to the STM32Cube CMSIS libraries,

if not identical, so no worries if you do not know the "zephyr" implementation.

The STM32Cube approach is probably very similar to the zephyr approach anyways.

Thanks in advance for your help. Please let me know if you have any

thoughts or questions.

Cheers,

Rob Weber

[Klasson.Johannes]

I stumbled on what I believe is the exact same issue on my STM32f051r8. By default the HSI (8MHz) is selected as system clock. I wanted a faster system clock so I used the PLL at 48MHz as clock source instead.

In Run mode my UART functioned as it should, but after a wakeup from Stop mode only garbage characters came out on the serial port. I attached a logic analyzer to the TX line and analyzed the signal. The bit pattern looked exactly the same before and after Stop mode, the only difference was the frequency with which it was clocked. After Stop mode it was 6 times slower.

From the reference manual: "When exiting Stop mode by issuing an interrupt or a wakeup event, the HSI oscillator is selected as system clock.". So I just reinitialized the PLL after I exited Stop mode and everything worked as it should once again.

So if you have the same issue as me, some other clock source was configured, and after wakeup from Stop mode HSI became configured instead. Then you need to figure out what clock source you had when you initialized the system after a reset, and then reinitialize the system clock the same way after a wakeup.

[RWebe.3 · Accepted solution]

Hi @Klasson.Johannes​ , thanks for mentioning you've experienced a similar issue! I use Zephyr as my RTOS, so I worked with some community members on the Zephyr mailing lists to learn how to reconfigure the clocks. You can check out the thread here: https://lists.zephyrproject.org/g/users/topic/27217100

The solution I came up with is specific to Zephyr, but hopefully it might provide an example for other users with other RTOSes.