doc: 54h documentation improvements

Improved various 54h doc pages.

Signed-off-by: Francesco Domenico Servidio <[email protected]>

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

@@ -30,7 +30,6 @@ Debug configurations
 Some applications and samples provide a specific configuration that enables additional debug functionalities.
 You can select custom configurations when you are :ref:`configuring the build settings <cmake_options>`.
 
-
 Debugging single-core applications
 **********************************
 
@@ -79,8 +78,10 @@ To debug a specific core using ``JLinkExe`` do the following:
       .. note::
          |nrfjprog_deprecation_note|
 
-   If just one DK is connected to the machine, defining ``SEGGER-ID`` is not necessary.
-   If more than one DK is connected to the machine and ``SEGGER-ID`` is undefined, a pop up window will appear where you can manually select the ID of the DK you want to run J-Link on.
+   If you connect just one DK to the machine, defining ``SEGGER-ID`` is not necessary.
+   If you connect more than one DK to the machine and ``SEGGER-ID`` is undefined, a pop up window will appear where you can manually select the ID of the DK you want to run J-Link on.
+
+   If you connect multiple DKs to the machine and have not defined ``SEGGER-ID``, a pop-up window appears where you can manually select the ID of the DK to run J-Link on.
 
    .. note::
       PPR core debugging is not functional in the initial limited sampling.
@@ -112,7 +113,7 @@ Debug logging
 *************
 
 You can use the logging system to get more information about the state of your application.
-Logs are integrated into various modules and subsystems in the |NCS| and Zephyr.
+Various modules and subsystems in the |NCS| and Zephyr integrate logs.
 These logs are visible once you configure the logger for your application.
 
 You can also configure log level per logger module to, for example, get more information about a given subsystem.
@@ -147,9 +148,10 @@ A value of ``0`` indicates *no error*, while any other value signifies that an e
    Therefore, a device experiencing erratic behavior might still report ``0`` incorrectly.
    For example, this may occur if the device is in a boot loop.
 
-
 Several components report errors through this register.
-The first 4 bits of the first byte is reserved for future use and must be ``0``, the second 4 bits of the bootstatus indicate which component reported an error:
+The first 4 bits of the first byte must be 0.
+These bits are reserved for future use.
+The second 4 bits of the ``BOOTSTATUS`` indicate which component reports an error:
 
  * System Controller ROM -> ``0x01``
  * Secure Domain ROM -> ``0x02``
@@ -160,17 +162,16 @@ The first 4 bits of the first byte is reserved for future use and must be ``0``,
       Each one of these values has a different handling of the remaining bits.
       This chapter only describes the semantics for Secure Domain Firmware errors (``0x0B******``).
 
-
 The second byte describes the boot step within the SDFW booting process that reported the failure.
 For more information, see `SDFW Boot Steps`_
 The last two bytes contain the lower 16 bits of the error code.
 
 For example, ``0x0BA1FF62`` indicates that the SDFW reported an error in the BICR validate step (``0xA1``) with error message ``0xFF62``, or ``-158``.
 
-SDFW Boot Steps
+SDFW boot steps
 ---------------
 
-The boot steps are defined as follows:
+The following are the boot steps definitions:
 
 .. parsed-literal::
    :class: highlight
@@ -188,7 +189,8 @@ The boot steps are defined as follows:
     #define BOOTSTATUS_STEP_ADAC 0xC0
     #define BOOTSTATUS_STEP_SERVICES 0xCF
 
-Errors are not accumulated, as only one error is reported even if multiple boot steps fail.
+Errors do not accumulate.
+When multiple boot steps fail, the system reports only one error.
 The SDFW chooses which error to report if multiple errors occur.
 The types of errors that can overwrite other errors are the following:
 
@@ -198,7 +200,7 @@ The types of errors that can overwrite other errors are the following:
 The following is a short description of the failures related to the boot steps:
 
  * ``BOOTSTATUS_STEP_START_GRTC``  - SDFW was unable to initialize the driver used for the GRTC.
- * ``BOOTSTATUS_STEP_SDFW_UPDATE`` - SDROM was instructed to install an update before last reset, and is indicating that an error occurred while performing the update.
+ * ``BOOTSTATUS_STEP_SDFW_UPDATE`` - Before the last reset, the SDROM received instructions to install an update and indicates that an error occurred during the process.
  * ``BOOTSTATUS_STEP_BELLBOARD_CONFIG`` - SDFW was unable to apply the static bellboard configuration.
  * ``BOOTSTATUS_STEP_SUIT_INIT`` - A SUIT related error occurred.
  * ``BOOTSTATUS_STEP_DOMAIN_ALLOCATE`` - An error occurred while allocating global resources.

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

@@ -27,32 +27,32 @@ Similarly to other SoCs from Nordic Semiconductor, to use a UART connection for
 nRF54H20 logging using System Trace Macrocell (STM)
 ***************************************************
 
-nRF54H20 domains contain ARM Coresight System Trace Macrocell (STM) hardware devices for collecting trace data from multiple domains, using either standalone logging or assisted multicore logging.
-The STM uses memory-mapped registers to write trace data generated by the domains in the system.
-It multiplexes the data as trace protocol data, formatted according to the MIPI System Trace Protocol (STP) v2, and synchronizes the data on a single output, such as a single UART.
+nRF54H20 domains include ARM Coresight System Trace Macrocell (STM) hardware, which collects trace data from multiple domains using standalone or assisted multicore logging.
+The STM writes trace data generated by the domains using memory-mapped registers.
+The STM multiplexes trace protocol data, formatted according to the MIPI System Trace Protocol (STP) v2, and sends it to a single output, like a UART.
 This approach has a minimal cost on performance and code size, allowing for a non-intrusive collection of system debug-and-trace information.
 
 The STM implements a frontend of the Zephyr logging subsystem, allowing you to use the standard Zephyr logging API.
 For more information on STM, see :ref:`zephyr:logging_cs_stm`.
 
 .. note::
-   The STM logging feature for the nRF54H20 SoC was tested using the J-Trace PRO V2 Cortex-M, with firmware compiled on ``Mar 28 2024 15:14:04``.
+   The STM logging feature for the nRF54H20 SoC underwent testing with the J-Trace PRO V2 Cortex-M, using firmware compiled on ``Mar 28 2024 15:14:04``.
    Using this feature also requires ``nrfutil-trace`` version 2.10.0 or later.
 
-Embedded Trace Router (ETR)
+Embedded trace router (ETR)
 ===========================
 
 The Embedded Trace Router (ETR) is a hardware feature that provides a circular buffer in RAM for trace data.
 For more information on ETR, see :ref:`zephyr:logging_cs_stm`.
 
-When using ETR on the nRF54H20 SoC, one of the cores is designated as a *proxy* to manage the trace data.
+When using ETR on the nRF54H20 SoC, one of the cores acts as a *proxy* to manage the trace data.
 
 .. note::
-   Currently, the Application core is the only core that can be designated as proxy.
+   Currently, only the Application core can act as a proxy.
 
 The proxy core is responsible for handling the data from the ETR and outputting it through the desired transport mechanism (like UART or USB).
 The proxy core approach allows for on-chip data processing, offering more flexibility than the Trace Port Interface Unit (TPIU).
-However, due to the limited size of the ETR buffer, there is a risk of data loss if not handled promptly.
+However, the limited size of the ETR buffer poses a risk of data loss if not handled appropriately.
 
 Standalone logging
 ==================
@@ -88,7 +88,7 @@ To read the STM log output on the UART, consult the following documentation page
 * If you want to use PuTTY, see :ref:`putty`.
 
 .. note::
-   To use UART in your application, the UART's node must be described in devicetree.
+   To use UART in your application, define the UART node in the devicetree.
    For more details, see :ref:`zephyr:devicetree-intro`.
 
 The following is an example log output::
