doc: Doc fixes for 2.8

Doc fixes for 2.8 - release task

Signed-off-by: Uma Praseeda <uma.praseeda@nordicsemi.no>

applications/machine_learning/app_desc.rst

@@ -659,7 +659,7 @@ Forwarding data.
 
    a. Open the `nRF Connect for Mobile`_ application and connect to the device again.
    #. Bond with the device from the `nRF Connect for Mobile`_ application on your smartphone or tablet.
-   #. Find **Nordic UART Service** and enable notification of its "TX Charcteristic".
+   #. Find **Nordic UART Service** and enable notification of its "TX Characteristic".
    #. Observe the sensor readouts represented as comma-separated values.
       Every new value represents a single sensor readout.
 

applications/matter_weather_station/README.rst

@@ -223,7 +223,7 @@ To build this application to work with the nRF7002 Wi-Fi expansion board:
 Generating factory data
 =======================
 
-To enable factory data support, you need to select the ``overlay-factory_data`` configuration overlay from the available application :ref:`build configuration overlays <matter_weather_station_app_build_configuration_overlays>`, set the ``SB_CONFIG_MATTER_FACTORY_DATA_GENERATE`` kconfig option to ``y``, and use the ``factory_data`` file suffix.
+To enable factory data support, you need to select the ``overlay-factory_data`` configuration overlay from the available application :ref:`build configuration overlays <matter_weather_station_app_build_configuration_overlays>`, set the ``SB_CONFIG_MATTER_FACTORY_DATA_GENERATE`` Kconfig option to ``y``, and use the ``factory_data`` file suffix.
 You can generate new factory data set when building for the given board target by invoking the following command:
 
 .. code-block:: console

applications/nrf_desktop/bluetooth.rst

@@ -14,7 +14,7 @@ The information about peer and connection state is propagated to other applicati
 
 The :ref:`CONFIG_DESKTOP_BT <config_desktop_app_options>` Kconfig option enables support for Bluetooth connectivity in the nRF Desktop.
 Specific Bluetooth configurations and application modules are selected or implied according to the HID device role.
-Apart from that, the defaults of Bluetooth-related Kconfigs are aligned with the nRF Desktop use case.
+Apart from that, the defaults of Bluetooth-related Kconfig options are aligned with the nRF Desktop use case.
 
 The nRF Desktop devices come in the following roles:
 

applications/serial_lte_modem/doc/CARRIER_AT_commands.rst

@@ -174,7 +174,7 @@ The ``<cmd>`` command is a string, and can be used as follows:
 
 * ``AT#XCARRIER="app_data_create",<obj_inst_id>,<res_inst_id>``
 
-  Create an empty resource instance of the Data resource (ID: 0) of the Binary App Data Containet object (ID: 19).
+  Create an empty resource instance of the Data resource (ID: 0) of the Binary App Data Container object (ID: 19).
 
   ``<obj_inst_id>`` indicates the target object instance.
 

applications/serial_lte_modem/doc/SOCKET_AT_commands.rst

@@ -1284,6 +1284,7 @@ Syntax
 
 * The ``<hostname>`` parameter is a string.
 * The ``<address_family>`` parameter is an integer that gives a hint for DNS query on address family.
+
   * ``0`` means unspecified address family.
   * ``1`` means IPv4 address family.
   * ``2`` means IPv6 address family.

applications/serial_lte_modem/doc/TCPUDP_AT_commands.rst

@@ -716,11 +716,10 @@ UDP receive data
 
 ::
 
-   #XUDPDATA notification comes only when SLM is not operating in :ref:`data mode <slm_data_mode>`.
-
    #XUDPDATA: <size>,<ip_addr>,<port>
    <data>
 
+* ``#XUDPDATA`` notification comes only when SLM is not operating in :ref:`data mode <slm_data_mode>`.
 * The ``<size>`` value is an integer that represents the actual number of bytes received.
 * The ``<ip_addr>`` value is a string that represents the IPv4 or IPv6 address of the remote peer.
 * The ``<port>`` value is an integer that represents the UDP port of the remote peer.

applications/serial_lte_modem/doc/nRF91_as_Zephyr_modem.rst

@@ -11,7 +11,7 @@ Overview
 ********
 
 Starting with |NCS| v2.6.0, the Serial LTE Modem (SLM) application can be used to turn an nRF91 Series SiP into a standalone modem that can be used through Zephyr's cellular modem driver.
-This means that the controlling chip can run a Zephyr application that seamlessly uses Zephyr's IP stack instead of offloaded sockets via AT commands.
+This means that the controlling chip can run a Zephyr application that seamlessly uses Zephyr's IP stack instead of offloaded sockets through AT commands.
 
 This is made possible by SLM's support of CMUX and PPP and Zephyr's cellular modem driver.
 
@@ -121,7 +121,7 @@ If SLM is running on the nRF9160 DK, the **PROG/DEBUG SW10** switch needs to be
 However, for convenience you may want to redirect SLM's logs to the SiP's UART 0 so that you do not need to reconnect the RTT client every time the board is reset.
 See the :ref:`slm_additional_config` section for information on how to do this.
 
-The logs output via UART can be seen by connecting to the appropriate UART with a serial communication program.
+The logs output through UART can be seen by connecting to the appropriate UART with a serial communication program.
 Under Linux, if the controlling chip is the nRF52840 of the nRF9160 DK, the device file of its UART 0 will typically be :file:`/dev/ttyACM1`.
 
 After both applications have been flashed to their respective chips and you are connected to receive logs, you can reset the controlling chip.

doc/nrf/app_dev/bootloaders_dfu/dfu_tools_mcumgr_cli.rst

@@ -396,7 +396,7 @@ Adding names requires an additional step:
     STATS_NAME(my_stats, my_stat_counter3)
   STATS_NAME_END(my_stats);
 
-The :kconfig:option:`CONFIG_MCUMGR_GRP_STAT_MAX_NAME_LEN` Kconfig option sets the maximum length of a section name that can can be accepted as parameter for showing the section data.
+The :kconfig:option:`CONFIG_MCUMGR_GRP_STAT_MAX_NAME_LEN` Kconfig option sets the maximum length of a section name that can be accepted as parameter for showing the section data.
 This may need adjustment for particularly long section names.
 
 .. note::
@@ -479,7 +479,7 @@ To upload a new file to a littleFS storage, mounted under ``/lfs``, use the foll
 where ``25`` is the size of the file.
 
 To download a file, first you must use the ``fs`` command with the :kconfig:option:`CONFIG_FILE_SYSTEM_SHELL` Kconfig option enabled.
-This allows operations via remote shell.
+This allows operations using remote shell.
 Create a new file on the remote system:
 
 .. code-block:: console

doc/nrf/app_dev/bootloaders_dfu/qspi_xip_split_image.rst

@@ -152,7 +152,7 @@ Configure :ref:`configuration_system_overview_sysbuild` to enable the required K
 
    .. tabs::
 
-      .. group-tab:: With networe core support
+      .. group-tab:: With network core support
 
          .. code-block:: cmake
 
@@ -220,7 +220,7 @@ The standard procedure will program the firmware using the default nrfjprog conf
 Programming using a different SPI mode
 ======================================
 
-If you are using an a different SPI mode on the QSPI interface, such as DSPI, you must use a custom :file:`Qspi.ini` file.
+If you are using a different SPI mode on the QSPI interface, such as DSPI, you must use a custom :file:`Qspi.ini` file.
 The following is an example for the Thingy:53, which supports DSPI and PP:
 
 .. literalinclude:: ../../../../samples/nrf5340/extxip_smp_svr/Qspi_thingy53.ini

doc/nrf/app_dev/config_and_build/sysbuild/sysbuild_images.rst

