[Backport v2.9-nRF54H20-branch] doc: nrf: app_dev: nrf54h20: Global reset

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

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

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

@@ -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.
 
@@ -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``.

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

@@ -35,14 +35,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
 *********************************