Skip to content

Commit

Permalink
doc: nrf: app_dev: nrf54h20: Global reset
Browse files Browse the repository at this point in the history
Updated reset handling to reflect the new global domain reset handling
for local domain resets, plus impact on debugging experience.
Also highlighted need for local domains for good power consumption
numbers.

Signed-off-by: Karsten Koenig <[email protected]>
  • Loading branch information
karstenkoenig authored and jangalda-nsc committed Jan 8, 2025
1 parent bb55a3b commit 40e3d4f
Show file tree
Hide file tree
Showing 3 changed files with 31 additions and 24 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -10,6 +10,11 @@ nRF54H20 Power Management
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.

To achieve optimal low power consumption, ensure that both the radio and application domains are programmed with firmware, as each domain independently sends its power and clock requirements to the System Controller.

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
************

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -7,25 +7,8 @@ nRF54H20 reset behavior
:local:
:depth: 2

The reset behavior of the nRF54H20 SoC depends on the core that triggers the reset:

+--------------------------+--------------------------------------------------------------+
| CPU Triggering Reset | Reset Behavior |
+==========================+==============================================================+
| Secure Domain | Resets the entire SoC |
+--------------------------+--------------------------------------------------------------+
| System Controller | Resets the entire SoC |
+--------------------------+--------------------------------------------------------------+
| Application domain | - Resets all peripherals and VPRs owned by the Application |
| | domain |
| | - Resets the Radio domain |
| | - Resets all peripherals and VPRs owned by the Radio domain |
+--------------------------+--------------------------------------------------------------+
| Radio domain | - Resets all peripherals and VPRs owned by the Radio domain |
| | - Resets the Application domain |
| | - Resets all peripherals and VPRs owned by the Application |
| | domain |
+--------------------------+--------------------------------------------------------------+

All local domain resets trigger a reset of the entire SoC.

nRF Util allows for different types of reset behavior on the various cores of the nRF54H20 SoC, based on the current lifecycle state of the device.

Expand Down Expand Up @@ -73,11 +56,14 @@ The following is the reset behavior when the LCS of the nRF54H20 SoC is either i
* - ``RESET_VIA_SECDOM``
- Uses the CTRL-AP mailbox to send a local domain reset request to the Secure Domain Firmware (SDFW).

SDFW resets nonessential local domains and global peripherals owned by these domains.
Nonessential domains include all local domains except the Secure Domain.
This command resets the entire system while keeping both the application core and the radio core in a halted state.

You can start each core individually using the following commands:

* To start the Application core: ``nrfutil device go --core Application``
* To start the Network core: ``nrfutil device go --core Network``

Only domains with a populated UICR are reset.
After the reset, the affected CPUs do not restart.
This approach is particularly useful for debugging individual domains, starting from their reset handlers.

* - ``RESET_DEFAULT``
- Selects ``RESET_HARD``.
Expand Down
18 changes: 17 additions & 1 deletion doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_debugging.rst
Original file line number Diff line number Diff line change
Expand Up @@ -34,14 +34,30 @@ Debugging single-core applications
**********************************

To debug single-core applications, you can use the ``west debug`` command to start a single debug session with GDB.
You can also attach the debug session to a running core using the ``west attach`` command.

Debugging multi-core applications
*********************************

To debug the firmware running also on cores other than the application core, you need to set up a separate debug session for each one of the cores you want to debug.
When debugging another core, the application core debug session runs in the background and you can debug both cores if needed.

If you want to reset the other cores while debugging, make sure to first reset the application core and execute the code.
Debugging early-boot and reset issues
*************************************

A local domain reset triggers a global reset, which resets the debugging state.
As a result, a new debugging connection is required.
To debug early boot issues, you can trigger a reset while keeping the cores in a halted state.
This approach allows time to attach the debugger.
The cores can then be started individually.

The following example demonstrates how to debug the early boot phase on the application core:

.. code-block:: shell
nrfutil device reset --reset-kind RESET_VIA_SECDOM
nrfutil device go --core Network
west attach
Using GDB as an external debugger
*********************************
Expand Down

0 comments on commit 40e3d4f

Please sign in to comment.