doc: Updated nRF54H20 power management doc

FrancescoSer · carlescufi · commit ae468c4969d5 · 2025-08-08T18:00:08.000+02:00
Updated nRF54H20 power management doc

Signed-off-by: Francesco Domenico Servidio &lt;francesco.servidio@nordicsemi.no&gt;
diff --git a/doc/nrf/app_dev/device_guides/nrf54h/index.rst b/doc/nrf/app_dev/device_guides/nrf54h/index.rst
@@ -44,3 +44,4 @@ Zephyr and the |NCS| provide support and contain board definitions for developin
    ../nrf54l/zms.rst
    ug_nrf54h20_mcuboot_dfu
    ug_nrf54h_ecies_x25519
+   ug_nrf54h20_pm_optimization
diff --git a/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_architecture_pm.rst b/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_architecture_pm.rst
@@ -1,6 +1,6 @@
 .. _ug_nrf54h20_architecture_pm:
 
-nRF54H20 Power Management
+nRF54H20 power management
 #########################
 
 .. contents::
@@ -15,24 +15,19 @@ To achieve optimal low power consumption, ensure that both the radio and applica
 For reference implementations, see the :ref:`multicore_idle_test` samples.
 These samples demonstrate configurations where the radio core remains idle while the application core remains active.
 
-Power states
-************
+Software power states
+*********************
 
-The nRF54H20 ARM Cortex CPUs currently support the following software power states:
+The ARM Cortex CPUs of the nRF54H20 SoC currently support the following software power states:
 
 * Active
 * Idle
-* Local suspend to Ram
-
-Overview
-********
+* Idle with cache disabled
+* Local suspend to RAM
 
 Each CPU in the nRF54H20 SoC tries to preserve as much power as possible, independently from other CPUs.
 The power management subsystem, operating independently within each CPU, continuously selects the most optimal power state based on the current conditions of the CPU.
 
-Power states details
-********************
-
 The following sections describes the details of each of the software power states available on the nRF54H20 SoC.
 
 Active
@@ -48,7 +43,7 @@ Active
 
    * - RAM
      - Banks used by the executed code are enabled.
-       Other banks may be in any state.
+       Other banks can be in any state.
 
    * - System state
      - *System ON*
@@ -82,7 +77,7 @@ Idle
 
    * - RAM
      - Banks used by the executed code are enabled.
-       Other banks may be in any state.
+       Other banks can be in any state.
 
    * - System state
      - *System ON*
@@ -104,8 +99,54 @@ The wake-up latency is higher than in *Active*, but lower than in the other powe
 The primary sources of wake-up latency are the wake-up of the ``MRAMC`` and the startup of clock sources.
 The maximum latency depends on the MRAM power state configured by the System Controller.
 
-Local Suspend to RAM
-********************
+Idle with cache disabled
+========================
+
+*Idle with cache disabled* is a lightweight sleep state where the CPU is suspended and the contents of the L1 caches are discarded.
+
+.. list-table::
+   :widths: auto
+
+   * - CPU
+     - Powered on but not clocked.
+       Its state is retained in the hardware flip-flops.
+
+   * - RAM
+     - Enabled or retained depending on the hardware state.
+       RAM in caches is disabled.
+
+   * - System state
+     - * *System ON* if at least one other CPU or a peripheral clocked > 32 kHz is active.
+       * *System ON Idle* if all CPUs are disabled and the only active peripherals are clocked with 32 kHz (real-time part of ``GRTC``, ``RTC``, ``WDT``) or System Off wake-up sources.
+       * *System ON All Idle* if all other CPUs and all peripherals except System Off wake-up sources are disabled.
+         Only available in domains without DVFS.
+
+       The hardware automatically selects one of these states based on the activity of other CPUs and peripherals.
+
+   * - Peripherals
+     - All can be active.
+       The local peripherals are powered and preserve their state.
+       The state of inactive peripherals in other domains is retained in the hardware flip-flops.
+
+   * - Coprocessors
+     - All can be active.
+       The state of inactive coprocessors is retained according to their selected sleep state.
+
+   * - System timer (based on GRTC)
+     - Active
+
+The primary sources of wake-up latency are:
+
+* Writing back dirty cache lines
+* Waking up the MRAMC
+* Refilling L1 caches
+* Restarting clock sources
+
+Latency is influenced by the number of dirty cache lines at sleep entry and the cache miss rate after wake-up.
+The maximum latency depends on the MRAM power state configured by the System Controller via the ``MRAMC.POWER.AUTOPOWERDOWN`` setting.
+
+Local suspend to RAM
+====================
 
 *Local Suspend to RAM* is a sleep state that balances between power consumption and wake-up latency.
 
@@ -153,100 +194,22 @@ Instead, their state is retained by software in RAM.
 The power consumption in this state depends on the overall System state but is lower than in any of the *Idle* states.
 The wake-up latency is higher than in any of the *Idle* states due to the CPU state restoration procedure.
 
-Selecting the optimal power state
-*********************************
-
-In the nRF54H20 SoC, each local domain is responsible for selecting the power state that results in minimal power consumption while maintaining an acceptable level of performance.
-
-Entering a deeper sleep state leads to power savings when the system is idle, but it requires increased power consumption to enter and exit the sleep state.
-There is a minimum sleep duration that justifies the energy spent on entering and exiting a sleep state, and this duration varies for each sleep state.
-
-In the SoC, a local domain has full control over entering and exiting local sleep states, allowing it to assess whether entering these sleep states is optimal at any given moment.
-However, entering sleep states associated with system-off requires cooperation between local domains and the System Controller.
-Local domains have limited control over the time and energy required to enter or exit system-off, as well as the power consumption during system-off.
-
-Latency management
-******************
-
-The sources of wake-up latency in the nRF54H20 SoC can be categorized into two types: local and global.
-Each CPU is responsible for managing its latency sources, with local sources handled by local domains and global sources managed by the System Controller.
-
-Local cores are responsible for handling latencies caused by restoring the system from suspend-to-RAM states.
-Local cores schedule their wake-up in advance of expected events.
-The timing of expected events is reported to the power management subsystem in the RTOS by the software modules anticipating these events.
-The power management subsystem sets a ``GRTC`` channel in advance of the next expected event to compensate for local wake-up latency.
-
-The System Controller is responsible for handling latencies caused by restoring the system from the system-off state (the warm boot procedure latency).
-The System Controller schedules the system wake-up from the system-off state in advance of the next ``GRTC`` event to compensate for the warm-boot latency of the system.
-
-Because the warm-boot latency is compensated by the System Controller, from a local CPU's perspective, the latency when restoring from the local-off state and the system-off state is expected to be the same.
-
-Latency in local domains
-========================
-
-Any local software module (like a device driver) can anticipate events like ISRs.
-Some of these events have predictable timing, while others have unpredictable timing.
-Handling the latency of events with unpredictable timing is the same in both simple and complex systems.
-
-If handling an event with predictable timing requires restoring the state of the software module or the peripherals used by this module before the event is processed, the software module is responsible for scheduling a timer event in advance.
-This scheduled event is used to restore the state of the software module or peripherals.
-
-The Power Management subsystem in a local domain is responsible for scheduling a wake-up in advance to compensate for the domain's core state restoration latency from the local power state.
-The wake-up time scheduled in advance by the power management subsystem is combined with the advance time added by the software module.
-This approach ensures that the local domain and the software modules anticipating an event have sufficient time to fully restore before the event occurs, allowing the event to be handled without latency.
-
-Unretained hardware classification
-**********************************
-
-Some power states in the nRF54H20 SoC result in powering off certain peripherals.
-The state of these peripherals is not retained by hardware and must be restored by software before the peripheral is activated.
-
-See the following sections for the lists of peripheral groups and the related software modules responsible for restoring the peripheral's state for each group.
-
-Peripherals in local domains
-============================
-
-All local domains include a common set of hardware modules.
-In addition to these, most local domains also contain domain-specific peripherals.
-
-Common peripherals for all local domains
-----------------------------------------
-
-Each local domain contains a set of peripherals that are classified consistently across all local domains.
-The following table summarizes the active peripherals that need handling when exiting the *Local Suspend to RAM* state.
-
-+---------------+--------------------+--------------------+--------------------+--------------------------+
-|Type           | List of the        | Source of data to  | Time of restoration| Software module          |
-|               | peripherals        | restore            |                    | responsible for restoring|
-+===============+====================+====================+====================+==========================+
-|Active         | * ``MVDMA``        | Device driver's    | Decided by the     | The device driver        |
-|peripherals    |                    | code and data      | driver             |                          |
-+---------------+--------------------+--------------------+--------------------+--------------------------+
-
-Peripherals specific to the Application Domain
-----------------------------------------------
-
-There are no peripherals specific to the Application Domain.
-
-Peripherals specific to the Secure Domain
------------------------------------------
-
-The Secure Domain contains additional peripherals that require handling in the *Local Suspend to RAM* state.
-
-+---------------+--------------------+--------------------+--------------------+--------------------------+
-|Type           | List of the        | Source of data to  | Time of restoration| Software module          |
-|               | peripherals        | restore            |                    | responsible for restoring|
-+===============+====================+====================+====================+==========================+
-|Active         | * ``CRACEN``       | Device driver's    | Decided by the     | The device driver        |
-|peripherals    |                    | code and data      | driver             |                          |
-+---------------+--------------------+--------------------+--------------------+--------------------------+
+Mapping application states to software power states
+***************************************************
 
-Peripherals specific to the Radio Domain
-----------------------------------------
+The following table maps application states to software power states:
 
-The Radio Domain does not implement the *Local Suspend to RAM* state.
++---------------------+------------------------------+---------------------------------------+------------------------------------------+
+| Application state   | Application core power state | Radio core power state                | SoC hardware state                       |
++=====================+==============================+=======================================+==========================================+
+| Active              | Active,                      | Active,                               | System On,                               |
+|                     | Idle,                        | Idle,                                 | System On Idle,                          |
+|                     | Local suspend to RAM         | Idle with cache disabled              | System On All Idle                       |
++---------------------+------------------------------+---------------------------------------+------------------------------------------+
+| Idle                | Local suspend to RAM         | Idle with cache disabled              | System On All Idle                       |
++---------------------+------------------------------+---------------------------------------+------------------------------------------+
 
-Power management benchmark
-**************************
+Power management optimization
+*****************************
 
-To benchmark the power consumption in *Idle* state, see :ref:`multicore_idle_test`.
+For recommendations on power management optimization techniques on the nRF54H20 SoC, see the :ref:`ug_nrf54h20_pm_optimization` page.
diff --git a/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_pm_optimization.rst b/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_pm_optimization.rst
