Last edited 3 years ago

How to define your low-power strategy

1. Purpose[edit source]

This article proposes some guidelines in order to determine the best low-power strategy for your STM32MP15 product.

2. Power supplies[edit source]

It is important to understand the perimeter of the two STM32MP15 main power supplies:

  • VDD supplies I/Os and analog components such as reset, power management, oscillators and PLLs. VDD is present as far as the STM32MP15 is not in Off or VBAT mode. For a given system, VDD voltage is fixed and usually chosen between 1.8 V to 3.3 V typical.
  • VDDCORE supplies the digital core domain and must be present after VDD at start up. Depending on the system low-power mode, VDDCORE voltage varies between switched off (0 V), the retention voltage (0.9 V) and the nominal voltage (1.2 V). The mapping of these voltage levels to the low-power modes is shown in the next paragraph.

For more information, refer to the PWR chapter of the STM32MP15 Reference Manual and to the STM32MP15 Datasheet.

3. Low-power modes[edit source]

Starting from the Run mode, various actions can be taken to reduce the processor power consumption when all tasks have been completed:

  • Stop the high-speed clock sources (PLLs/HSI/HSE/CSI): this corresponds to the Stop mode where the VDDCORE external regulator is kept at its nominal voltage. The regulator can even be switched in low-power mode in order to reduce its power consumption: this is the LP-Stop mode.
  • Stop the high-speed clock sources (PLLs/HSI/HSE/CSI) and reduce VDDCORE voltage to its retention value: this is the LPLV-Stop mode, that enables to consume the minimum power while maintaining the content of all the registers and internal memories.
  • Stop the high-speed clock sources (PLLs/HSI/HSE/CSI) and switch off VDDCORE: this is the Standby mode, where the content of all registers and internal memories is lost, apart from the one that are in VSW domain that is supplied by VDD (when present) or VBAT (in VBAT mode). In particular, notice that the Backup registers, the Backup RAM and the Retention RAM are in the VSW domain. Please also note that PWR and RCC both have some registers in the VSW (kept during Standby) and VDD (lost during Standby) domains.

One or several wake-up source(s) are used to exit from the above low-power modes and come back to Run mode. Not all internal peripherals are able to wake up from low-power modes. Table Functionalities depending on system operating mode located in the PWR chapter of the STM32MP15 Reference Manual, shows the wake-up capability of each peripheral. This is summarized in the figure in the following paragraph.

When the processor is put in one of these low-power modes, the external RAM (DDR) is usually put in Self-Refresh mode in order to keep its content whereas most of the STM32MP15 is no more active (no more clock generated for the DDR, no more Auto-refresh commands). This extra power consumption has to be considered at system level and depends on the selected DDR memory (refer to your memory provider datasheet).

The main side effect of using low-power modes is the wake-up time required to restore the system to a full running state (Run mode): the deepest you slept and the longest it needs to wake up. The next chapter illustrates this in order to allow you to make the best choice for your product.

Refer to the AN5109 document for a deeper explanation of the low-power mode characteristics and dynamics.
Refer to the Power overview to discover the corresponding software architecture that enable using those modes with OpenSTLinux.

4. Low-power strategy[edit source]

4.1. Overview[edit source]

The figure below shows, for each low-power mode:

  • The peripherals that can be used as wake-up sources (grey boxes)
  • The STM32MP15 typical power consumption (on the left)
  • The system wake -up times in various configurations (on the right)


AN5109Power overviewWake up time interpretationPower suppliesLow power modesSTM32MP15 low power modes

4.2. Wake-up time interpretation[edit source]

Warning white.png Warning
External factors, such as a ONKEY that would be debounced before reaching the STM32MP15 wake up pin, may influence the measurements given in the figure above and must be taken into account:
  • For Arm® Cortex®-A7 core:
    • The wake-up times given in the above figure correspond to a typical OpenSTLinux distribution (around 7-Mbyte uImage, 500-Mbyte Weston rootfs, 30-second cold boot time)
  • For the Arm® Cortex®-M4 core:
    • The wake-up times correspond to the return to the software execution, so your application extra time has to be added to those figures, which are taken from the STM32MP15 datasheets.
    • The RETRAM and SRAM remain supplied in (LP-)Stop and LPLV-Stop modes, so the Cortex-M4 firmware code and data can use them.
    • The RETRAM remains supplied in Standby mode, and can hence be used to store the code of a size limited firmware that would be executed at wake-up. Once woken up, the firmware can use again the SRAM for data storing and the application running on the Cortex-A7 core could even reload some services (code) in SRAM.
Info white.png Information
The core that is started on wake up from Standby is selected thanks to the MPU_BEN (Cortex-A7) and MCU_BEN (Cortex-M4) bits in RCC_MP_BOOTCR.
  • Disabling both MPU_BEN and MCU_BEN is equivalent to enabling MPU_BEN.
  • Enabling MPU_BEN is the nominal case.
  • Enabling MCU_BEN requires to be aware of the ES0438 errata sheet following items:
    • RCC security settings for Cortex-M4 access are not kept upon wake up from Standby
    • Wake-up pin flags cleared at Standby mode exit with MCU_BEN high and MPU_BEN low
  • Enabling both MPU_BEN and MCU_BEN is not recommended because race condition may occur on shared resources between each core (Cortex-A7 boot chain, including the ROM code, and Cortex-M4 firmware)