cpu/stm32l0: power management updated #7329

Marc-Aurele · 2017-07-07T08:04:40Z

Now, stm32l0 is able to go in sleep and stop mode. By default, low power modes are deactivated.

aabadie · 2017-07-07T09:02:40Z

cpu/stm32l0/include/periph_cpu.h

+
+/**
+ * @brief   Override the default initial PM blocker
+ * @todo   we block all modes per default, until PM is cleanly implemented


What is missing with PM to be 'cleanly implemented' ?

i let the comment how it was specified for the other CPUs. But, the functions such as pm_block, pm_unblock seems to work on my side, so i don't know what is missing. (for example, at start up, i have made a pm_block(0) to prevent the CPU from going into standby mode)

But, for now, i'm still facing an issue, when my CPU is in stop mode, i have configured the RTC to trigger an alarm and wake up the CPU every 1 second, but the scheduler stop running the tasks and goes back immediatly in stop mode, moreover UART is printing wrong character at wake up.
Am i missing something or doing something wrong ? Is it possible to use RIOT with stop mode activated !

Am i missing something or doing something wrong ? Is it possible to run RIOT in stop mode ?

In theory yes. Maybe @kaspar030 can give a more precise answer.

The "stop mode" is working fine even if i need to do a clk_init in my RTC callback so that the UART continues printing characters. So this patch could be merged as "stop mode" is not activated by default.

The issue is that xtimer (based on TIM2) is stopped in stop mode, @aabadie do you thing it is possible to associate xtimer with low power timer (LPTIM1) from stm32l0 so that we still have a time base running in stop mode ?
For now, i need to use thread_sleep/thread_wakeup that is not the best way to schedule my tasks.

Do you thing it is possible to associate xtimer with low power timer (LPTIM1) from stm32l0 so that we still have a time base running in stop mode ?

I don't know. Maybe @haukepetersen or @kaspar030 have an idea since they are working on an improved version of the xtimer that is able to work in low power modes (IIRC) ?

Marc-Aurele · 2017-07-09T10:57:06Z

Thx,

Here is my status :

I saw that i need to do a "clk_init" after going out of stop mode. Is it right ? I'm doing it in the RTC interrupt but it should be preferable to do it in the "pm_set" function.
Is there exemples of RIOT associated with stop mode on STM32L of F family ?
Then, as the timers are stopped, all tasks that are calling xtimer_usleep are freezed. How timing can be handled in stop mode and how a task can be stopped and started again for a while ?

Thank you in advance, if you have any idea about a possible issue or a missing configuration, don't hesitate to share it ;)

Marc-Aurele · 2017-07-13T12:41:27Z

@aabadie I saw that @vincent-d is working on the implementation of low power timer for stm32f4. That's exactly what i wanted to start but i was a little bit lost as i'm quite new with RIOT. Once, it will be merged, i will port his patch on stm32l0 family.
By the way, do you think this patch could be merged ?

aabadie · 2017-07-13T13:08:11Z

@Marc-Aurele, first thanks for working on this topic which is very important with Low power MCU like L0.

As you can noticed in #7351, other people are interested in this subject. On my side, I have a very limited knowledge on that (but I'm also interested) so I can't really help.

There's obviously room here for putting a common effort on this subject in order to reach a good (enough) solution.

cc'ing @kaspar030 @haukepetersen and @vincent-d who are the ones that could help the best (I think).

Marc-Aurele · 2017-07-22T09:33:13Z

Hello,

I have rebased my patches. I think this patch can be merged as it is if you don't see anything wrong since low power mode are deactivated by default. Anyway, stop mode and sleep mode are working very well on stm32l0 when pm_layered feature is activated.

Regards,

Marc-Aurele · 2017-08-08T20:31:27Z

Patch has been rebased on master

Marc-Aurele · 2017-10-18T11:03:37Z

Patch has been rebased on master and is ready to be merged

aabadie · 2017-11-07T19:23:37Z

There are conflicts on your PR @Marc-Aurele, can you rebase and fix them ?

Marc-Aurele · 2017-11-08T07:05:42Z

done

Marc-Aurele · 2018-03-02T13:35:23Z

Hi @aabadie

What is stopping us from merging this PR ? Are we waiting for something else or do i need to rework this patch. For now, L0 family cannot go in low power without thi patch.

Regards,

Aurélien

aabadie · 2018-03-02T13:40:03Z

@Marc-Aurele, still having this one somewhere in my head, don't worry. I just need to find a moment to try it.

aabadie · 2018-03-02T13:41:10Z

cpu/stm32l0/include/periph_cpu.h

+ * @brief   Override the default initial PM blocker
+ * @todo   we block all modes per default, until PM is cleanly implemented
+ */
+#define PM_BLOCKER_INITIAL  { .val_u32 = 0x01010101 }


