Reduce power consumption STM32L4

[Lukasz Przenioslo]

Hello there,

I am developing a FreeRTOS based application using STM32L452 MCU. I am looking for a way, to reduce the power consumption in the idle intervals of the processors work. When reviewing the sleep modes, it occured to me that the MCU might be unresponsive to external events or even lose context (MCU reset), which is not fit in this RTOS running application.

I thought then that I could simply reduce the HCLK frequency by playing with the PLL registers. The problem here is that the systick timer will get altered, and I really need it to stay with its regular timebase (1 ms). I checked either it is possible to clock the Systick timer from other sources, but it seems like its only HCLK and HCLK / 8. The datasheet says it is calibrated for this value.

I would appreciate some suggestions on this topic.

Lukasz.

[Uwe Bonnes]

Clock LPTIMER with HSE an use it as systick. Then you can reduce HCLK during sleep.

[Tesla DeLorean]

Can't you adapt the SysTick count as you alter the speed.​

[Lukasz Przenioslo]

Hello, thank you for answers.

@Uwe Bonnes​ it seems that it is not possible to use LPTIM as system timebase source:

Also, it seems that the only sources I can use for LPTIM clocking are not precise ones...

@Community member​ the way I understood the datsheet is that the systick base is factory calibrated for 80 Mhz / 8 usage with this MCU and by altering the base I wont get exact timing?

[Tesla DeLorean]

I don't even know that ST sets that constant. Any way ARM suggests providing a default value, but you get to program whatever you want for the period, so the frequency of the CPU and if the ticker fires at 1 KHz or something else is entirely up to you.

​

The point with the LPTIM is you could use it or the RTC to provide the HAL timebase​, you're not tied to SysTick. Even RTOS should be workable with a different periodic IRQ.

[Lukasz Przenioslo]

Ok, now I see the point.

Ideally, I was wondering about such idea: reduce the HSE osc frequency as much as I can (4 Mhz crystals are there, 2 Mhz are probably findable too). In "regular mode" just use PLL abd default settings for 80 Mhz operation with systick. In the "dormant mode" modify the timing registers to clock everything without any PPL, directly from HSE. In that case it would be 2-4 Mhz for the systick and I would have to modify the registers to keep the 1 ms time base (the same for other timers if used). What do you think?

[Uwe Bonnes]

Or resync system clock on wakeup with RTC.

[Jack Peacock_2]

If you are looking to switch to SLEEP low power mode while idle then an active SysTick is not your friend. The FreeRTOS website has a lot of details on running a "tickless" RTOS timebase in order to get the most benefit from SLEEP mode.

The problem is you only sleep for a maximum of the SysTick interrupt period, which isn't very long. You aren't going to see a dramatic difference in power consumption because the core is constantly waking up to handle SysTick interrupts, without actually accomplishing any useful work. If you use the RTOS tickless mode you get the maximum benefit from idling the core while sleeping. The core stays idle until a timeout (scheduled task wakeup) or an external event occurs. The difference is you sleep the core for seconds or even minutes at a time, rather than milliseconds.

RTOS tickless mode also allows you to implement STOP low lower mode if your hardware connections allow for it. That has a dramatic effect on battery life.

And if you do go with dynamic frequency scaling be sure to adjust the core voltage after you drop to a lower clock rate. If you check the data sheets you'll see it makes a difference.

[Lukasz Przenioslo]

Thank you for answer Jack,
In general I am looking for any options to reduce power consumption with freertos now. In my application I am going idle for intervals of around from 30 seconds to 5 minutes. Even though the mcu doesnt do anything specific in that dormant petiod, the systick time has to be kept- the whole system bases on that systic variable value. Thats why I thought reducing the clock speed, wgile maintaining the systick frequency of 1k would be least "invasive".

[Geoffrey1]

It might be easier to use ChibiOS which is designed to support "tickless" operation. As a point of reference, using an stm32l432 with an external RTC from microcrystal (rv-8803-c7) as a 1khz input to the stm32l432 RTC. I measured 430nA in standby at 2.4 v (520nA at 3v). Stop2 would be more like 1.7uA, but has some advantages. "Wakeup" from standby is more complicated because it looks like a reset, which requires a somewhat more complex system architecture.

It wasn't clear from your notes what your timing needs are. If you need a precise high speed oscillator, when in "run" mode, then you might consider powering it down in your long sleep periods.

[Lukasz Przenioslo]

Hi Geoffrey, thabks for answer.
The point is here that in my idle periods I dont really want to be asleep. I will still need to have systick running and react to external event. I just dont need the full blown 80 Mhz computing power. I think 1 Mhz would be enough without powering the peripherals off.
Also I cant really go ChibiOs bow from FreeRtos, the project is in way to advanced stage.

[Geoffrey1]

Fair enough. It was a little hard to be sure what your requirements are, for example interrupt latency. Best of luck in your quest to save power -- always a rocky and interesting road.

[S.Ma]

On the stm32f437, it is possible in the clock tree to modulate syclk while keeping peripheral clock fixed IF it has been chosen to be the lowest possible.

This way you can even cranck-up the gearbox only in interrupts...

[Lukasz Przenioslo]

Hi, thanks for answer.
Could you elaborate a bit more what you have in mind?

[Jack Peacock_2]

FreeRTOS tickless mode does exactly what you want. The SysTick timebase is preserved, any tasks delayed for specific periods or timeouts will still respond at the right time, and any external interrupt will exit low power sleep mode. Unlike stop and standby mode there are no limitations on wakeups and clocks.

Sleep mode halts the processor clock, far more power efficient than just slowing down the clock rate. The instruction clock, but not PCLK for peripherals, is halted. The core exits from sleep mode very quickly after any external interrupt occurs. Tickless mode updates the FreeRTOS tick count for total elapsed time while asleep.

What you save here is the power consumed by the core while executing instruction in idle mode, for the total length of the idle period, not just fragments between systick interrupts. Its far less complicated than frequency switching. Saves more power too...after all, zero Mhz will always consume less current.

The sleep mode core implementation is one thing ST does much better than most of its low power M class competitors, especially on the L4 series, and FreeRTOS takes full advantage of it. If you're using battery power don't ignore it.

Jack Peacock

[Lukasz Przenioslo]

Jack, thank you for in depth explanation.
This would seem to be a great feature, but I see one problem. In my application, the time for which the system is in idle state is calculated by FreeRtos delay function, which needs the counter values from ticks. If there are no ticks, I cannot wake up from idle. Do I understand correctly?

[zsellera]

There's a project that use LPTIMx as the tick timer: this way you can have FreeRTOS ticks updated even in STOPx modes (it's what you need imho).

Changing SYSTICK prescaler (/1 or /8) is nice if you want to run occasionally faster, but you're generally fine at lower speeds. It offers a limited gain only compared to STOP mode sleep states (ie: sleep @64 MHz ~1.4 mA; sleep @8 MHz ~0.3 mA; while stop2 is lower than ~10uA). Anyway, this exactly what I needed recently. This is my blog post with implementation details on it (changing voltage scaling, flash latency, tuning pll, etc).

[Lukasz Przenioslo]

Hi @zsellera​ ,

Thank you for suggesting this solution- wish I had it at the time of dealing with my problem :). Will surely remember about it for the next project.