@@ -125,7 +125,7 @@ The following are the prefixes used to indicate the cores:
 Assisted multicore logging
 ==========================
 
-Assisted multicore logging uses dictionary-based logging to send messages without redundant strings to STM, and is based on the :ref:`zephyr:logging_guide_dictionary` feature of the logging API provided by Zephyr.
+Assisted multicore logging uses dictionary-based logging to send messages without redundant strings to STM, following the :ref:`zephyr:logging_guide_dictionary` feature of the Zephyr logging API.
 For more information on assisted multicore logging, see :ref:`zephyr:logging_cs_stm`.
 
 Configuring logging
@@ -139,8 +139,8 @@ For example, the following command uses the snippet when building for the applic
 
 All cores must use the same logging configuration.
 
-After building your application, a dictionary database file named :file:`log_database.json` will be generated in the build directories for each one of the cores the snippet was used on (:file:`build/<app_name>/zephyr/`, where ``<app_name>`` is the name of the application built for each specific core).
-This file is crucial for decoding the logs and is updated with every build.
+After building your application, the build directories for each core will contain a dictionary database file named :file:`log_database.json` (:file:`build/<app_name>/zephyr/`, where ``<app_name>`` is the application name for each core).
+This file is crucial for decoding the logs and updates with every build.
 
 Reading the logs
 ----------------
@@ -149,7 +149,7 @@ To read the dictionary-based STM log output, do the following:
 
 1. Set up the log capture.
 
-   Use the ``nrfutil trace stm`` command to start capturing logs from the device, specifying the database configuration for each domain ID, as well as the serial port, the baud rate, and the output type::
+   Use the ``nrfutil trace stm`` command to start capturing logs from the device, specifying the database configuration for each domain ID, along with the serial port, baud rate, and output type::
 
       nrfutil trace stm --database-config <domain_id>:build/<app_name>/zephyr/log_dictionary.json --input-serialport <port> --baudrate 115200 --stdout ascii
 
@@ -160,13 +160,13 @@ To read the dictionary-based STM log output, do the following:
      When using several domains, use a comma (`,`) to separate each domain in the list.
    * ``<app_name>`` is the application name.
    * ``<port>`` is the serial port used for output.
-     Use ``nrfutil device list`` to list which serial ports are exposed by the development kit.
+     Use ``nrfutil device list`` to identify the serial ports exposed by the development kit.
    * The output can be either the console (``--stdout ascii``) or a file (the :file:`out.txt` file if ``--output-ascii out.txt``).
 
 #. Capture and decode the logs.
 
    nrfutil will capture the log data from the specified UART port and use the provided dictionary databases to decode the logs into a human-readable format.
-   The decoded logs are sent to the previously-defined output (either the console or the :file:`out.txt` file in the previous example).
+   The tool sends the decoded logs to the specified output (either the console or the :file:`out.txt` file in the example).
 
 #. Read the terminal or open the output file to review the decoded log messages.
 
@@ -199,5 +199,5 @@ When using assisted multicore logging, consider the following:
 
 * Use optimized log macros (having up to 2 word size numeric arguments, like ``LOG_INF("%d %c", (int)x, (char)y)``) to improve the size and speed of logging.
 * For memory constrained applications (for example, when running on the PPR or FLPR cores), disable the ``printk()`` function by setting both the :kconfig:option:`CONFIG_PRINTK` and :kconfig:option:`CONFIG_BOOT_BANNER` Kconfig options to ``n`` in your project configuration.
-* When working with multiple domains, such as the Secure Domain and Application core, ensure that each database is prefixed with the correct domain ID.
-* Some log messages might be dropped due to the limited size of the RAM buffer that stores STM logs.
+* When working with multiple domains, such as the Secure Domain and Application core, ensure that each database has the correct domain ID prefix.
+* The limited size of the RAM buffer storing STM logs may cause some log messages to drop.