@@ -190,8 +190,8 @@ sysbuild.cmake:
 
 .. _sysbuild_images_adding_via_a_zephyr_module:
 
-Adding via a zephyr module
---------------------------
+Adding through a Zephyr module
+------------------------------
 
 To add images in a Zephyr module, create a folder within the module to hold the `Kconfig.sysbuild` and (optionally, if needed) `CMakeLists.txt` files.
 Then, add this folder to the Zephyr module file:

doc/nrf/app_dev/device_guides/nrf53/qspi_xip_guide_nrf5340.rst

@@ -92,7 +92,7 @@ See the following snippet for an example of the Nordic Thingy:53 configuration t
     };
 
 .. note::
-    Due to QSPI peripheral product anomaly, the QSPI peripheral must be ran with the ``HFCLK192MCTRL=0`` setting.
+    Due to QSPI peripheral product anomaly, the QSPI peripheral must be run with the ``HFCLK192MCTRL=0`` setting.
     Any other value may cause undefined operation of the device.
 
 Add the following to the DTS overlay for your board:

doc/nrf/app_dev/device_guides/wifi_coex.rst

@@ -9,7 +9,7 @@ Coexistence of short-range radio and other radios
 
 This guide describes how to add short-range radio and other radio coexistence support to your application in |NCS|.
 
-Short-range RF technologies (here referred to as SR), such as Bluetooth LE or 802.15.4, use a different radio than other technologies like Wi-Fi or LTE (here referred to as *the other radios*).
+Short-range RF technologies (here referred to as SR), such as Bluetooth® LE or 802.15.4, use a different radio than other technologies like Wi-Fi®  or LTE (here referred to as *the other radios*).
 However, if both SR and the other radio attempt to transmit simultaneously, the radio frequency (RF) waves interfere with each other, causing decreased performance and higher power consumption.
 Also, in cases like receiving an acknowledgment (ACK), radios should not transmit to ensure correct reception.
 

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

@@ -47,7 +47,7 @@ The following is the reset behavior when the LCS of the nRF54H20 SoC is in the `
      - Initiates a reset using the CTRL-AP through the On-Board Debugger (OBD).
        The register used is ``RESET`` (address offset: ``0x00``).
    * - ``RESET_PIN``
-     - J-Link toggles the **RESET** pin via OBD.
+     - J-Link toggles the **RESET** pin using OBD.
    * - ``RESET_VIA_SECDOM``
      - Not supported.
    * - ``RESET_DEFAULT``
@@ -67,9 +67,9 @@ The following is the reset behavior when the LCS of the nRF54H20 SoC is either i
      - Not supported.
    * - ``RESET_HARD``
      - Initiates a reset using the CTRL-AP through the On-Board Debugger (OBD).
-       The register used is ``RESET`` (address offset: ``0x00``).
+       The register used is **RESET** (address offset: ``0x00``).
    * - ``RESET_PIN``
-     - J-Link toggles the ``RESET`` pin via OBD.
+     - J-Link toggles the **RESET** pin using OBD.
    * - ``RESET_VIA_SECDOM``
      - Uses the CTRL-AP mailbox to send a local domain reset request to the Secure Domain Firmware (SDFW).
 

doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_customize_dfu.rst

@@ -166,7 +166,7 @@ Metadata file
 The :file:`metadata.yaml` file contains information about the Nordic Semiconductor manifest templates from which the custom manifest templates were derived.
 The file should be added into the version control system alongside the custom manifest templates.
 
-The ``west suit-manifest review`` command uses the metadata to display the changes between the lastly linked Nordic Semiconductor manitest templates and the manifest templates that are present in the |NCS| release that is currently being used.
+The ``west suit-manifest review`` command uses the metadata to display the changes between the lastly linked Nordic Semiconductor manifest templates and the manifest templates that are present in the |NCS| release that is currently being used.
 
 The ``west suit-manifest review --accept`` command updates the metadata to link with the Nordic Semiconductor manifest templates that are present in the |NCS| release that is currently being used.
 
@@ -194,10 +194,10 @@ Specifically, in the basic case:
 * :kconfig:option:`CONFIG_SUIT_MPI_RAD_LOCAL_1_VENDOR_NAME`
 * :kconfig:option:`CONFIG_SUIT_MPI_RAD_LOCAL_1_CLASS_NAME`
 
-These Kconfigs are used during Manifest Provisioning Information (MPI) generation.
+These Kconfig options are used during Manifest Provisioning Information (MPI) generation.
 After the MPI has been flashed, it is read by the Secure Domain Firmware, which can then use it to verify if the UUIDs in a manifest are correct,
 
-As as an example, after adding the following lines to the :file:`prj.conf` file:
+As an example, after adding the following lines to the :file:`prj.conf` file:
 
 .. code-block::
 
@@ -332,7 +332,7 @@ For more information, see the file available in the sample and `Jinja documentat
             suit-components:
             - - CAND_MFST
             - 0
-   {%- if radio is defined %}                                         # Add section below only, in case the radio core has been already been built.
+   {%- if radio is defined %}                                         # Add section below only, in case the radio core has already been built.
       {%- set component_index = component_index + 1 %}                             # Increment `component_index`.
       {%- set radio_component_index = component_index %}              # Store the current component index for further use.
       {{- component_list.append( radio_component_index ) or ""}}      # Append the current component index to the common list.
@@ -356,7 +356,7 @@ For more information, see the file available in the sample and `Jinja documentat
 Reference for editing manifest values
 -------------------------------------
 
-Some entries in the YAML file will filled in automatically, (upon first build of the sample) by the build system in the final binary DFU envelope.
+Some entries in the YAML file will be filled in automatically, (upon first build of the sample) by the build system in the final binary DFU envelope.
 
 +---------------------------------------------------------+------------------------------+--------------------------------------------------------+
 | Operation                                               | YAML entry                   | Value in the output binary envelope                    |

doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_customize_qsg.rst

@@ -95,7 +95,7 @@ This can be done by changing the class and vendor names using Kconfig options (f
    CONFIG_SUIT_MPI_APP_LOCAL_1_VENDOR_NAME="ACME Corp"
    CONFIG_SUIT_MPI_APP_LOCAL_1_CLASS_NAME="Light bulb"
 
-After rebuiling you will be able to find the following part in the :file:`./build/DFU/application.yaml` file.
+After rebuilding you can find the following part in the :file:`./build/DFU/application.yaml` file.
 
 .. code-block::
 

doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_intro.rst

@@ -7,7 +7,7 @@ Introduction to SUIT
    :local:
    :depth: 2
 
-This documentives an overview of SUIT and its characteristics.
+This documents an overview of SUIT and its characteristics.
 See the :ref:`nrf54h_suit_sample` if you want to try using the SUIT procedure on the nRF54H20 SoC.
 
 .. _ug_suit_overview:

doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_suit_recovery.rst

@@ -205,7 +205,7 @@ To turn an application into a recovery application, the following steps have to
 #. Optionally - you can modify the recovery manifest templates.
    The manifest template defined by the ``CONFIG_SUIT_ENVELOPE_TEMPLATE_FILENAME`` is first searched for in :file:`suit/<soc>` in the main application directory.
    If it is not found, :file:`suit/<soc>` in the recovery app is checked.
-   If the manifest template is still not found, the default template directory in NCS is checked (:file:`config/suit/templates`).
+   If the manifest template is still not found, the default template directory in |NCS| is checked (:file:`config/suit/templates`).
 
 #. Extend the ``SUIT_RECOVERY_APPLICATION`` choice with an option for attaching the custom recovery application.
    Then, make the ``SB_CONFIG_SUIT_RECOVERY_APPLICATION_PATH`` point to the custom application path.