cancel
Showing results for 
Search instead for 
Did you mean: 

STM32N6 low-power modes and Standby demo

B.Montanari
ST Employee

Summary

This article provides an overview of the low-power modes available in the STM32N6 series. It provides hands-on instructions for utilizing the Standby demo, detailing how RAM retention is implemented and how to run the demo code.

Introduction

The STM32N6 series is designed to offer a range of low-power modes to optimize power consumption for various applications. This guide covers the essential aspects of these low-power modes and their main characteristics as well as how to run the Standby demo available. Practical instructions for implementing the other low-power modes can be found in the application note: How to optimize low-power modes on STM32N6 MCUs.

1. Low-power modes overview

The STM32N6 series microcontrollers are not low-power. However, they are designed to optimize power consumption while maintaining performance. These devices, based on the Arm Cortex®-M55 CPU and Neural-ART accelerator, support various low-power modes to balance power savings and functionality.

The diagram available in Figure 29 of the RM0456 shows how the device manages transitioning between different voltage scaling states and power modes, optimizing for either performance or power savings as needed. 

BMontanari_0-1741202262411.png

Here is a detailed overview of the low-power modes available:

1.1 RUN modes

In RUN modes, the STM32N6 executes its tasks, whether it is general-purpose processing or AI computations. Power consumption depends on the voltage and frequency settings, which can be controlled independently for the CPU and NPU, creating two possible RUN modes:

  • RUN AI mode: The entire chip is active, with the MCU handling tasks and the NPU performing AI inference. This mode is used when full performance is needed for AI applications.

  • RUN GP mode: The Cortex® M55 handles general tasks, such as running RTOS tasks or using DSP capabilities for simple ML models, while the NPU is turned off. This mode is suitable for general-purpose processing with lower power consumption compared to RUN AI mode.

1.2 Sleep mode

In this mode, the CPU is off, meaning no clock is provided to it. Only a few peripherals are clocked, and the DMA is running, awaiting events from peripherals to push data into memory when an external component makes a request. This mode significantly reduces power consumption while allowing the system to wake up quickly.

1.3 Stop mode

In this mode, the DMA is not clocked, the PLL is stopped, and external RAMs are kept in self-refresh mode. The chip remains powered on, but the VDD core is off. Internal RAM can be optionally kept in retention, and external memories are powered off or put in deep-power-mode. Wake-up is achieved by restarting the clock, and the CPU starts executing from an address in the retained RAM. This mode offers a balance between power savings and wake-up time.

1.4 Standby mode

This is the lowest power mode, where the chip is powered, but the core voltage is off. Only a portion of the internal RAM is kept in retention, and external memories are powered off or put into deep power mode. The automatic switch from VDD to VBAT is supported, and I/Os can be configured with independent pull-up and pull-down circuitry. By default, the voltage regulators are in Power down mode, and all internal SRAMs are erased except 80 KB of SRAM1.

There are settings that can be made to back up the ITCM and DTCM memories as well. Five wake-up pins are available to wake up the device from Standby mode, with configurable polarity for each pin. The wake-up clock is MSI with a frequency configurable from 1 to 8 MHz. Upon the wake-up event, the MCU restarts based on the location of the secure vector table, which can be pointed to SRAM1.

1.5 VBAT mode

In this mode, the complete chip is turned off. Only the real-time clock, tamper detection, temperature, voltage, frequency protection logic, and backup registers are kept powered to retain their contents. A very limited region of the STM32N6 is powered on to preserve critical data, including:

  • RTC, tamper detection, and temperature/voltage/frequency protection logic

  • 8 KB backup RAM

  • 32 backup registers, 32-bit each

  • VDD 1V8 and VDD_IO are off

  • Exiting from VBAT is by supplying power to the chip and boot

2. Hands-on instructions

2.1 Prerequisites

Hardware: STM32N6570-DK Discovery kit with an STM32N657X0 MCU.

Software: STM32CubeIDE (1.17.0 or later) and STM32CubeProgrammer (2.18 or later).

2.2 Concept

All internal SRAM is erased except for 80 Kbytes of SRAM1, depending on the FLEXMEM setting. Backup SRAM, I-TCM, and D-TCM RAM can also be retained. Table 36 from reference manual 0486 provides a clear view on the configuration and the RAM memories that are retained:

BMontanari_1-1741202262414.png

Upon wake-up from standby mode, from events such as:

  • WKUP pins rising or falling edge, RTC alarm (alarm A and alarm B)
  • RTC wake-up
  • Tamper event
  • Timestamp event
  • External reset in NRST pin or IWDG reset
  • Software reset occurs, but the boot ROM is NOT executed.

The software restarts based on the location of the secure vector table address, as written by the application in the SYSCFG_INITSVTORCR register before entering Standby mode. Refer to reference manual 0486 for more details.

 

BMontanari_2-1741202262417.png

2.3 Demo implementation

By default, the contents of TCM RAMs and I-TCM FLEXMEM are not retained in standby mode. Before entering standby, the demo enables them by setting the TCMRBSEN bit in the PWR_CR4 register using the HAL_PWREx_EnableTCMRetention() function. Additionally, the TCMFLXRBSEN bit, also in the PWR_CR4 register, using the HAL_PWREx_EnableTCMFLXRetention() function, which allows the content of these memories to be retained even in Standby mode.

 

BMontanari_3-1741202262423.png

 

The demo code also ensures the secure vector table (VTOR) address is properly set in SYSCFG_INITSVTORCR. This is done in the <system_stm32n6xx_s.c> file, in the SystemInit() function.

2.4 Demo execution flow

  • Power ON: Boot ROM execution, FSBL project copied from external FLASH to internal SRAM2. Represented as steps 1 to 4

  • FSBL execution: Full application binary copied from external FLASH to internal SRAM1. Given the application is <80 KB, the application is fully retained. Represented as step 5

  • Application execution: PC jumps to application code in SRAM1. Represented as steps 6 and 7.

BMontanari_4-1741202262433.png

 

The code example performs the basic configuration, including the clock settings, the green and red LED, and the PC13 (user button) as a wake-up pin. There is a minor logic to verify if the MCU woke up from the Standby by checking the power flag and configuring the system initialization in case it is true. After that, the demo enables the TCM and ITCM retention and enters Standby mode.

Once the wake-up event is created, the STM32N6 software resets and starts from SRAM1 instead of entering in the boot ROM area. The exit from Standby mode is identified and the hardware configuration is performed, including the clock settings, since no FSBL was executed after Standby wake up. The device enters again Standby mode and the process repeats itself.

If the application had exceeded the 80 KB that can be retained at SRAM1, a copy of the FSBL or a custom loader should be present at the AXISRAM1 instead. This ensures it will either copy the entire application code from the external serial flash memory to internal RAM and perform the jump after waking up from SRAM1. Alternatively, configure the serial FLASH in execution in place mode and jump to it.

3. Hands-on: Standby mode with data retention

3.1 Understanding the demo

Open STM32CubeIDE and import the PWR_STANDBY example from the specified path.

  • Click on [File] → [Open Project From File System...] to import the PWR_STANDBY example located at:

    C:\Users\%username%\STM32Cube\Repository\STM32Cube_FW_N6_V1.0.0\Projects\STM32N6570-DK\Examples\PWR\PWR_STANDBY\STM32CubeIDE

This demo shows how to enter the Standby mode and wake up from this mode by using a wake-up pin.

As detailed, the FSBL project runs in AXISRAM2 (0x3418'0000) and is executed upon power-on after boot ROM execution. The application is loaded into AXISRAM1 (0x3400'0000) and executed after the FSBL.

The application then sets up the necessary configuration for Standby operation and wake-up upon wake-up pin press.

After power-on, the LED blinks at 1 Hz to signify post reset operation for five seconds, after that, the device enters Standby mode.

The device can be woken up upon USER1 button press (connected to wake-up pin PC13). The LED blinks at 5 Hz for five seconds to signify the exit from Standby mode. The device enters again Standby mode. Any USER1 button press can wake it up and the same sequence described in the last steps above unrolls.

3.2 Attention points

The application project enables the memory retention in main.c at lines 153 and 154: 

/* enable memory retention to keep application in Standby */
HAL_PWREx_EnableTCMRetention();
HAL_PWREx_EnableTCMFLXRetention();

The function SystemInit() in system_stm32n6xx_s.c is the one responsible for configuring the INITSVTORCR register.

3.3 Adding a post build command and build

To facilitate the demo execution, add this post build command on both projects to add the header in the binaries. This command assumes the STM32CubeProgrammer is installed in its default path:

cd "${ProjDirPath}/Debug" && echo y | "C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin\STM32_SigningTool_CLI.exe" -bin "${ProjName}.bin" -nk -of 0x80000000 -t fsbl -o "${ProjName}-Trusted.bin" -hv 2.3 -dump "${ProjName}-Trusted.bin"

This command can be added as a post build by entering in the Project Properties, C/C++ Build Settings Build Steps:

BMontanari_5-1741202262436.png

Once this post build is added to both projects, press [Ctrl] + [B] to build both. Notice the commands being executed in the Console tab:

BMontanari_6-1741202262439.png

3.4 Programming the binaries

On the STM32N6570-DK board, change BOOT1=H (DEV_BOOT) and connect it to the PC using the USB Type-C® cable.

Using the STM32CubeProgrammer, make sure the external loader for the flash enabled:

BMontanari_7-1741202262452.png

Use the address [0x7000 0000] to program the FSBL binary and the [0x7010 0000] to program the secure application binary.

BMontanari_8-1741202262455.png

TIP: You might need to power cycle the board in case a failure message appears when clicking [Start Programming] and ensure it is positioned in DEV boot mode.

3.5 Validation

To see your application running, set BOOT1 to LOW, disconnect the programmer, and power cycle the board.

The PWR_STANDBY_FSBL code is copied from flash into SRAM2 by the boot ROM and the PWR_STANDBY_Appli is copied from FLASH into SRAM1 by FSBL. The application then sets up the necessary configuration for Standby operation and wake-up upon wake-up pin press.

After power-on, the LED blinks at 1 Hz to signify post reset operation for five seconds. The device enters Standby mode. The device is woken up upon USER1 button press (connected to wake-up pin PC13). The LED blinks at 5 Hz for five seconds to signify exit from Standby mode. The device enters again Standby mode. Any USER1 button press can wake it up and the same sequence described in the last steps above unrolls.

The measurement connector, CN2, has been standardized to be compliant with the available STLINK-V3PWR, to measure several power rails in parallel. More details in this How to use STLINK-V3PWR to monitor power consumption on STM32 MCUs - Application note. In summary, the user needs to rely on the shunt resistors available on the evaluation board and measure the voltage for each shunt in the CN2.

Be careful, as a few zero ohm resistors must be removed for said measurement to take place. For more details, refer to page 5 of the board schematic: MB1939 and DS14791 current consumption measurement scheme shown in the image below:

BMontanari_9-1741202262458.png

Conclusion

This article provides an overview of the low-power modes available in the STM32N6 series, focusing on deeply explaining the Standby code implementation available in the example repository.

References

Version history
Last update:
‎2025-03-19 6:19 AM
Updated by: