STM32L0 RTC wakeup time offset (in STOP mode)

[koenvv]

Posted on November 12, 2015 at 02:36

Hi,

I'm using an STM32L051R8 clocked off HSI 16Mhz and with a 32.768KHz external crystal (LSE) that drives the RTC and an LPTIMER.I have set the RTC to generate periodic wakeup interrupts every X seconds, just before I enter STOP mode by __WFI()  I enable the LPTimer. When woken up I read out the timer count to know how long I was in STOP mode. I always see a delta of -10ms between the expected time (ie: 1 second) and the LPtimer count (990ms). I tried different sleep times (RTC wakeup periods) and the offset keeps quite constant; it doesnt scale over time. ex: 1 second <-> 990ms LPtimer2 seconds <-> 1991ms LPtimer10 seconds <-> 9990ms LPtimer60 seconds <-> 59991ms LPtimerLPtimer is having a 32x prescaler off LSE so it should count 1024 ticks/sec. I convert from ticks to ms by (ticks *1000) /1024 I checked with an oscilloscope and confirmed the actual time is less than 1 second (measured 995ms on scope). So my question now is: why is the timing offset by -10ms ? I would expect it to be a marginal positive offset as there is always some wakeup from stop mode latency, interrupt latency and it has to execute the IRQ for the RTC and then it can read out the LPTimer count twice before the calculation is made.Is this a known issue? Which one is correct LPtimer or RTC? RegardsKoen

[Tesla DeLorean]

Posted on November 12, 2015 at 02:54

Ok, but the granularity of the RTC is one second, have you looked at where the sub-second count is at? Not sure if this is read-able on the L0, not using it.

If you toggle an LED on the 1 Hz RTC wakeup, do you get a 2 Hz square wave? Or time stamp the consecutive entry times. If it takes 10ms to startup, and you advance the RTC wakeup for 10 seconds, the sleep time will be 9.990 ms right? Not sure a phase offset is unexpected, what it is might be a topic for debate.

[Tesla DeLorean]

Posted on November 12, 2015 at 02:59

Pretty sure it's never going to be positive, time always advances, the RTC is already 10ms into the future before your code does anything, by my interpretation of the phenomenon you are describing.

[koenvv]

Posted on November 12, 2015 at 04:04

Hi Clive,

Subsecond counts are not always similar before and after the STOP mode; 1 sec RTC wakeup subsecond registers:0xFF before and aft the first time; LPtimer reported 994 ms (1018 ticks)0xFE the second time; LPtimer reported 990ms (1014 ticks)0xFE before and 0xFF after the consecutive times; LPtimer reported 990ms (1014 ticks)This shows a resolution of 1/256second for the RTC internally (which is right given the prediv settings).

When not entering stop mode The RTC_IRQHandler is called at timestamp (999, 1999, 2999...); timestamps are generated by LPTimer counter. So no offset there.

As an experiment I went to sleep halfway a second (subsec at 126) Then I get very strange behavior; LPTimer now consistently reporting sleep times of 1490ms (target = 1000ms). And randomly the subsec count after is 126 or 255.When I enter sleep 3/4th into a second I get 1240ms worth of sleep time and the subsec count is 62 before and randomly 62 or 255 after. So it seems to always run 990ms + carrying over an offset towards the next whole second. 

[koenvv]

Posted on November 12, 2015 at 12:58

OK I found a small bug in my code; when loading the RTC->WUTR register you have to subtract one period. (1 second in my case)

So now I have it set to 5 seconds (RTC->WUTR = 4); I sleep for 4990ms; which means my code between waking and going to sleep again just takes 10ms to execute. So the sleeptime is 5000 - 10 = 4990 as expected.When I add a code delay of 500ms (simulate execution of 10+500ms for example) the sleep time becomes 4490ms which is correct as it is the remaining time till the next 5 second wakeup period.