 Hello, and welcome to this presentation of the power management on STM32 MP1 devices. It covers the sequences to enter and exit low power modes. Let's start the hardware description of the low power mechanisms of the STM32 MP1. First of all, it is important to notice that there are two domains, also named clusters, in the STM32 MP1, one related to the Cortex-A7 core and one related to the Cortex-M4 core. Both domains are power supplied by a single regulator named VDDCore. Each domain supports various low power modes that can independently be selected on each side. The overall chip state is determined by the combination of each domain power mode. The flexible clock tree allows fine-tuning of the clocks thanks to various dividers, muxes, and gates. Now let's focus on the STM32 MP1 internal peripherals that handle the power management features. The first one is the RCC. It stands for Reset and Clock Control. Its role is to control the clock tree. It offers registers to define the clock tree state. PLL configuration, clock path thanks to muxes and dividers. It also enables the gating of the clocks. The RCC also controls the various resets of the system. There are individual resets, peripheral reset, and platform reset. The second peripheral is the PWR. It is responsible for low power entry and exit. The RCC and PWR are tightly coupled. They work in coordination to handle all the resources involved in power management. Clocks, power supplies, and wake-up signals. Here is a physical representation of these blocks. It shows the strong interaction between them through several signals. The two domains are visible, and we also see the corresponding signals. Underscore C1 and underscore C2. Some additional words can be said about the AIEC block, also named EXTI, which collects the wake-up signals coming from the peripherals. It can be configured to generate one single wake-up signal to the right domain. This slide focuses on the definition of the power mode supported by the STM32MP1 microprocessor. As previously mentioned, there are power modes at domain level, prefixed with C, and at platform level, no prefix. Let's start with the modes available at domain level, as they are also necessary to explain the platform modes. The list is ordered from the lightest power saving game to the deepest. The first mode is named CRUN. It is available on the Cortex-A7 side and on the Cortex-M4 side. The CPU is running, or in WFI, or wait for interrupt, and the interconnect and peripheral clocks are available. The CSLEEP mode can be seen as an add-on to the CRUN mode. It offers the possibility to automatically gate the clocks of a peripheral when the CPU is in WFI. This feature can be configured independently for each peripheral. CSLEEP is also available on both domains. In C-STOP mode, the CPU, interconnect and peripherals clocks are off. VDDCore is unchanged. This mode is available on both domains. C-STANDBY is very similar to C-STOP regarding the hardware resources states. The difference between both modes is the way to wake up. Note that C-STANDBY is available on the Cortex-A7 side only. The platform modes are the combination of the cluster modes described above. When both clusters are in C-STOP mode, the platform reaches STOP mode. The PLLs are disabled. VDDCore is unchanged. LPLV STOP mode is similar to STOP mode, except that VDDCore is reduced to 0.9V typical. It can be seen as a retention mode. STANDBY mode is the deepest low-power mode. The Cortex-A7 core is in C-STOP or C-STANDBY mode, and the Cortex-M4 core is in C-STOP mode. In this mode, all clocks, including PLLs, are off, and VDDCore is also off. Let's have a look at the wake-up behavior of each of the previously described modes. The main point of attention here is to highlight the available wake-up sources for each mode and to give an idea of the exit latency. In WFIC sleep mode, the CPU clock is off. This mode is left as soon as any enabled interrupt happens. Exit latency is negligible. In C-STOP, the interconnect, CPU, and peripheral clocks need to restart. The peripherals having a wake-up capability can generate a wake-up condition. In STOP mode, there is an additional latency compared with C-STOP due to the PLL's lock time. In LPLV STOP, there is an additional latency compared with STOP mode because VDDCore needs to rise back to its nominal value before clocks can restart. Due to the reduction of VDDCore, the peripherals which have a wake-up capability are no more operational. The C-STANDBY has the same wake-up peripherals as C-STOP, but C-STANDBY is left through a reset on the Cortex-A7 side. So the CPU executes the boot ROM, the boot loader, and then the Linux kernel. In STANDBY mode, VDDCore was off, so it needs to restart before the CPU executes the boot ROM, the boot loader, and possibly the Linux kernel reload and restart. A word on the DDR subsystem. In STANDBY mode, the software deliveries offer the possibility to put the DDR in self-refresh to preserve its content or to switch it off. This is selected at software build time. The DDR memory is important regarding the power management process. The STM32MP1 microprocessor supports DDR3, LPDDR2, and LPDDR3 memory types. In STOP, C-STOP, and LPLV STOP mode, as the clocks are off, the DDR controller does not issue refresh orders anymore. So the DDR memory is put in self-refresh. In STANDBY mode, VDDCore is off, so the DDR controller is not powered anymore. Depending on the targeted power saving amount, it is possible to switch the DDR off or to keep it in self-refresh. The STM32MP1 device is mounted on an evaluation board that can also embed external components such as a camera, a display, etc. So the board power distribution tree is part of the delivery. Two flavors of power distribution are available, a PMIC-based solution. It is a dedicated circuit which integrates all the regulators needed by the platform. It is compact and additionally offers other functionalities such as overcurrent detection, thermal detection, banked registers for low power mode, etc. And a discrete solution which consists of physically independent regulators soldered on the board. The voltages are fixed. So, for example, a mode like LPLV STOP is not supported. Here is a graphical view of the PMIC power distribution scheme. An I2C link allows the STM32MP1 to access the PMIC registers. Some hardware lines between the two chips allow generation of interrupts, resets, and PMI registers bank selection through the PWR CTRL line of the STM32MP1. This slide shows how the discrete power scheme is built. The regulator's control consists of powering on or off the supply. The PWR CTRL line of the STM32MP1 is used for this. The PWRONLP line of the STM32MP1 is used to switch off the DDR3 terminations. Now that the hardware context has been presented, we have to dig into the software implementation. As there is a software platform boot training, the boot ROM and bootloader aspects are not discussed in this part. Starting on the Cortex A7 side, the application runs on a Linux kernel. The APIs are used to invoke a power mode from the user application. MEM is the command used to reach the STM32MP1 low power modes. Please note that in western environment, the MEM command is replaced with system CTL command. The common clock framework and the reset framework from the Linux community are used. They allow full configuration and control of the clock tree and resets within the RCC peripheral. The Linux suspend framework is used to invoke the low power modes from the user application. It is interfaced with the GenPD or generic power domain framework and with the PCSI 1.0 library. It is important to focus on standby exit because several configurations are possible. The standby mode is left via chip reset, which means that the boot ROM is executed first. It is possible to specify to the boot ROM which CPU has to wake up. In case the Cortex M4 has to wake up alone or at the same time as the Cortex A7, its firmware, slim type, has to be located in retention RAM because the SysRAM is lost due to VDD core falling to zero. Notice that the boot ROM offers an optional Cortex M4 firmware authentication service through a hash mechanism. The Linux can fill in the hash dedicated backup registers so that the boot ROM verifies at standby exit that the hash is the same on the Cortex M4 resident firmware. The goal is to avoid starting an altered Cortex M4 firmware. This slide shows which low power modes can be reached depending on the enabled wake up source. It is the responsibility of the GenPD framework to ensure the consistency between the enabled source and the low power mode. The Linux kernel offers one command to call STM32MP1 low power modes. The platform supports more than one low power mode so the software deliveries implement a mechanism to reach the available modes. It has been stated in a previous slide that all the wake up sources are not available in each low power mode. The GenPD software framework is used to analyze which wake up sources are enabled and it then calls the deepest low power mode compatible with these sources. Let's take some examples. 1. UART4 is enabled as wake up source. Then GenPD will not go deeper than stop mode. 2. RTC is enabled as wake up source. Then GenPD allows standby mode to be reached. 3. UART4 and RTC are enabled as wake up sources. Then GenPD will not go deeper than stop mode. Several versions of stop modes are available. The customer can choose at software build time which flavor should be supported. There is a dedicated section in the secure monitor device tree to specify this. This slide gives an example of the possible analysis enabling the choice of the low power modes to be supported. It is oriented around the DDR type mounted on the board. In low power mode the DDR memory is put in self refresh mode. Comparing the overall power consumption in stop mode plus DDR3 in self refresh mode and standby mode plus DDR3 in self refresh mode both configurations are in the same range because the DDR3 memory consumption is the major contributor. It then makes sense to choose stop mode plus DDR3 in self refresh mode and standby plus DDR3 off. Doing the same exercise with LPDDR2 the conclusion is different because the consumption of the LPDDR2 memory device in self refresh mode is small. Then it becomes interesting to select LPLV stop or standby mode with LPDDR in self refresh mode. Remember that making the optimal choice requires consideration of wake-up latency, targeted power saving gain and type of needed wake-up source. ST Microelectronics provides an overall proposal taking into account the type of enabled wake-up source and ensuring a consistency with low power modes. Again the final choice is a trade-off between the three criteria mentioned on the previous slide and the customer has to consider them for an optimal decision. Here is an overview of a low power entry exit sequence. The low power entry is initiated by the user application. On the Linux side all activity is suspended. Then the RCC and PWR are programmed. It is assumed that the user has enabled at least one wake-up source. The last step is to put the DDR memory in self refresh state if this option is selected. From this moment the platform is in low power mode waiting for a wake-up event to happen. When a wake-up event happens the RCC and PWR restore the clocks and power before allowing the software to run. Here are some tips to ease the power management debug. Debug FS is a tool dedicated to clocks in the Linux kernel. It displays the clock tree configuration on the console. This can help detect missing clocks or clocks that remain on even when unused. It can also help detect wrong frequencies. This is a standard tool coming from the Linux community common clock framework. It is also important to dump some registers from the RCC and PWR peripherals. In the PWR peripherals some flags are related to stop mode. It can help verify whether stop mode was reached or not. In the RCC peripheral the interesting information is related to reset flags. It can help detect if the C standby or standby mode was reached or not. Finally there is a dedicated debug peripheral named HDP that can be configured through the device tree to observe internal hardware signals involved in low power entry or exit. This section presents frequently encountered problems around power management and gives the first instructions to start the analysis. If the system does not wake up the first point to be verified is that at least one wake-up source is enabled. The clock source of the peripheral that must wake up also needs to be checked. It must be running. In case of wake-up by wake-up pins if the polarity and or pull-up or pull-down configuration is not correct the pin will not operate. Another common issue is that the system refuses to switch to low power. This is usually due to an already pending event present in the interrupt controller of the CPU. This can happen when an input line pull-up pull-down is badly configured. In case of platform power consumption too high at run time there are several points that can be verified. Check that no clocks remain on whereas nobody needs them. Check that no regulators remain on whereas nobody needs them. The debug FS of the common clock framework and of the regulator framework can help identify such situations. For more details on the hardware embedded on STM32 MP1 boards please refer to the STM32 MP1 reference manual and to the STP MIC1 data sheet.