Integrating sleep, standby, and shutdown mode into Zephyr low power PM

[saeed-molaie]

Does it make sense to add sleep, standby, and shutdown mode to cpu power states so that PM automatically selects the best power state, taking into account all the available STM32U5 power states (not just stop 0-3)?

cpu-power-states = <&stop0 &stop1 &stop2>;

zephyr/dts/arm/st/u5/stm32u5.dtsi

Line 42 in c79b1e8

cpu-power-states = <&stop0 &stop1 &stop2>;

FYI, tried adding standby, but it looks like it will require a bit of more work because currently it does not respond to RTC interrupts. I am guessing shutdown will have the same issue.

@erwango @mathieuchopstm

[erwango]

@saeed-molaie As you mention, this property is used for power states that could be automatically selected. As such "shutdown" doesn't apply since it can only be selected by application (on user action, typically).

About "Standby", beware. STM32 and Zephyr standby notions differ:
-Zephyr PM_STATE_STANDBY is intermediate between "suspend-to-idle" states (as Stop3) and "suspend-to-ram". You'll find some pretty old STM32 code on this but this should probably be cleaned up, as it's mapped on to STM32 standby which signification differ.
-STM32 Wireless "standby" is in Zephyr a "suspend-to-ram" state. Not implemented in Zephyr on U5. Available on WB0/WBA.
-Typical STM32 Standby, as a "light power off" would likely matches Zephyr "PM_STATE_SOFT_OFF" and is not implemented today

[mathieuchopstm]

Zephyr's PM_STATE_STANDBY is actually equivalent to PM_STATE_SUSPEND_TO_IDLE on uni-processor:

zephyr/include/zephyr/pm/state.h

Lines 69 to 77 in 8409c13

	* In addition to putting peripherals into low-power states all
	* non-boot CPUs are powered off. It should allow more energy to be
	* saved relative to suspend to idle, but the resume latency will
	* generally be greater than for that state. But it should be the same
	* state with suspend to idle state on uniprocessor system.
	*
	* @note This state is correlated with ACPI S2 state
	*/
	PM_STATE_STANDBY,

Since all STM32 MCUs are uni-processor, they should never use PM_STATE_STANDBY (only PM_STATE_SUSPEND_TO_IDLE).

As for PM_STATE_SOFT_OFF, it is merely an historical artifact now superseded by CONFIG_POWEROFF and should no longer be used. Various STM32 series already implement CONFIG_POWEROFF support (including STM32U5, in which it is mapped to Shutdown mode).

[mathieuchopstm]

Also, suspend-to-RAM support is implemented in Zephyr for at least STM32WBA series (Standby with retention mode) and STM32WB0 (Deepstop mode), although it may be somewhat incomplete (i.e., peripherals loosing their state after low-power residency).

[mathieuchopstm]

Does it make sense to add sleep, standby, and shutdown mode to cpu power states so that PM automatically selects the best power state, taking into account all the available STM32U5 power states (not just stop 0-3)?

Sleep mode is entered automatically whenever the idle thread is scheduled (which executes a WFI instruction with SCB->SCR.SLEEPDEEP = 0) - no SoC-specific implementation is required to support it. (Note that the WFI path is executed only if no better low-power state can be entered when CONFIG_PM=y)

Standby mode is for the most part identical to Shutdown mode on STM32U5 as, in both cases, most of the system is powered-off and looses its state. The only differences are:

• Standby mode can retain up to 64 KiB of RAM (SRAM2)
  • which means that in theory, you could use it as PM_STATE_SUSPEND_TO_RAM state
  • but "SRAM2 only" is a huge limitation so this was never implemented
• Standby mode supports BOR (automatic switch from VDD to VBAT as I understand it?)
• Standby mode can partially retain I/O state (Pull-Up / Pull-Down)
• IWDG remains active in Standby mode

These additional features might be useful in some cases so perhaps we should implement a Kconfig option which allows selecting which mode (Standby / Shutdown) is entered by sys_poweroff(); regardless, Standby mode would be a CONFIG_POWEROFF state only which means it would never be entered automatically.

Shutdown mode is already supported on STM32U5 series and can be entered using sys_poweroff() (gated by CONFIG_POWEROFF).