-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
doc: Documentation edits for 2.7.99-cs1 release
Added firmware bundle compatibility table. Updated nRF54H20 GS guide. Added initial power management documentation. Added initial clock control documentation Signed-off-by: Francesco Domenico Servidio <francesco.servidio@nordicsemi.no>
- Loading branch information
1 parent
f7b59d2
commit 408d986
Showing
8 changed files
with
252 additions
and
54 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
64 changes: 64 additions & 0 deletions
64
...dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_architecture_clockman.rst
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,64 @@ | ||
| .. _ug_nrf54h20_architecture_clockman: | ||
|
|
||
| nRF54H20 Clock Management | ||
| ######################### | ||
|
|
||
| .. contents:: | ||
| :local: | ||
| :depth: 2 | ||
|
|
||
| The nRF54H20 SoC consists of multiple asynchronous clock domains and require clock sources for correct operation. | ||
| Each of the clock sources needs proper management: | ||
| to start and stop the clock at the appropriate time, to select the proper clock source, and to calibrate or synchronize the clock to another more accurate source. | ||
| Some of the clock management operations are performed solely by the hardware circuits, but others require software. | ||
| Most of the clocks can be locked to other more accurate ones to improve their accuracy. | ||
|
|
||
| Clock Domains | ||
| ************* | ||
|
|
||
| The nRF54H20 SoC consists of the following clock domains: | ||
|
|
||
| * LFCLK | ||
| * HFXO | ||
| * FLL16M | ||
| * HSFLL Application | ||
| * HSFLL Radio (if Radio domain is present) | ||
| * HSFLL Secure | ||
| * HSFLL Global | ||
|
|
||
| Each of the clock domains is enabled independently of others. | ||
| Each clock domain is automatically enabled when at least one sink is active. | ||
| Firmware can choose to keep each of the clock domains enabled even when all its sinks are inactive. | ||
|
|
||
| Clock domain source selection differs between clock domains. | ||
| The LFCLK source is selected by the System Controller Firmware. | ||
| The HFXO source is selected by the System Controller Firmware. | ||
| The FLL16M source is selected by local domains or System Controller firmware in all scenarios except one: when firmware selects open-loop, but any of HSFLLs is closed-loop, then FLL16M is switched by hardware to closed-loop. | ||
| HSFLLs sources are selected by firmware (depending on an HSFLL instance: local domain or System Controller). | ||
|
|
||
| The details of each of the clock domains are described in the following sections. | ||
|
|
||
| The application-facing APIs show only the domain directly clocking the component used by the application. | ||
| The management of clocks on which this domain depends is handled internally by the clock driver of this domain. | ||
| One example would be a firmware module requesting better timing accuracy for a fast ``UART`` instance. | ||
| This firmware module requests the accuracy of the global ``HSFLL`` device driver, directly clocking the ``UART``. | ||
| The accuracy of the dependencies FLL16M and LFXO is requested by the global HSFLL driver internally. | ||
| Not directly by the firmware module. | ||
|
|
||
| LFCLK | ||
| ===== | ||
|
|
||
| The Low-Frequency Clock domain is responsible for generating a 32768 Hz clock signal for ultra-low-power peripherals like ``GRTC`` or ``RTC``. | ||
|
|
||
| Zephyr clock control API | ||
| ************************ | ||
|
|
||
| Zephyr RTOS contains a *clock_control* device driver class for managing clocks. | ||
| The *clock_control* API is designed to support multiple requestors. | ||
| Moreover, the *clock_control* API supports blocking or asynchronous operations based on the notification when the requested clock settings are applied. | ||
| Because of this, the *clock_control* API is well-suited for LFCLK management in the local domains. | ||
|
|
||
| The *clock_control* subsystem exposes portable parameters in its functions: | ||
|
|
||
| * accuracy requests in ppm values | ||
| * precision requests in ppm over n cycles, period-period jitter, or (for simplicity) high- and low-precision modes |
143 changes: 143 additions & 0 deletions
143
...f/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_architecture_pm.rst
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,143 @@ | ||
| .. _ug_nrf54h20_architecture_pm: | ||
|
|
||
| nRF54H20 Power Management | ||
| ######################### | ||
|
|
||
| .. contents:: | ||
| :local: | ||
| :depth: 2 | ||
|
|
||
| The nRF54H20 SoC is a distributed system where each domain tries to achieve minimal power consumption for itself. | ||
| When all CPUs are ready to fully minimize power consumption by entering the System Off hardware state, the System Controller prepares the system and triggers the entrance in this state. | ||
|
|
||
| Power states | ||
| ************ | ||
|
|
||
| The nRF54H20 ARM Cortex CPUs currently support the following software power states: | ||
|
|
||
| * Active | ||
| * Idle | ||
|
|
||
| In following releases on the |NCS|, support for the following power states will be added: | ||
|
|
||
| * Idle with cache retained in RAM | ||
| * Idle with cache disabled | ||
| * Local Suspend to RAM | ||
| * Suspend to RAM ready for System Off | ||
| * Soft Off | ||
|
|
||
| Overview | ||
| ******** | ||
|
|
||
| Each CPU in the nRF54H20 SoC tries to preserve as much power as possible, independently from other CPUs. | ||
| As such, each CPU strives to enter sleep as deep as possible in its current circumstances, switching its power states asynchronously from the other CPUs. | ||
|
|
||
|
|
||
| Power states details | ||
| ******************** | ||
|
|
||
| The following sections describes the details of each of the software power states available on the nRF54H20 SoC. | ||
|
|
||
| Active | ||
| ====== | ||
|
|
||
| *Active* is the power state in which the CPU is actively processing. | ||
|
|
||
| .. list-table:: | ||
| :widths: auto | ||
|
|
||
| * - CPU | ||
| - Powered on and clocked. | ||
|
|
||
| * - RAM | ||
| - Banks used by the executed code are enabled. | ||
| Other banks may be in any state. | ||
|
|
||
| * - System state | ||
| - *System ON* | ||
|
|
||
| * - Peripherals | ||
| - All can be active. | ||
| The state of all inactive peripherals 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 | ||
|
|
||
| This is the power state with the highest power consumption. | ||
| The software execution latency is minimal. | ||
| The main latency source is the wake-up of ``MRAMC``. | ||
| The maximal latency depends on the MRAM power state configured in the ``MRAMC.POWER.AUTOPOWERDOWN`` by the System Controller. | ||
|
|
||
| Idle | ||
| ==== | ||
|
|
||
| *Idle* is the lightest sleep power state available in the system where the cache content is retained. | ||
|
|
||
| .. list-table:: | ||
| :widths: auto | ||
|
|
||
| * - CPU | ||
| - Powered on but suspended (not clocked). | ||
|
|
||
| * - RAM | ||
| - Banks used by the executed code are enabled. | ||
| Other banks may be in any state. | ||
|
|
||
| * - System state | ||
| - *System ON* | ||
|
|
||
| * - 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 power consumption in this state is lower than when in *Active*, but higher than in other power states. | ||
| The wake-up latency is higher than when in *Active*, but lower than in the other power states. | ||
| The main wake-up latency source is the wake-up of ``MRAMC``, and the startup of clock sources. | ||
| The maximal latency depends on the MRAM power state configured in the ``MRAMC.POWER.AUTOPOWERDOWN`` by the System Controller. | ||
|
|
||
| Entering and exiting sleep states by ARM CPUs | ||
| ********************************************* | ||
|
|
||
| All ARM CPUs managing local domains enter and exit the sleep states in a unified way. | ||
|
|
||
| Two sets of software sequences can take place for each sleep state: | ||
|
|
||
| * One executed to enter the sleep state. | ||
| * One executed after exiting the sleep state. | ||
|
|
||
| All of these sequences apply to all of the ARM Cortex CPUs managing the local domains. | ||
|
|
||
| The described sequences are executed in critical sections with all IRQs masked. | ||
| The IRQ handlers are delayed until the sequences are completed. | ||
|
|
||
| Idle | ||
| ==== | ||
|
|
||
| To enter the *Idle* state, it is enough to suspend the CPU execution (``WFE`` or ``WFI`` instruction). | ||
|
|
||
| When the CPU execution is suspended, the power domain containing the CPU and the CACHE can switch to a mode that does not retain cache status, which would result in data loss. | ||
| Powering down the power domain containing the CACHE must be prevented by setting ``LRCCONF010.POWERON.ACTIVE = 1`` | ||
|
|
||
| The complete procedure of entering the idle state consists of the following steps: | ||
|
|
||
| 1. ``LRCCONF010.POWERON.ACTIVE[n] = 1``, where *n* is the index of the power domain containing ``CACHE`` | ||
| #. ``WFE`` or ``WFI`` | ||
|
|
||
| Exiting this state is triggered by any event resuming the CPU execution (usually an interrupt). | ||
| The CPU continues execution of the program following the ``WFI`` / ``WFE`` instruction. | ||
| Alternatively, if the IRQ waking up the system was not masked while suspending the CPU, the CPU resumes the execution from the ISR. | ||
| The return address from the ISR is the instruction following ``WFI`` / ``WFE``. | ||
|
|
||
| After waking up the default configuration of the power domains should be restored through ``LRCCONF010.POWERON.ACTIVE[n] = 0``, where *n* is the index of the power domain containing ``CACHE``. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.