Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

stm32l0: Voltage regulator is not restored after leaving STOP mode #42092

Closed
abxy opened this issue Jan 24, 2022 · 1 comment · Fixed by #42078
Closed

stm32l0: Voltage regulator is not restored after leaving STOP mode #42092

abxy opened this issue Jan 24, 2022 · 1 comment · Fixed by #42078
Assignees
Labels
area: Power Management bug The issue is a bug, or the PR is fixing a bug platform: STM32 ST Micro STM32 priority: low Low impact/importance bug
Milestone

Comments

@abxy
Copy link
Contributor

abxy commented Jan 24, 2022

Describe the bug
I have a custom board that started to crash after I enabled power management. I have located the source of the problem to the cpu power management driver for STM32L0.

In power.c, when entering "STOP mode" (suspend to idle) the internal voltage regulator is changed to low-power mode, but when exiting STOP mode, the regulator mode is not restored to its main mode. Specifically it is the LPSDSR bit of PWR_CR that is not restored. It is my understanding that leaving this bit set will cause the MCU to enter "low-power sleep" in the idle thread, but that requires additional steps to do safely. This is further corroborated by the fact that my attempts to debug the issue indicates a fault in arch_cpu_idle.

To Reproduce

Reproducing the stability issue is difficult as it seems to depend on other factors (my own untested hypothesis is that having VDD = 1.8V can be a contributing factor). I have only had it happen on a custom board, but on that board it is very reproducible.

I cannot give full steps to reproduce, but the sample samples/boards/stm32/power_mgmt/blinky can be modified to verify that regulator is indeed configured to low-power mode after entering STOP mode for the first time.

In main.c...

...include the relevant header

#include <stm32_ll_pwr.h>

...and modify the loop

while (true) {
        printk("Regulator mode LP: 0x%x\n", LL_PWR_GetRegulModeLP());
        /* Rest of the loop body */
}

Add DTS overlay if needed. E.g. boards/nucleo_l031k6.overlay:

/ {
    power-states {
		stop: stop {
			compatible = "zephyr,power-state";
			power-state-name = "suspend-to-idle";
			min-residency-us = <100>;
		};
	};
};

&cpu0 {
	cpu-power-states = <&stop>;
};

&lptim1 {
    status = "okay";
};

Build and run

  1. west build -b nucleo_l031k6 -s samples/boards/stm32/power_mgmt/blinky
  2. west flash
  3. Open terminal to view output

Output showing that regulator mode changes:

*** Booting Zephyr OS build v2.7.99-3661-gd51a67b7c098  ***
Device ready
Regulator mode LP: 0x0
Regulator mode LP: 0x1
Regulator mode LP: 0x1
Regulator mode LP: 0x1

Expected behavior
All lines should print Regulator mode LP: 0x0. My custom board should not crash.

Additional context
The custom board on which this issue was first observed uses uses STM32L071CZ, sys clock = HSI16 and VDD = 1.8V.

@abxy abxy added the bug The issue is a bug, or the PR is fixing a bug label Jan 24, 2022
@erwango erwango assigned erwango and abxy and unassigned erwango Jan 24, 2022
@erwango erwango added area: Power Management platform: STM32 ST Micro STM32 priority: low Low impact/importance bug labels Jan 24, 2022
@erwango erwango added this to the v3.0.0 milestone Jan 25, 2022
@wcappelle
Copy link

Great fix, I've experienced the same problems with an STM32L010RB board (even sometimes on the nucleo board with external -unstable- power). I've tried your fix, and so far no problems, but as you said reproduction isn't that easy..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Power Management bug The issue is a bug, or the PR is fixing a bug platform: STM32 ST Micro STM32 priority: low Low impact/importance bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants