doc: 54h documentation improvements

Improved various 54h doc pages.

Signed-off-by: Francesco Domenico Servidio <[email protected]>
(cherry picked from commit e808fbf)

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

@@ -12,30 +12,28 @@ The nRF54H20 DK uses both devicetree and Kconfig for its hardware and software c
 You can find the basics of both devicetree and Kconfig in Zephyr in the :ref:`zephyr:application` section of the Zephyr documentation.
 You can also read the :ref:`app_build_system` section describing the |NCS| additions to the Zephyr configuration system.
 
-However, the multicore nature of the nRF54H20 DK required some changes to the way devicetree files are organized.
+However, the multicore nature of the nRF54H20 DK required some changes to how devicetree files are organized.
 
 DTS file scheme
 ***************
 
-.. to review
-
 .. note::
    This file scheme is valid only for the nRF54H20 initial limited sampling version of |NCS|.
    It is subject to changes or improvements in future releases.
 
 The following is the DTS file structure implemented for all the SoCs of the 54H family:
 
-* Arch-specific DTS files, located in the :file:`../dts/arm/nordic_nrf_next/` and :file:`dts/riscv/nordic_nrf_next folder​` directories:
+* Arch-specific DTS files, located in the :file:`../dts/arm/nordic_nrf_next/` and :file:`dts/riscv/nordic_nrf_next folder` directories:
 
-    * Project-wide files (:file:`haltium_cpu.dtsi` and :file:`haltium_global_*.dtsi`)​
-    * Core-specific files per product (:file:`nrf54h20_cpu*.dtsi`)​
+    * Project-wide files (:file:`haltium_cpu.dtsi` and :file:`haltium_global_*.dtsi`)
+    * Core-specific files per product (:file:`nrf54h20_cpu*.dtsi`)
 
-* Common directory, located in the :file:`../common/nordic_nrf_next` folder​:
+* Common directory, located in the :file:`../common/nordic_nrf_next` folder:
 
-    * Arch-independent configurations​
+    * Arch-independent configurations
     * Common platform overlays
-    * Common memory and peripherals overlay applicable across products​
-    * Product-specific overlays applicable to all cores​
+    * Common memory and peripherals overlay applicable across products
+    * Product-specific overlays applicable to all cores
     * Project-wide overlays
 
 The following is the include tree for the application core of the nRF54H20 (cpuapp):
@@ -48,26 +46,22 @@ The files shown in the figure are currently hosted in the ``ic-next`` repository
 Customizing the DTS configuration
 *********************************
 
-.. to review
-
-The output files created in your application build directory are documented in :ref:`zephyr:devicetree-in-out-files`.
+You can find documentation for the output files created in your application build directory in :ref:`zephyr:devicetree-in-out-files`.
 You can use overlay files to customize this configuration.
 
 To see and test how to use overlays for changing nodes, see the *Lesson 3* of the `nRF Connect SDK Fundamentals course`_ on the Nordic Developer Academy website.
 
 Generated HEX files
 *******************
 
-.. to review
-
 When building an application for the nRF54H20 DK, you are building all domain images at once.
-During this process, the following :file:`zephyr.hex` images are built:
+This process generates the following :file:`zephyr.hex` images:
 
 * Application core application
 * PPR core application
 * Radio core firmware
 
-Additionally, the following user information configuration registers (UICR) contents (:file:`uicr.hex`) are generated for setup access for domains:
+Additionally, the build process generates the following user information configuration registers (UICR) contents (:file:`uicr.hex`) to set up access for domains:
 
 * System Controller UICR
 * Application UICR
@@ -77,6 +71,6 @@ Additionally, the following user information configuration registers (UICR) cont
    ``west flash`` uses :file:`uicr_merged.hex` files that are pre-merged HEX files combining the relevant :file:`zephyr.hex` + :file:`uicr.hex` for a domain that has UICRs.
    Flashing both :file:`zephyr.hex` + :file:`uicr.hex` will result in the same configuration.
 
