[STM32L4][RTOS] Need a 32-bit register as a counter for RTOS's system tick

[TNguy.19]

Hi everyone,

I'm using STM32L4R9 to develop product which run on RTOS kernel. Previously, I used a other Cortex-M4 chip run on RTOS platform in tickless mode, a 32 bit timer counter is used for calculate RTOS tick and this timer-counter able run on lowest power mode when kernel is idle.

Now I switch to STM32L4R9 and the deepest mode that my system can get in is STOPMODE2, at this state only LPTIM is run/wakeup with clock source LSI/LSE, however this LPTIM just support a 16-bit counter register which is easy to get full which configure 1000 tick per second.

I also thought to use RTC as a main counter but it's configured in BCD.

So if I really need a 32 bit counter register in STOPMODE, which peripheral I can use to help RTOS kernel run on?

Thanks.

[Uwe Bonnes]

Can you schedule a wakeup at timer overflow? That would relief the > 16 bit requirement at the cost of additional wakeups. It is also a pity that the STM32 recent RTC IP has non continuous counter!

[Jack Peacock_2]

There is a way to use the RTC if you include the subseconds register in the L4, assuming the RTOS tick rate is greater than RTCCLK frequency driving the subsec counter, and the RTC oscillator continues to run in your STOP mode.

In tickless mode you have to determine elapsed RTOS ticks from sleep/stop to wakeup. Before entering STOP mode take a snapshot of the subseconds, time and date registers (it's atomic if you read date last). When you wake up do a second capture of the same RTC registers. Convert these two values to the equivalent RTOS ticks and you have the elapsed time as the difference.

If you have an wakeup time limit (i.e. FreeRTOS) you can still use the RTC wakeup timer, or set an RTC alarm to generate a wakeup event.

In practice it's a little more complicated, since you have to allow for unexpired time from the regular tick timer (fractional ticks do add up) plus cumulative overhead in the tickless routine while switching between tick timers..

No intermediate overflow interrupts to handle so you get the maximum low power mode benefits. And yes, it would be nice if LPTIM was 32-bit, make life a lot easier.

Jack Peacock

[waclawek.jan]

Wouldn't the prescaler in LPTIM help?

JW

[Jack Peacock_2]

The prescaler can be used to approximate the tick resolution, but if it's scaled to a longer time period then RTOS ticks get lost. So if the systick is 5msec and the prescaler is to something around a 5msec tick, 64K ticks yields 327 seconds, around 5.5 minutes. The idea is to drop down to STOP mode to save power, so waking up every 5 minutes when the delay may actually be 6 hours up to several days (from a real world app, equipment in a hospital room that's only active when room lights are on) that's a significant amount of wasted battery power for all the unnecessary wakeups, especially if the battery is supposed to last for weeks at a time.

Jack Peacock

[TNguy.19]

Hi JW,

I also thought ab this but with configuration 1000 tick per second so I need smallest resolution for every tick is 1ms (2^16 / 1000 ~ 65 second). So after every 65s, the timer is overflow so it's a bit dificult if we schedule a timer > 65s, the system is wakeup unexpected.

Thank for your caring.

[TNguy.19]

Hi Jack,

It's a good idea but system that I'm working on is a bit critical, so it need to be configured 1000 tick per second. Then it will wake up every ~65s even if kernel is idle, more than that we have to cover if timer counter overflow very well, cause it may lead to many coner case/race condition.

I saw you comment ab using RTC is main counter. Technically, subsecond register is 16-bit and with config 1000 tick per second, I think it will behave the same with LPTIM. Alarm interrupt is also a good idea, we can configure the clock in RTC and prescaler to make RTC run slower 1000 time, the we have 1ms resolution, however convert from BCD to decimal I think it not a very good choice.

Thank you for spending your time on my problem :)

[TNguy.19]

You're right.

Actually, the more the chip wakes up to re-calculate tick when counter is overflow, the more possibily system can get faut (corner case, race condition ...). Btw, we also need Power profile of system, if chip wake up usually because of counter's overflow, it will make a little bit confusing when we analyze power.

Thank you