Skip to content

Commit 4cecedb

Browse files
karstenkoenigdegjorva
authored andcommitted
doc: nrf: app_dev: nrf54h20: Global reset
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]>
1 parent 7b201e1 commit 4cecedb

File tree

3 files changed

+31
-24
lines changed

3 files changed

+31
-24
lines changed

doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_architecture_pm.rst

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -10,6 +10,11 @@ nRF54H20 Power Management
1010
The nRF54H20 SoC is a distributed system where each domain tries to achieve minimal power consumption for itself.
1111
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.
1212

13+
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.
14+
15+
For reference implementations, see the :ref:`multicore_idle_test` samples.
16+
These samples demonstrate configurations where the radio core remains idle while the application core remains active.
17+
1318
Power states
1419
************
1520

doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_architecture_reset.rst

Lines changed: 9 additions & 23 deletions
Original file line numberDiff line numberDiff line change
@@ -7,25 +7,8 @@ nRF54H20 reset behavior
77
:local:
88
:depth: 2
99

10-
The reset behavior of the nRF54H20 SoC depends on the core that triggers the reset:
11-
12-
+--------------------------+--------------------------------------------------------------+
13-
| CPU Triggering Reset | Reset Behavior |
14-
+==========================+==============================================================+
15-
| Secure Domain | Resets the entire SoC |
16-
+--------------------------+--------------------------------------------------------------+
17-
| System Controller | Resets the entire SoC |
18-
+--------------------------+--------------------------------------------------------------+
19-
| Application domain | - Resets all peripherals and VPRs owned by the Application |
20-
| | domain |
21-
| | - Resets the Radio domain |
22-
| | - Resets all peripherals and VPRs owned by the Radio domain |
23-
+--------------------------+--------------------------------------------------------------+
24-
| Radio domain | - Resets all peripherals and VPRs owned by the Radio domain |
25-
| | - Resets the Application domain |
26-
| | - Resets all peripherals and VPRs owned by the Application |
27-
| | domain |
28-
+--------------------------+--------------------------------------------------------------+
10+
11+
All local domain resets trigger a reset of the entire SoC.
2912

3013
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.
3114

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

76-
SDFW resets nonessential local domains and global peripherals owned by these domains.
77-
Nonessential domains include all local domains except the Secure Domain.
59+
This command resets the entire system while keeping both the application core and the radio core in a halted state.
60+
61+
You can start each core individually using the following commands:
62+
63+
* To start the Application core: ``nrfutil device go --core Application``
64+
* To start the Network core: ``nrfutil device go --core Network``
7865

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

8268
* - ``RESET_DEFAULT``
8369
- Selects ``RESET_HARD``.

doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_debugging.rst

Lines changed: 17 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -34,14 +34,30 @@ Debugging single-core applications
3434
**********************************
3535

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

3839
Debugging multi-core applications
3940
*********************************
4041

4142
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.
4243
When debugging another core, the application core debug session runs in the background and you can debug both cores if needed.
4344

44-
If you want to reset the other cores while debugging, make sure to first reset the application core and execute the code.
45+
Debugging early-boot and reset issues
46+
*************************************
47+
48+
A local domain reset triggers a global reset, which resets the debugging state.
49+
As a result, a new debugging connection is required.
50+
To debug early boot issues, you can trigger a reset while keeping the cores in a halted state.
51+
This approach allows time to attach the debugger.
52+
The cores can then be started individually.
53+
54+
The following example demonstrates how to debug the early boot phase on the application core:
55+
56+
.. code-block:: shell
57+
58+
nrfutil device reset --reset-kind RESET_VIA_SECDOM
59+
nrfutil device go --core Network
60+
west attach
4561
4662
Using GDB as an external debugger
4763
*********************************

0 commit comments

Comments
 (0)