How to Achieve Long Periods of Deep Sleep on STM32

[mattbrown015]

Description

I'm working on a battery a powered application and therefore power consumption is very important. Our board is based on a STM32L4.

I'm looking for a better description and/or an example of how to use Mbed OS with long periods of deep sleep because our application may may go hours or even days with nothing to do.

I've defined MBED_TICKLESS and I can see deepsleep() being called.

If I leave MBED_CONF_TARGET_LOWPOWERTIMER_LPTIM as 1 it appears we wake up every few seconds even if the wait is much longer. I'm guessing this is because the maximum timeout of LPTIM1 is only a few seconds.

I changed MBED_CONF_TARGET_LOWPOWERTIMER_LPTIM to 0 and I can see this changes the behaviour but I've no understanding of the ramifications. Is this the correct approach?

Any thoughts greatly appreciated.

I last updated my mbed-os clone on 22 May 18:

commit 3bcc076c0c08a4f411bfbeb9fcf173bb1343cd8c (HEAD -> master, origin/master, origin/HEAD)
Merge: 261f73fbf b30f3abf1
Date:   Tue May 22 14:56:37 2018 -0500

Issue request type

[X] Question
[ ] Enhancement
[ ] Bug

[0xc0170]

cc @ARMmbed/team-st-mcd

[bcostm]

Related issue #6081

[ciarmcom]

ARM Internal Ref: MBOTRIAGE-581

[0xc0170]

Related issue #6081

That is correct. For longer periods, we shall consider an enhancement to the current solution. What I did not understand was the difference between MBED_CONF_TARGET_LOWPOWERTIMER_LPTIM values, as asked above. 1 or 0.

The question is, how to achieve the longest sleep with the current solution we have, what are limitations for STM32L4 (or is this generic to any mbed target, no further limitation from target implementation) ?

[mattbrown015]

The question is, how to achieve the longest sleep with the current solution we have, what are limitations for STM32L4 (or is this generic to any mbed target, no further limitation from target implementation) ?

I think that is the question I'm asking!

The related issue asks for a shutdown mode. I'm not bothered about selecting the shutdown low-power mode. As I understand it, hal_deepsleep() is selecting stop 2 low-power mode for the STM32L4 and I think that will give us what we need; we just need to spend most of the time in stop 2.

[Alex-EEE]

I second needing an answer to this question. We also want deep sleep for days at a time.

[brandond]

Same here. Looking for extended deep sleep on STM32F1. Hoping to use LowPowerTicker on PlatformIO with mbed , which I understand is an additional complication.

[mattbrown015]

As no one who really understands has taken the bait so I'll make a couple of comments and see if it leads anywhere.

My guess is there is some balancing of power vs accuracy. If we want to sleep for longer the wake-up is likely to be less accurate. Someone in the Med or ST teams has tried to a create a general solution that is a reasonable compromise.

targets/TARGET_STM/lp_ticker.c configures LPTIM1 and selects LPTIM_PRESCALER_DIV2. I guess a different prescaler could be used to give a longer time before wrap around but I don't know how well the rest of the RTOS would cope with this. Even at the maximum prescaler the wrap around is still only seconds and hence I don't know how significant this would be be.

AFAICT, when both LPTIM1 and RTC are both available LPTIM1 is preferred. I assume this is because it provides better accuracy than the RTC although the RTC can create events over hours. Is this correct? If so what is the difference in accuracy? How far in the future can an RTC event be created?

[mattbrown015]

This was effectively a cross-post of a https://os.mbed.com question, deepsleep - LPTIM1 Vs RTC on STM32?, and I've just had an answer there.

In summary, because the LPTIM1 is only 16-bit on the STM32L4 it is necessary to use the RTC.

I haven't looked to see if other STM32 devices have a wider LPTIM1.

I'm going to post to deepsleep - LPTIM1 Vs RTC on STM32? again and I'll close this issue once I think I understand!

[jeromecoutant]

Hi @mattbrown015 and all

I am going to try to answer few questions about LPTIM versus RTC...

• LPTICKER mbed feature can be mapped on RTC wake up timers for most of STM32 chips (all except F1 and F2 families)
• LPTICKER can be mapped on LPTIM timers for "only" L0, L4, F7 and few F4 STM32. For targets using this mode, RTC feature can be removed.

LPTICKER configuration:

• RTC mode: frequency is 8192 Hz with a 32 bits timer. This provides a 122us precision and a sleep time about 145h
• LPTIM mode: frequency is 32768 Hz with a 16 bits timer. This provides a 30us precision and a sleep time about 2s

RAM/FLASH :
I compiled the same application with a L475 DISCO board

• RTC mode: RAM 9572 bytes, FLASH 50101 bytes
• LPTIM mode: RAM 9584 bytes, FLASH 47381 bytes

Execution time:
I tried to measure time spent in different functions (measured with a soft ustimer).

• RTC mode: read function takes around 7us, setting a wake up timer 20us, 108us if timer was already set
• LPTIM mode: read function takes around 5us, setting a wake up timer 5us, 75us if timer was already set

I let you make the conclusion...

[jeromecoutant]

About TICKLESS, goal is of course to enable it for all STM32 as soon it is possible.
But we still got some issues with that, please follow #7328

[jeromecoutant]

About long period of deep sleep, our advice would be to use the RTC alarm feature.
But unfortunately, MBED doesn't provide any API for that yet...

[mattbrown015]

Hi @naveenkaje and @jeromecoutant, I feel bad about cross posting but thanks to both your efforts I believe I understand better now.

From your advice it is now my belief that MBED_TICKLESS and RTC mode is best choice for my situation, i.e. battery powered STM32L4 and long periods of inactivity.

In future I will stick to asking questions here, it feels to me that questions on the Mbed forum get less attention.

Thanks, Matt

[rohithreddykota-npsc]

using LPTIM = 32768Hz and prescalar as 128 we can further reduce the clock right?

[jeromecoutant]

using LPTIM = 32768Hz and prescalar as 128 we can further reduce the clock right?

See https://os.mbed.com/docs/v5.10/porting/low-power-ticker.html
minimum frequency has to be 8KHz, so prescalar can be 4.

[mattbrown015]

Hi @jeromecoutant, I'm looking at my sleep time again!

After instrumenting hal_deepsleep I realised that my STM32L4 comes out of deepsleep every 8 seconds.

This surprised me because your comment above made me think it could stay in deepsleep for hours:

RTC mode: frequency is 8192 Hz with a 32 bits timer. This provides a 122us precision and a sleep time about 145h

After a bit of investigation I realised that you're using the STM32L4 auto wake-up counter, aka 'wake-up timer', see rtc_set_wake_up_timer.

(As you know) This is a 16-bit down-counter providing a maximum interrupt period of 32 s. You're using RTC clock divided by 4 hence the maximum deepsleep period of 8 s.

In #8778 you've made it possible to configure the LPTIM clock divider and say that selecting 4 gives a deepsleep time of about 8 s. I assume making the divider bigger is not an option because it is not accurate enough(?).

All this means I'm no longer sure what the correct approach is. If the maximum deepsleep time is that same for the RTC and LPTIM I guessing it's better to use the LPTIM(?).

On Monday I'll try switching back to the LPTIM and see what happens.

[jeromecoutant]

Hi @mattbrown015
Could you check #8777 ?

[mattbrown015]

Ah, yes, that looks better! :-)

I will actually try it later.

Let's see if I now understand correctly...

Fundamentally the longest possible deepsleep when using the RTC wake-up timer on STM32L4 is 32s.

Theoretically it could be possible to deepsleep for longer using the RTC programmable alarms but this would not work with Mbed OS because they don't tick with the required accuracy.

#8777 chooses the RTC clock divider based on the expected length of sleep. This should balance sleeping for as long as possible with maintaining the tick accuracy. 👍

Once #8777 is tested and merged the RTC will provide an advantage over the LPTIM because we'll get a 32s deepsleep instead of 8s