-All of the HEX files need to be flashed into the device.
+You must flash all the HEX files into the device.
 For more information on building images for the nRF54H20 DK, see :ref:`ug_nrf54h20_gs`.
 For additional information on multi-image builds see :ref:`ug_multi_image`.

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,9 @@ 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 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 +112,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 +147,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 +161,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 +188,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 +199,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,16 +27,16 @@ 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)
@@ -45,14 +45,14 @@ 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,8 @@ 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.
+It is based on 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 +140,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 (:file:`build/<app_name>/zephyr/`, where ``<app_name>`` is the application name for each core) will contain a dictionary database file named :file:`log_database.json`.
+This file is crucial for decoding the logs and updates with every build.
 
 Reading the logs
 ----------------
@@ -149,7 +150,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 +161,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 +200,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.

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

@@ -15,34 +15,34 @@ Updating the nRF54H20 SoC binaries
 **********************************
 
 You can update the nRF54H20 SoC binaries in two ways.
-Both methods require using the :file:`nordic_top.suit` envelope, which can be found inside the nRF54H20 SOC binaries ZIP file.
+Both methods require using the :file:`nordic_top.suit` envelope, available inside the nRF54H20 SoC binaries ZIP package.
 
 The two methods for updating are the following:
 
-* Updating separately from the manufacturer application.
+* Updating the SoC binaries without the manufacturer application.
 
-* Updating along with the manufacturer application, by attaching the :file:`nordic_top.suit` envelope to the manufacturer root manifest, updating both the SoC binaries and the manufacturer's application simultaneously.
+* Updating along with the manufacturer application by attaching the :file:`nordic_top.suit` envelope to the manufacturer root manifest, updating both the SoC binaries and the manufacturer's application simultaneously.
 
 
-Updating the nRF54H20 SoC binaries separately from the manufacturer application
-===============================================================================
+Updating the nRF54H20 SoC binaries without the manufacturer application
+=======================================================================
 
-When using this method, two separate updates are performed:
+When using this method, you perform two updates:
 
 1. An update using a manufacturer envelope that contains the update candidate.
-2. A second update, provided by the :file:`nordic_top.suit` envelope from the SoC binaries bundle.
+2. A second update provided by the :file:`nordic_top.suit` envelope from the SoC binaries bundle.
 
 Each envelope contains all the necessary information, allowing the device to differentiate between the two updates.
 
-This approach was chosen for the following benefits:
+This approach offers the following benefits:
 
-* A smaller partition is required for storing the update candidate.
+* The update candidate requires a smaller partition.
 * There is no need to integrate the process of downloading Nordic artifacts into the manufacturer application build process.
-* There is no need to update the version and sequence number of the manufacturer root manifest, if only SoC binaries updates are required.
+* There is no need to update the version and sequence number of the manufacturer root manifest when you update only the SoC binaries.
 
 However, there are the following limitations:
 
-* Two separate updates are required, which is not supported by all protocols.
+* This method requires two updates, which is not supported by all protocols.
 * The manufacturer envelope cannot ensure the compatibility of SoC binaries with the manufacturer application.
 
 
@@ -53,12 +53,12 @@ When building an application, you can configure the build system to include the
 
 This approach has the following benefits:
 
-* The entire update can be performed by pushing a single image to the device, which may be required by some protocols.
-* The manufacturer root manifest can be used to manage dependencies between the manufacturer application and the SoC binaries.
+* You can perform the entire update by pushing a single image to the device, which some protocols may require.
+* You can use the manufacturer root manifest to manage dependencies between the manufacturer application and the SoC binaries.
 
 This approach has the following drawbacks:
 
-* A larger partition is required to store the update candidate, as both the manufacturer and the SoC binaries must fit within it.
+* You need a larger partition to store the update candidate since both the manufacturer application and the SoC binaries must fit within it.
 * The manufacturer must integrate the process of downloading Nordic artifacts into the update package creation process.
 
 To build and perform an update using this method, do the following: