cancel
Showing results for 
Search instead for 
Did you mean: 

STM32L552 RCC issue

BBekk.1
Associate II

Hello,

I am evaluating the STM32L552 with Zephyr OS for a new project. While implementing a low power sleep mode, i encountered an issue with clock configuration.

In my code, I place the MCU in stop2 mode while sleeping, and wake up based on a LPTIM interrupt. Before going to sleep, I configure the clock to wake up in MSI mode. After waking up, I reconfigure the system clock to use the PLL as the clock source, with MSI as the PLL source. I configure this using `LL_PLL_ConfigSystemClock_MSI` from the LL drivers.

All of this seems to work, but after zephyr OS switches to a different thread, the clock settings are set back to the reset values. As far as I can tell, the software does not modify the clock settings, but they are reset by hardware when executing the context switch.

I am not excluding the posibility that there could be a software reset somewhere, but my debugger does not record any writes to the RCC in the time interval the reset happens.

Is there any behaviour that could explain this, or suggestions for how to debug this? Is this a hardware feature?

PS: I don't have TZ enabled.

1 ACCEPTED SOLUTION

Accepted Solutions
BBekk.1
Associate II

I solved the issue:

The zephyr OS code did not reset SCR.DEEPSLEEP from deepsleep mode to regular sleep mode after leaving deepsleep. Instead, they reset SLEEPONEXIT. This is probably a bug, because sleeponexit is never enabled in the first place. This means that at the next WFI, the mcu goes back to deepsleep for a few us, resetting the clock configuration.

View solution in original post

2 REPLIES 2
TDK
Guru

> All of this seems to work, but after zephyr OS switches to a different thread, the clock settings are set back to the reset values. As far as I can tell, the software does not modify the clock settings, but they are reset by hardware when executing the context switch.

A context switch doesn't modify the clock settings. There has to be an answer somewhere in your code.

> I am not excluding the posibility that there could be a software reset somewhere

You really should instrument your startup so that, at the least, you know it happens.

If you feel a post has answered your question, please click "Accept as Solution".
BBekk.1
Associate II

I solved the issue:

The zephyr OS code did not reset SCR.DEEPSLEEP from deepsleep mode to regular sleep mode after leaving deepsleep. Instead, they reset SLEEPONEXIT. This is probably a bug, because sleeponexit is never enabled in the first place. This means that at the next WFI, the mcu goes back to deepsleep for a few us, resetting the clock configuration.