doc: Doc fixes for 2.8

Doc fixes for 2.8 - release task

Signed-off-by: Uma Praseeda <[email protected]>
(cherry picked from commit a6fe428)

Author: umapraseeda

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: