![]() |
Coming soon |
1. Introduction
STM32WBA CubeFW provides low power features that are integrated into the application framework.
Once the low power is enabled in the application, the system framework is responsible of choosing the lowest possible power mode that can be used. Serval parameters are taken into account such as the application use case or the radio activity.
2. Concepts
2.1. Low power general overview
STM32WBA SoC low power mode is determined by both Link Layer operating modes and SoC PWR modes.
Details are given in the next sections.
2.1.1. Link Layer operating modes
Link Layer operating modes are detailed in the table below.
Operating mode | Purpose |
---|---|
Active – Standby | Link Layer is in active mode when the radio is operating. Standby is used on active waiting of radio event (BLE IFS, RX on IDLE for 802.15.4). |
Sleep | This mode is used when there is no radio activity. Baseband clock (active clock) has to be switched OFF. RXTX SRAM or sequence SRAM are not available. HW Link Layer registers are accessible as long as bus clock remains ON. |
Deep Sleep | Deep Sleep mode is the lowest low power mode for Link Layer IP. This mode is only available when the is no current/up-coming radio activity. Baseband clock (active clock) is switched OFF. All power domains are switched OFF except sleep timer one. Bus clock has to be ON for sleep timer registers access. |
Deep sleep mode entry/exit is time consuming. Therefore, the next radio activity has to be far enough to power down the radio.
A threshold value is available in system framework and can be configured as needed. See RADIO_DEEPSLEEP_WAKEUP_TIME_US
macro in system configuration.
2.1.2. SoC PWR power modes
STM32WBA SoC supports four main PWR power modes: run, sleep, stop and standby. Details are given below.
2.1.2.1. Run mode
The CPU and the system clock are running. It shall be used only when it is required to execute code.
2.1.2.2. Sleep mode
CPU clock is off (CPU stops fetching code), all peripherals including Cortex-M33 core such as NVIC and SysTick can run and wake up the CPU when an interrupt or an event occurs. This should be used when a peripheral (that does not have a kernel clock) requires the system clock to operate while the CPU is stopped.
2.1.2.3. Stop modes
Stop modes achieve the lowest power consumption while retaining the content of registers. The SRAM content can be selected to be retained or not. All clocks (except some autonomous peripherals bus and kernel clocks) in the Core domain are stopped (system clock, high-speed oscillators).
There are two stop modes:
- stop0: This is the stop mode available when a kernel clock is enabled or a autonomous peripherals bus clock is requested.
- stop1:
2.1.2.4. Standby modes
Standby Retention This is the lowest Low-power mode targeted in the application. The CPU, the system clock, the high-speed oscillators and most SoC registers are all lost. It is required to save / restore all contexts and hardware registers configurations that are not retained in the SRAM which content is not lost. The time required to save / restore all contexts and hardware registers depends on how many peripherals are used in the application (e.g: Most of the time GPIO, UART, CPU, DMA, Clocks are used and need to be restored). Due to the extra CPU execution time required to exit/enter this mode (mostly due to startup and save / restore operation), it should be used only when the latency to wakeup does not matter and when the “idle” time is long enough so that the power saving in this mode compensates the extra power consumption due to extra CPU processing to enter/exit this mode. The radio and BLE HW LL registers, except for the sleep timer, are lost and need to be restored by the BLE LL FW. (The BLE LL is in Deep Sleep). This should be used, when possible, between radio event to save additional power. Standby SoC registers, Radio Sleep Timer and BLE HW LL SRAMs are lost. Only RTC, TAMP, and WKUP are retained. This should be used only when it is decided to restart everything from wakeup. E.g.: There is no more radio activity, and the application may stop for several days to wake up on a GPIO events or an alarm from the RTC.
2.2. Low power in Connectivity applications
2.2.1. Low power manager Utility module (LPM)
The low power manager provides a simple interface to receive the input from up to 32 different users and computes the lowest possible power mode the system can use. It also provides hooks to the application before entering or on exit of low-power mode.
2.2.2. Low power platform interface
2.2.3. Low power standby mode: save & restore mechanism
From an architecture point of view, low power manager has a two sections organization. One for the BLE LL and one for the SoC. Both impact each other on their low-power management. The schema below overviews its concept:
There are numerous different low-power modes available. They all differ according to the section they impact and the intended objective. Right after are the different low-power modes based on the two sections:
BLE IP Low-power modes:
- HW LL
-
- Active – Standby
- These modes are requested when the radio is operating. Standby is used during IFS.
- Sleep
- This mode is used when there is no radio activity. This is fully handled by the BLE FW LL. It is possible to access BLE HW LL registers in this mode. For this, the bus clock needs to be active. To access RXTX SRAM or sequence SRAM, the baseband clock shall remain active – This is managed by the LL itself.
- Deep Sleep
- This mode is used when there is no radio activity and no need to read/write any register in the BLE HW LL (except the Sleep timer and the register to set the Low-power mode of the BLE HW LL). This mode shall be entered when the BLE HW LL is in idle mode long enough so that the overhead to exit from Deep Sleep mode is not significant. This needs profiling to define the threshold value.
- PHY
-
- Tx/Rx – Standby
- These modes are requested when the radio is operating. Standby is used during IFS.
- Sleep
- This mode is used when there is no radio activity.
- Shutdown
- This mode is applied only when the SoC enters Standby (no retention). All radio configurations are lost (Calibration, etc.).
SoC Low-power modes:
- Run
- The CPU and the system clock are running. It shall be used only when it is required to execute code.
- Sleep
- Only the CPU is in Low-power mode (stop fetching code). The system clock is running. This should be used when a peripheral (that does not have a kernel clock) requires the system clock to operate while the CPU is stopped.
- Stop0/Stop1
- The CPU, the system clock and the high-speed oscillators are all stopped. LPBAM peripheral can still operate. The 2.4GHz radio can still be active when in Stop 0 Range1. For this, the high-speed system clock and peripheral kernel clocks may be kept running. When a kernel clock is enabled, Stop0 is selected by the SoC HW. This should be used when Standby is not possible.
- Standby Retention
- This is the lowest Low-power mode targeted in the application. The CPU, the system clock, the high-speed oscillators and most SoC registers are all lost.
- It is required to save / restore all contexts and hardware registers configurations that are not retained in the SRAM which content is not lost.
- The time required to save / restore all contexts and hardware registers depends on how many peripherals are used in the application (e.g: Most of the time GPIO, UART, CPU, DMA, Clocks are used and need to be restored).
- Due to the extra CPU execution time required to exit/enter this mode (mostly due to startup and save / restore operation), it should be used only when the latency to wakeup does not matter and when the “idle” time is long enough so that the power saving in this mode compensates the extra power consumption due to extra CPU processing to enter/exit this mode.
- The radio and BLE HW LL registers, except for the sleep timer, are lost and need to be restored by the BLE LL FW. (The BLE LL is in Deep Sleep). This should be used, when possible, between radio event to save additional power.
- Standby
- SoC registers, Radio Sleep Timer and BLE HW LL SRAMs are lost. Only RTC, TAMP, and WKUP are retained. This should be used only when it is decided to restart everything from wakeup. E.g.: There is no more radio activity, and the application may stop for several days to wake up on a GPIO events or an alarm from the RTC.
2.3. Application Idle State
The application is either in Active state when the CPU executes code or in Idle state when the CPU is stopped. This Idle state may be split into 3 parts:
- Pre-Idle Task:
- It holds the last code to be executed before stopping the CPU. It runs outside critical section so user may implement here some long execution time code without impacting any interrupt latency.
- Idle Task:
- It holds the code to enter Low-power mode. A critical section is required to avoid interrupt loss due to race conditions (when WFI is used to stop the CPU). When moving out from Low-power mode, the mandatory system setup shall be executed here before any interrupt run. This is required as this is the last code executed before jumping in the interrupt handler.
- Post-Idle Task:
- It holds the first code to be executed when moving out from the Idle Task. It shall be executed when the Pre-Idle Task has been executed and only in that case. It runs outside critical sections so user may implement here some code with long execution time without impacting any interrupt latency. Here should be executed any system setup required to run the Application in Active but not mandatory for a coming interrupt handler.
3. Interfaces
TBD.
4. How to
TBD.