Just asking, do you have a reference for this hardcoded value ?

It is based on the periph_cpu.h file from stm32f1 family that seems to implement the low power mode feature too.

The default value is the same, I'm wondering if it's really required here.

What this means is that there are several reasons why we MUST block PM modes. The reasons are mostly peripheral related, e.g. we don't have a flexible/dynamic way on which we can disable/enable some peripherals which SHOULD block some power modes. For instance, if we allow to go to the deepest sleep mode (peripherals off), and we make use of UART, it won't work and we have undefined behaviour, since our current peripheral implementations are unaware if we're sleeping and how deep. To solve this problem, we block by default the power modes, so the device won't go to sleep unless we say so explicitly. Until we (re)implement this conditions for all our peripherals, we need to block them by default.

we need to block them by default.

I know, but this is already the case by default ,see the link I gave

aabadie · 2018-03-09T14:16:46Z

@Marc-Aurele, I (finally) gave a test to this one. I had to rebase and allowed myself to push a few changes to your branch and now it works like a charm: I could go to standby and stop mode on a b-l072z-lrwan1 board. I also tested other applications and all worked.

If you are ok with the last changes, then we can merge this one.

Marc-Aurele · 2018-03-09T16:12:49Z

Hi,

It's ok for me.
Thank you very much for your time ;)

aabadie

Tested and works, ACK

aabadie · 2018-03-09T16:35:21Z

Looks like Murdock is down, @kaspar030 do you know what happens ?

kYc0o · 2018-03-09T16:39:48Z

I saw that i need to do a "clk_init" after going out of stop mode. Is it right ?

For now yes, this is needed to reconfigure the clocking sources for peripherals, unless peripheral's implementation is done in a way that they accept to run under low power clock sources. As far as I know, UART is the most problematic. Some CPUs feature a LPUART (Low Power UART) which is able to run in a separated clock domain, if I'm not wrong.

I'm doing it in the RTC interrupt but it should be preferable to do it in the "pm_set" function.
Is there exemples of RIOT associated with stop mode on STM32L of F family ?
Then, as the timers are stopped, all tasks that are calling xtimer_usleep are freezed. How timing can be handled in stop mode and how a task can be stopped and started again for a while ?

This is, for now, not possible using the high speed/high precision timers. xtimer gets it's base time from a given source, usually a timer running at 1MHz. In sleep mode, high speed timers are stopped, thus you also stop xtimer which has an undefined behaviour when the base timer is stopped (basically it needs a free running timer all the time).

A way to avoid it is to feed xtimer with a low power, low precision timer, usually 32.768KHz present in most boards, which is not stopped when the CPU is in a low power mode, so xtimer can still work. Take a look into the kinetis implementations to have an example.

aabadie · 2018-03-09T16:47:24Z

I saw that i need to do a "clk_init" after going out of stop mode. Is it right ?

This is done after wake up, see here.

And now that #8735 is merged, this PR updates it so it is also done automatically with stm32l0 cpus

Now, MCU is able to go in stop mode if necessary when periph_pm feature is activated. Regarding LPSDSR bit that deactivates or not regulator in stop mode, it is up to the user to set/clear this bit. In order to save power, voltage regulator can be set in low power state during stop mode but it increases wakeup time. Signed-off-by: Aurelien Fillau <aurelien.fillau@gmail.com>

aabadie · 2018-03-12T07:54:16Z

Murdock is back and now green, let's merge this one. Thanks @Marc-Aurele !

Marc-Aurele force-pushed the pm_l0 branch from 8b9c451 to 9ec3752 Compare July 7, 2017 08:29

aabadie reviewed Jul 7, 2017

View reviewed changes

aabadie self-assigned this Jul 7, 2017

aabadie added Platform: ARM Platform: This PR/issue effects ARM-based platforms Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation labels Jul 7, 2017

aabadie added this to the Release 2017.10 milestone Jul 7, 2017

aabadie assigned kaspar030 Jul 7, 2017

Marc-Aurele force-pushed the pm_l0 branch from f904f39 to c5d3051 Compare July 21, 2017 20:53

Marc-Aurele force-pushed the pm_l0 branch from c5d3051 to ee1be45 Compare August 8, 2017 20:29

Marc-Aurele force-pushed the pm_l0 branch from ee1be45 to 6dec0ea Compare September 5, 2017 09:29

Marc-Aurele force-pushed the pm_l0 branch from 6dec0ea to b6a514e Compare October 18, 2017 10:58

Marc-Aurele force-pushed the pm_l0 branch from b6a514e to 80bb7a7 Compare October 18, 2017 11:15

Marc-Aurele force-pushed the pm_l0 branch from 80bb7a7 to 9767ea4 Compare November 8, 2017 07:04

smlng modified the milestones: Release 2017.10, Release 2018.01 Nov 16, 2017

Marc-Aurele force-pushed the pm_l0 branch from 691a483 to 80a48a7 Compare January 10, 2018 09:55

smlng modified the milestones: Release 2018.01, Release 2018.04 Jan 18, 2018

aabadie reviewed Mar 2, 2018

View reviewed changes

aabadie force-pushed the pm_l0 branch from 80a48a7 to 79556ad Compare March 9, 2018 14:00

aabadie force-pushed the pm_l0 branch from 79556ad to 8d2ccd1 Compare March 9, 2018 14:04

aabadie mentioned this pull request Mar 9, 2018

pkg/semtech-loramac: semtech_loramac_send function stucked after device wakeup #8750

Closed

aabadie force-pushed the pm_l0 branch from 8d2ccd1 to c037c8a Compare March 9, 2018 16:17

aabadie approved these changes Mar 9, 2018

View reviewed changes

aabadie added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Mar 9, 2018

aabadie added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Mar 11, 2018

aabadie force-pushed the pm_l0 branch from 1bb1bfb to 0368239 Compare March 11, 2018 10:01

aabadie merged commit 89af008 into RIOT-OS:master Mar 12, 2018

fjmolinas mentioned this pull request Mar 12, 2019

cpu/stm32l1: add stop and standby modes, adds pm_layered #11159

Merged

cpu/stm32l0: power management updated #7329

cpu/stm32l0: power management updated #7329

Uh oh!

Conversation

Marc-Aurele commented Jul 7, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Marc-Aurele Jul 7, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Marc-Aurele commented Jul 9, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Marc-Aurele commented Jul 13, 2017

Uh oh!

aabadie commented Jul 13, 2017

Uh oh!

Marc-Aurele commented Jul 22, 2017

Uh oh!

Marc-Aurele commented Aug 8, 2017

Uh oh!

Marc-Aurele commented Oct 18, 2017

Uh oh!

aabadie commented Nov 7, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Marc-Aurele commented Nov 8, 2017

Uh oh!

Marc-Aurele commented Mar 2, 2018

Uh oh!

aabadie commented Mar 2, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aabadie commented Mar 9, 2018

Uh oh!

Marc-Aurele commented Mar 9, 2018

Uh oh!

aabadie left a comment

Choose a reason for hiding this comment

Uh oh!

aabadie commented Mar 9, 2018

Uh oh!

kYc0o commented Mar 9, 2018

Uh oh!

aabadie commented Mar 9, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

aabadie commented Mar 12, 2018

Uh oh!

Uh oh!

Marc-Aurele Jul 7, 2017 •

edited

Loading

Marc-Aurele commented Jul 9, 2017 •

edited

Loading

aabadie commented Nov 7, 2017 •

edited

Loading

aabadie commented Mar 9, 2018 •

edited

Loading