STM32 LPTICKER with RTC : better sleep time #8777

jeromecoutant · 2018-11-16T14:29:20Z

Description

With current implementation, as the WakeUp timer is a 16 bits counter, the maximum sleep duration is about 2s.

Idea is to decrease WakeUp clock source frequency for "long time".

Pull request type

[x] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

mbed-ci · 2018-11-18T09:54:57Z

Test run: FAILED

Summary: 4 of 7 test jobs failed
Build number : 2
Build artifacts
Build logs

Failed test jobs:

jenkins-ci/mbed-os-ci_mbed2-build-IAR
jenkins-ci/mbed-os-ci_mbed2-build-GCC_ARM
jenkins-ci/mbed-os-ci_mbed2-build-ARM
jenkins-ci/mbed-os-ci_build-ARM

0xc0170 · 2018-11-19T14:52:30Z

@jeromecoutant The above is a test run (don't mind it at the moment). I'll restart jenkins CI now

mbed-ci · 2018-11-19T15:43:38Z

Test run: FAILED

Summary: 4 of 7 test jobs failed
Build number : 3
Build artifacts
Build logs

Failed test jobs:

jenkins-ci/mbed-os-ci_build-ARM
jenkins-ci/mbed-os-ci_mbed2-build-IAR
jenkins-ci/mbed-os-ci_mbed2-build-GCC_ARM
jenkins-ci/mbed-os-ci_mbed2-build-ARM

cmonr · 2018-11-22T02:15:47Z

Restarting CI

mbed-ci · 2018-11-22T10:24:46Z

Test run: SUCCESS

Summary: 4 of 4 test jobs passed
Build number : 4
Build artifacts
Build logs

0xc0170 · 2018-11-22T10:30:52Z

@OPpuolitaival Please review test failures (test run success ?)

0xc0170 · 2018-11-22T10:34:32Z

We will restart CI but after reviews are done and having some 5.11 items in.

0xc0170 · 2018-11-26T10:46:18Z

reviewers please review this PR

LMESTM

only one question - otherwise looks good

LMESTM · 2018-11-26T10:47:08Z

targets/TARGET_STM/rtc_api.c

+            WakeUpCounter = WakeUpCounter/2;
+
+            if (WakeUpCounter > 0xFFFF) {
+                WakeUpCounter = 0xFFFF;


In case where wake-up is pushed to the upper limit, it means that we cannot sleep as much as was requested right ?
Is it then expected that higher layers (mbed-os core) takes care of synchronizing os-time again ?

Wake up can always be early, due to other wakeup sources than time. As long as the HAL reports how long it actually slept, that's fine, from the OS's point of view.

The common ticker layer can safely handle early wakeups, but the LowPowerTickerWrapper does not. It treats early interrupts as spurious interrupts and ignores them.

To prevent this I recommend adjusting the supported bits from lp_ticker_get_info to match what you can safely set. This way the common ticker layer will always schedule a wakup time the hardware can achieve. In the case of maximum clock division (1/4th normal speed) with a 16 bit counter that would be .bits=18. This value is currently set to 32 bits which can cause failures.

Isn't .bits=18 still a little off? Can't actually schedule 0x3FFFF, only 0x3FFFC. Is that significant enough to matter?

OPpuolitaival · 2018-11-26T11:19:40Z

Test failed because of broken hardware. The board is taken off from CI and now restarted the test

0xc0170 · 2018-11-28T11:02:19Z

@LMESTM @c1728p9 Please finalize your reviews

jeromecoutant · 2018-11-28T11:58:38Z

Hi
This PR needs work.
Either:

LowPowerTickerWrapper mbed-os update to safely handle early wakeups
or/and update to declare 18 bits as indicated by Russ
or update in the set interrupt function to support 32 bits

kjbracey · 2018-11-29T12:55:59Z

One question about performance here - how significant is the power saving of 32s versus 8s versus 2s sleep time? (And as part of that calculation, how long do we spend awake each time?). What would the saving be if we achieved much higher or unlimited time?

mattbrown015 · 2018-11-29T13:18:32Z

how significant is the power saving of 32s versus 8s versus 2s sleep time?

Whether or not something is significant is difficult to quantify, justify and/or state categorically!

But, I looked at this for myself the other day and can give you some figures.

I'm using a STM32L4 and measured the wake up time as a little over 2 ms.

The sweet spot for our application is waking up and taking a measurement every 10 minutes. To take and transmit the measurement we spend less than 100 ms in Run mode.

So for 8s we spend ((10 * 60) / 8) * 2 = 150 ms in Run mode only to decide to go back to sleep. For 32s it becomes ((10 * 60) / 32) * 2 = 37.5 ms. Over a 100 ms not in Run mode feels worth it to me.

Obviously hours, or even days, would be much better for the situations where the sample interval is reduced but I can see why this would be difficult to achieve while maintaining accuracy.

kjbracey · 2018-11-29T13:23:12Z

I am kind of asking because I'm trying to justify (or not) some sort of API extension which would permit 1 second granularity, which would then presumably open the door to much longer sleeps here.

In STM, can we sleep with 1s wakeup precision to get a longer range (RTC alarm), but still get a <1ms precision measurement of sleep time? Or would we lose sleep time measurement precision too?

LMESTM · 2018-11-29T13:37:54Z

Last time I had this discussion, users were asking for an RTC Alarm API.
I thnk that the RTC Alarm API would allow long period of sleep without wake-ups and is pretty intuitive to understand by users. Several users have asked for it in past years.
This may need mbed-OS core to be able to not schedule any wake-up timer at all ?
Whether power saving would be significant is hard to tell, but this is a recurring request ...

kjbracey · 2018-11-29T14:06:52Z

The two possibilities I'm looking at initially are

 suspend(seconds)

so potential for rtc alarm to be built-in to the call, or maybe

rtcalarm->set(seconds)
suspend()

So no built-in suspend wakeups, just whatever wakeup sources you have.

I'm inclined to go for the first, as it can be implemented using existing LPTimer. Use of RTC alarm could be added under the surface.

Getting the automatic idle to also have that RTC alarm potential under the surface would also be possible, but would probably require the ability to provide an accurate measurement of how long the sleep period actually was, even if the wakeup had 1-second granularity. Whereas for an explicit suspend we could just document the potential of 1 second system clock drift.

LMESTM · 2018-11-29T14:15:44Z

I like the RTC alarm idea because application may rely on a RTC alarm handler to be called,
whether the application is just back from suspend or was already awake when the alarm expires ...
So my 2 cents: I like your 2nd proposal better :-)

kjbracey · 2018-11-29T14:26:37Z

I feel you, but one of my design goals is getting suspend working without the requirement for HAL changes... Leveraging that to overcome the 16-bit * 10ms limitation on STM is a side bonus.

As for the alarm handler, Mbed OS already has a lot of ways to get a callback at a specific time - I'm not yet convinced there's a separate need for an API requesting a callback specifically directly from the RTC handler peripheral. Something more under-the-surface could potentially cope better with latency, such as with the latency stuff.

ThisThread::wait(1000) can pre-fire the LPTicker early to ensure an accurate wakeup, whereas requesting 1000 directly from the LPTicker will get you there late if coming from deep sleep. Same logic could apply for using the RTC alarm to wake up within a second of the correct time, then a lpticker to hit more precisely.

jeromecoutant · 2018-12-11T16:09:38Z

Can we start CI ?
Thx

cmonr · 2018-12-11T19:12:46Z

Marked as needing CI.

Waiting for RC3 PRs to wrap up before starting CI for 5.11.1 PRs.

cmonr · 2018-12-12T03:20:07Z

CI started

mbed-ci · 2018-12-12T06:45:35Z

Test run: FAILED

Summary: 1 of 11 test jobs failed
Build number : 5
Build artifacts

Failed test jobs:

jenkins-ci/mbed-os-ci_exporter

0xc0170 · 2018-12-12T09:01:43Z

Pipe closed in CI, restarting exporters

0xc0170 · 2018-12-12T13:41:04Z

This looks ready from CI point of view but not reviewers.

Reviewers, please review

cmonr · 2018-12-12T19:50:16Z

@kjbracey-arm @c1728p9 Mind doing a quick re-review? This appears to be ready aside for final checks.

cmonr · 2018-12-19T22:30:02Z

Rerunning CI since it's been more than a week.

cmonr · 2018-12-19T22:31:42Z

CI started

mbed-ci · 2018-12-20T01:26:27Z

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 6
Build artifacts

kjbracey · 2018-12-21T11:40:29Z

This introduces issue #9176, fixed by #9180.

mattbrown015 · 2019-01-16T09:33:49Z

Hi @jeromecoutant ,

I've found a problem with this which really deserves a new issue. I'm busy doing other things so I'll just mention the problem with the expectation that you're not actually going to do anything!

I've found this change affects our event scheduling accuracy. When scheduling events for only a minute or 2 in the future it sometimes starts selecting the least accurate wake-up clock.

It is repeatable but I haven't had time to investigate. I've stopped it selecting RTC_WAKEUPCLOCK_CK_SPRE_16BITS in order to keep our scheduling working how we want it.

My feeling is that the problem isn't with what you've done. I suspect that the RTOS starts misjudging the sleep time and calls rtc_set_wake_up_timer with a number that is too big.

cmonr · 2019-01-17T00:06:19Z

with the expectation that you're not actually going to do anything!
Well that seems a bit rude...

Wouldn't fault him considering comments in a closed PR aren't tracked. In the future, please open issues instead of commenting in closed/merged PRs.

mattbrown015 · 2019-01-17T09:00:14Z

Well that seems a bit rude

Sorry, I didn't mean to be rude. I certainly didn't intend to imply any criticism of the ST or Mbed teams.

Rather I meant, I wasn't expecting @jeromecoutant to start an investigation based on my vague and incoherent ramblings.

If this was more important to me I'd do some more investigation, gather some evidence and try and write a coherent issue. I haven't got time to do that now and I'm not expecting @jeromecoutant to do it for me.

But, I mentioned it in case @jeromecoutant sees, or hears about, something funny and perhaps things will start adding up into something a bit more tangible!

I was actually trying to avoid making a fuss and work for everyone. I've completely failed in that regard!

cmonr · 2019-01-17T18:25:59Z

Thanks for the clarification.

Sarcasm over a text-only medium is hard 😄

cmonr requested review from c1728p9 and LMESTM November 16, 2018 16:20

cmonr added the needs: review label Nov 16, 2018

jeromecoutant mentioned this pull request Nov 26, 2018

How to Achieve Long Periods of Deep Sleep on STM32 #7156

Closed

LMESTM reviewed Nov 26, 2018

View reviewed changes

cmonr added the release-version: 5.11.1 label Nov 26, 2018

0xc0170 added needs: work and removed needs: review labels Nov 28, 2018

jeromecoutant mentioned this pull request Nov 29, 2018

LowPowerTimeout Broken #8906

Closed

cmonr added needs: review and removed needs: work labels Nov 29, 2018

STM32 RTC : skip rtc_write if possible

9da5e48

cmonr added needs: CI and removed needs: review labels Dec 11, 2018

0xc0170 added needs: review and removed needs: CI labels Dec 12, 2018

c1728p9 approved these changes Dec 19, 2018

View reviewed changes

cmonr added needs: CI and removed needs: review labels Dec 19, 2018

cmonr added ready for merge and removed needs: CI labels Dec 20, 2018

0xc0170 merged commit 99778bd into ARMmbed:master Dec 20, 2018

jeromecoutant deleted the PR_LP_RTC branch December 20, 2018 12:00

cmonr removed the ready for merge label Dec 20, 2018

mattbrown015 mentioned this pull request Dec 20, 2018

STM32: RTC No Longer Enabled by Reading the Time #9176

Closed

kjbracey mentioned this pull request Dec 21, 2018

Revert "STM32 RTC : skip rtc_write if possible" #9180

Merged

mattbrown015 mentioned this pull request Jan 15, 2019

STM32L4: Adjusting RTC Synchronisation When Using MBED_TICKLESS in RTC Mode #7695

Closed

STM32 LPTICKER with RTC : better sleep time #8777

STM32 LPTICKER with RTC : better sleep time #8777

Conversation

jeromecoutant commented Nov 16, 2018

Description

Pull request type

mbed-ci commented Nov 18, 2018

0xc0170 commented Nov 19, 2018

mbed-ci commented Nov 19, 2018

cmonr commented Nov 22, 2018

mbed-ci commented Nov 22, 2018

0xc0170 commented Nov 22, 2018

0xc0170 commented Nov 22, 2018

0xc0170 commented Nov 26, 2018

LMESTM left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

OPpuolitaival commented Nov 26, 2018

0xc0170 commented Nov 28, 2018

jeromecoutant commented Nov 28, 2018

kjbracey commented Nov 29, 2018

mattbrown015 commented Nov 29, 2018 • edited Loading

kjbracey commented Nov 29, 2018

LMESTM commented Nov 29, 2018

kjbracey commented Nov 29, 2018 • edited Loading

LMESTM commented Nov 29, 2018

kjbracey commented Nov 29, 2018

jeromecoutant commented Dec 11, 2018

cmonr commented Dec 11, 2018

cmonr commented Dec 12, 2018

mbed-ci commented Dec 12, 2018

0xc0170 commented Dec 12, 2018

0xc0170 commented Dec 12, 2018

cmonr commented Dec 12, 2018

cmonr commented Dec 19, 2018

cmonr commented Dec 19, 2018

mbed-ci commented Dec 20, 2018

kjbracey commented Dec 21, 2018

mattbrown015 commented Jan 16, 2019

cmonr commented Jan 17, 2019

mattbrown015 commented Jan 17, 2019

cmonr commented Jan 17, 2019

mattbrown015 commented Nov 29, 2018 •

edited

Loading

kjbracey commented Nov 29, 2018 •

edited

Loading