doc: Doc fixes

Doc fixes

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

Author: umapraseeda

applications/ipc_radio/README.rst

@@ -68,8 +68,8 @@ You can set the supported radio configurations using the following Kconfig optio
 
 You can select the Bluetooth Low Energy serialization using the :kconfig:option:`CONFIG_IPC_RADIO_BT_SER` Kconfig option:
 
-* :kconfig:option:`CONFIG_IPC_RADIO_BT_HCI_IPC` - For the Bluetooh HCI serialization.
-* :kconfig:option:`CONFIG_IPC_RADIO_BT_RPC` - For the Bluetooh host API serialization.
+* :kconfig:option:`CONFIG_IPC_RADIO_BT_HCI_IPC` - For the Bluetooth HCI serialization.
+* :kconfig:option:`CONFIG_IPC_RADIO_BT_RPC` - For the Bluetooth host API serialization.
 
 The Bluetooth Low Energy and IEEE 802.15.4 functionalities can operate simultaneously and are only limited by available memory.
 
@@ -101,9 +101,9 @@ The following files are available:
 
 .. note::
    When you use sysbuild to build an application which uses the ipc_radio as network core image the preceding configuration files are added automatically to ipc_radio.
-   The selection of specific configuration files is determined by the sysbuild kconfig.
+   The selection of specific configuration files is determined by the sysbuild Kconfig.
 
-   For instance the :kconfig:option:`SB_CONFIG_NETCORE_IPC_RADIO_IEEE802154` kconfig enables the :file:`overlay-802154.conf` configuration file to be used with ipc_radio.
+   For instance, the :kconfig:option:`SB_CONFIG_NETCORE_IPC_RADIO_IEEE802154` Kconfig option enables the :file:`overlay-802154.conf` configuration file to be used with IPC radio firmware.
 
 Building and running as a single image
 **************************************

applications/machine_learning/common/src/modules/Kconfig.event_proxy

@@ -11,7 +11,7 @@ menuconfig ML_APP_EVENT_PROXY
 	select APP_EVENT_MANAGER_POSTINIT_HOOK
 	help
 	  Enable and initialize event manager proxy subsystem on application
-	  start. Subscribtion to events is done based on configuration file.
+	  start. Subscription to events is done based on configuration file.
 
 if ML_APP_EVENT_PROXY
 
@@ -20,8 +20,8 @@ config ML_APP_REMOTE_CORE_INITIALIZATION_TIMEOUT
 	range 10 10000
 	default 2000
 	help
-	  The time to wait for remote cores to report its readines. The time is
-	  given in miliseconds.
+	  The time to wait for remote cores to report its readiness. The time is
+	  given in milliseconds.
 
 module = ML_APP_EVENT_PROXY
 module-str = event proxy module

applications/matter_bridge/doc/matter_bridge_description.rst

@@ -225,7 +225,7 @@ Controlling a simulated On/Off Light bridged device
       uart:~$ matter_bridge onoff 1 3
 
    Note that the above command will only work if the :ref:`CONFIG_BRIDGED_DEVICE_SIMULATED_ONOFF_SHELL <CONFIG_BRIDGED_DEVICE_SIMULATED_ONOFF_SHELL>` option is selected in the build configuration.
-   If the Kconfig option is not selected, the simulated device changes its state periodically in autonomous manner and can not be controlled by using shell commands.
+   If the Kconfig option is not selected, the simulated device changes its state periodically in autonomous manner and cannot be controlled by using shell commands.
 
 Controlling a simulated On/Off Light Switch bridged device
    Use the following command:
@@ -416,7 +416,7 @@ If you selected the Bluetooth LE device implementation using the :ref:`CONFIG_BR
 .. _CONFIG_BRIDGE_BT_MAX_SCANNED_DEVICES:
 
 CONFIG_BRIDGE_BT_MAX_SCANNED_DEVICES
-   Set the maximum amount of scanned devices.
+   Set the maximum number of scanned devices.
 
 .. _CONFIG_BRIDGE_BT_MINIMUM_SECURITY_LEVEL:
 

applications/nrf_desktop/description.rst

@@ -7,7 +7,7 @@ nRF Desktop: Application description
    :local:
    :depth: 2
 
-The nRF Desktop application supports common input hardware interfaces like motion sensors, rotation sensors, and buttons martixes.
+The nRF Desktop application supports common input hardware interfaces like motion sensors, rotation sensors, and buttons matrixes.
 You can configure the firmware at runtime using a dedicated configuration channel established with the HID feature report.
 The same channel is used to transmit DFU packets.
 

applications/nrf_desktop/doc/wheel.rst

@@ -27,7 +27,7 @@ Enable the module with the :ref:`CONFIG_DESKTOP_WHEEL_ENABLE <config_desktop_app
 For detecting rotation, the wheel module uses Zephyr's QDEC driver.
 You can enable the module only when QDEC is configured in DTS and the Zephyr's QDEC driver is enabled with the :kconfig:option:`CONFIG_QDEC_NRFX` Kconfig option.
 If your board supports multiple QDEC instances (for example ``nrf54l15pdk/nrf54l15/cpuapp``), you also need to specify the used QDEC instance with the ``nrfdesktop-wheel-qdec`` DT alias.
-If your board supports only one QDEC instance, the module relies on the ``qdec`` DT label and you do not need to define the DT alias.
+If your board supports only one QDEC instance, the module relies on the ``qdec`` DT label and you need not define the DT alias.
 
 The QDEC DTS configuration specifies how many steps are done during one full angle.
 The sensor reports the rotation data in angle degrees.

applications/nrf_desktop/src/modules/Kconfig.hids

@@ -37,7 +37,7 @@ config DESKTOP_HIDS_SUBSCRIBER_PRIORITY
 	range 1 255
 	help
 	  HID Service over GATT reports subscriber priority. The lower value means the lower
-	  priority in subscribtion to HID reports. By default, the HID service uses the lowest
+	  priority in subscription to HID reports. By default, the HID service uses the lowest
 	  possible priority.
 
 choice BT_HIDS_DEFAULT_PERM

applications/nrf_desktop/src/modules/Kconfig.usb_state

@@ -26,7 +26,7 @@ config DESKTOP_USB_SUBSCRIBER_REPORT_PRIORITY
 	range 1 255
 	help
 	  USB reports subscriber priority. The lower value means the lower
-	  priority in subscribtion to HID reports. By default, the USB uses the highest
+	  priority in subscription to HID reports. By default, the USB uses the highest
 	  possible priority.
 
 config DESKTOP_USB_SELECTIVE_REPORT_SUBSCRIPTION

applications/serial_lte_modem/doc/CMUX_AT_commands.rst

@@ -59,15 +59,15 @@ Syntax
 
 The ``<AT_channel>`` parameter is an integer used to indicate the address of the AT channel.
 The AT channel denotes the CMUX channel where AT data (commands, responses, notifications) is exchanged.
-If specified, it must be 1, unlesss :ref:`PPP <CONFIG_SLM_PPP>` is enabled.
-If PPP is enabled, it can also be 2 (to allocate the first CMUX channel to PPP).
+If specified, it must be ``1``, unless :ref:`PPP <CONFIG_SLM_PPP>` is enabled.
+If PPP is enabled, it can also be ``2`` (to allocate the first CMUX channel to PPP).
 If not specified, the previously used address is used.
-If no address has been previously specified, the default address is 1.
+If no address has been previously specified, the default address is ``1``.
 
 .. note::
 
    If there is more than one CMUX channel (such as when using :ref:`PPP <CONFIG_SLM_PPP>`), the non-AT channels will automatically get assigned to addresses other than the one used for the AT channel.
-   For example, if PPP is enabled and CMUX is started with the ``AT#XCMUX=2`` command, the AT channel will be assigned to address 2 and the PPP channel to address 1.
+   For example, if PPP is enabled and CMUX is started with the ``AT#XCMUX=2`` command, the AT channel will be assigned to address ``2`` and the PPP channel to address ``1``.
 
 An ``OK`` response is sent if the command is accepted, after which CMUX is started.
 This means that after successfully running this command, you must set up the CMUX link and open the channels appropriately.
@@ -99,7 +99,7 @@ Response syntax
    #XCMUX: <AT_channel>,<channel_count>
 
 * The ``<AT_channel>`` parameter indicates the address of the AT channel.
-  It is between 1 and ``<channel_count>``.
+  It is between ``1`` and ``<channel_count>``.
 * The ``<channel_count>`` parameter is the total number of CMUX channels.
   It depends on what features are enabled (for example, :ref:`PPP <CONFIG_SLM_PPP>`).
 

boards/shields/pca63565/doc/index.rst

@@ -3,28 +3,35 @@
 PCA63565 shield
 ###############
 
+.. contents::
+   :local:
+   :depth: 2
+
 Overview
 ********
 
 PCA63565 is a testing shield with following sensors:
-- ADXL362 - accelerometer (SPI interface);
-- BMI270 - accelerometer and gyroscope (SPI interface),
-- BME688 - temperature, pressure, humidity and gas sensor (I2C interface with on-board pull-up resistors 4.7 kohm).
-It is targeted for testing I2C, and SPI protocols drivers.
+
+* ADXL362 - Accelerometer (SPI interface)
+* BMI270 - Accelerometer and gyroscope (SPI interface)
+* BME688 - Temperature, pressure, humidity and gas sensor (I2C interface with on-board pull-up resistors 4.7 kohm).
+           It is targeted for testing I2C, and SPI protocols drivers.
 
 Supply voltage - 1.8V
 
 SPI interface:
-- SCK (P2.6)
-- MISO (P2.9)
-- MOSI (P2.8)
-- CS ADXL362 (P2.10)
-- CS BMI270 (P1.13)
-- IRQ from ADXL or BMI270 (selected with a jumper) (P1.14)
+
+* SCK (P2.6)
+* MISO (P2.9)
+* MOSI (P2.8)
+* CS ADXL362 (P2.10)
+* CS BMI270 (P1.13)
+* IRQ from ADXL or BMI270 (selected with a jumper) (P1.14)
 
 I2C interface:
-- SCL (P1.11)
-- SDA (P1.12)
+
+* SCL (P1.11)
+* SDA (P1.12)
 
 Requirements
 ************

boards/shields/pca63566/doc/index.rst

@@ -3,21 +3,27 @@
 PCA63566 shield
 ###############
 
+.. contents::
+   :local:
+   :depth: 2
+
 Overview
 ********
 
 PCA63566 is a testing shield with sensors and transceivers:
-- temperature,
-- humidity,
-- pressure,
-- accelerometer,
-- CAN transceiver
+
+* Temperature
+* Humidity
+* Pressure
+* Accelerometer
+* CAN transceiver
+
 It is targeted for testing I2C, I3C, SPI and CAN protocols drivers.
 
 Requirements
 ************
 
-This shield is pin compatible with nrf54h20dk.
+This shield is pin compatible with nRF54H20 DK.
 
 Usage
 *****

doc/nrf/config_and_build/board_support/defining_custom_board.rst

@@ -3,6 +3,10 @@
 Defining custom board
 #####################
 
+.. contents::
+   :local:
+   :depth: 2
+
 Defining your own board is a very common step in application development, because applications are typically designed to run on boards that are not directly supported by the |NCS|, and are often custom designs not available publicly.
 
 Guidelines for custom boards

doc/nrf/config_and_build/configuring_app/output_build_files.rst

@@ -3,6 +3,10 @@
 Output build files (image files)
 ################################
 
+.. contents::
+   :local:
+   :depth: 2
+
 The building process produces each time an :term:`image file`.
 
 The image file can refer to an *executable*, a *program*, or an *ELF file*.

doc/nrf/config_and_build/dfu/index.rst

@@ -90,13 +90,13 @@ Based on these criteria, the |NCS| offers support for the following DFU alternat
 
 For device-specific guides related to DFU, see the following pages:
 
-* :ref:`Developing with nRF52 Series <ug_nrf52_developing_ble_fota>` - for how to do firmware over-the-air (FOTA) updates with nRF52 Series devices.
+* :ref:`Developing with nRF52 Series <ug_nrf52_developing_ble_fota>` - For how to do firmware over-the-air (FOTA) updates with nRF52 Series devices.
 
-* :ref:`Developing with nRF5340 DK <ug_nrf53_developing_ble_fota>` - for how to do FOTA updates and serial recovery with the nRF5340 SoC.
+* :ref:`Developing with nRF5340 DK <ug_nrf53_developing_ble_fota>` - For how to do FOTA updates and serial recovery with the nRF5340 SoC.
 
-  * :ref:`qspi_xip` - for external execute in place (XIP) for the nRF5340 SoC.
+  * :ref:`qspi_xip` - For external execute in place (XIP) for the nRF5340 SoC.
 
-* :ref:`ug_nrf70_fw_patch_update` - for nRF70 Series devices.
+* :ref:`ug_nrf70_fw_patch_update` - For nRF70 Series devices.
 
 See the following user guides for an overview of topics related to general firmware updates with the |NCS|:
 

doc/nrf/device_guides/nrf53/qspi_xip_guide_nrf5340.rst

@@ -304,6 +304,7 @@ If you wish to use the :file:`Qspi.ini` file, you will need to manually flash th
 For example, for the :ref:`smp_svr_ext_xip` sample, you need to flash the following files (paths are relative to the build directory):
 
 * :file:`<cpunet_build_subdirectory>/zephyr/merged_CPUNET.hex`
+
   * For Bluetooth stack application the path is :file:`<cpunet_build_subdirectory> hci_ipc`.
 * :file:`mcuboot/zephyr/zephyr.hex`
 * :file:`zephyr/internal_flash_signed.hex`

doc/nrf/device_guides/nrf53/serial_recovery.rst

@@ -19,7 +19,7 @@ To upload the networking image, use the following command::
      ./mcumgr image upload <build_dir_path>/zephyr/net_core_app_update.bin -e -n 3 -c serial_conn
 
 ``serial_conn`` is the serial connection configuration.
-For more information on MCUmgr image management, see :ref:`zephyr:image_mgmt`
+For more information on MCUmgr image management, see :ref:`zephyr:image_mgmt`.
 
 To enable the serial recovery of the network core while the multi-image update is not enabled in the MCUboot, set the following options:
 

doc/nrf/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_matter_thread.rst

@@ -281,7 +281,7 @@ Matter and Thread support has the following limitations on the nRF54H20 DK:
 * The ``west flash --erase`` command is blocked.
   See :ref:`ug_nrf54h20_gs_sample` for more information.
 * The factory reset functionality does not work properly.
-  After clearing all NVM storage, the device can not reboot automatically and falls into a hard fault.
+  After clearing all NVM storage, the device cannot reboot automatically and falls into a hard fault.
 
   As a workaround, press the reset button on the nRF54H20 DK board after performing a factory reset.
 * Matter over Thread commissioning might be unstable due to the lack of true random generator support on nRF54H20.

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

@@ -20,7 +20,7 @@ It consists of two main concepts: the SUIT envelope and the SUIT manifest.
 * The SUIT envelope acts as a secure container for transporting firmware updates, encapsulating the firmware binary and its manifest.
 * The SUIT manifest is a structured file with metadata essential for the update process, including firmware version, size, and hash for integrity verification.
 
-Default manifest templates are provided by Nordic and used by default during application build.
+Default manifest templates are provided by Nordic Semiconductor and used by default during application build.
 These templates are suitable for simple cases and form the basis for generating SUIT envelopes and manifests tailored to specific application requirements.
 Customization of these templates is crucial for specific use cases and security requirements.
 
@@ -62,7 +62,6 @@ Build system configuration
 
 By default the build system generates SUIT envelopes using predefined manifest templates provided by Nordic Semiconductor.
 These templates can be found in :file:`modules/lib/suit-generator/ncs`, and are suitable for standard development needs.
-.
 
 Three manifests are used in the most common case:
 
@@ -98,7 +97,7 @@ The source of the manifest templates can be configured by setting the following
 
 * :kconfig:option:`SB_CONFIG_SUIT_ENVELOPE_ROOT_TEMPLATE`
 
-* :kconfig:option:`CONFIG_SUIT_ENVELOPE_TEMPLATE` - for each of the images (application and radio core images)
+* :kconfig:option:`CONFIG_SUIT_ENVELOPE_TEMPLATE` - For each of the images (application and radio core images)
 
 One example is demonstrated with the following case:
 
@@ -115,9 +114,7 @@ One example is demonstrated with the following case:
 The following files are used to create the SUIT envelope:
 
 * Root envelope - :file:`root.yaml.jinja2`
-
 * Application domain - :file:`app.yaml.jinja2`
-
 * Radio domain - :file:`radio.yaml.jinja2`
 
 To build the described example with the provided user-defined manifest templates:
@@ -188,11 +185,8 @@ Variables and methods available in the manifest templates
 The manifest templates have access to the following:
 
 * Devicetree values (`edtlib`_ object)
-
 * Target names
-
 * Paths to binary artifacts
-
 * Application version
 
 Some of these values are stored in the Python dictionaries that are named after the target name.
@@ -201,23 +195,17 @@ For example, for the :ref:`nrf54h_suit_sample` there will be two variables avail
 The target names (the names of these variables) can be changed using the :kconfig:option:`CONFIG_SUIT_ENVELOPE_TARGET` Kconfig option for a given image.
 Each variable is a Python dictionary type (``dict``) containing the following keys:
 
-* ``name`` - name of the target
-
+* ``name`` - Name of the target
 * ``dt`` -  Devicetree representation (`edtlib`_ object)
-
-* ``binary`` - path to the binary, which holds the firmware for the target
+* ``binary`` - Path to the binary, which holds the firmware for the target
 
 Additionally, the Python dictionary holds a variable called ``version`` that holds the application version.
 With the Python dictionary you are able to, for example:
 
 * Extract the CPU ID by using ``application['dt'].label2node['cpu'].unit_addr``
-
 * Obtain the partition address with ``application['dt'].chosen_nodes['zephyr,code-partition']``
-
 * Obtain the size of partition with ``application['dt'].chosen_nodes['zephyr,code-partition'].regs[0].size``
-
 * Get the pair of URI name and the binary path by using ``'#{{ application['name'] }}': {{ application['binary'] }}``
-
 * Get the application version with ``suit-manifest-sequence-number: {{ sysbuild['config']['SB_CONFIG_SUIT_ENVELOPE_SEQUENCE_NUM'] }}``
 
 Additionally, the **get_absolute_address** method is available to recalculate the absolute address of the partition.
@@ -406,7 +394,7 @@ To restore a YAML file from a binary SUIT envelope:
 Debug a SUIT envelope
 ---------------------
 
-To debug the a SUIT envelope, by printing their parsed content to the ``stdout``, run the following:
+To debug a SUIT envelope, by printing their parsed content to the ``stdout``, run the following:
 
 .. code-block::
 

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

@@ -16,13 +16,9 @@ Overview
 The following are basic SUIT concepts you need to understand to be able to customize SUIT DFU for your device:
 
 * SUIT uses envelopes that serve as a secure transport container, and the SUIT manifest contains crucial deployment metadata.
-
 * SUIT envelopes are generated from manifest templates.
-
 * The SUIT manifest is like a blueprint that tells the system how to create a SUIT envelope, and contains instructions and metadata for the DFU procedure.
-
 * Default SUIT manifest templates are provided, but customization, especially for UUIDs, is recommended.
-
 * The manifest templates are automatically created and copied to the sample directory on the first build of SUIT samples.
 
 .. figure:: images/nrf54h20_suit_dfu_overview.png
@@ -121,5 +117,5 @@ The SUIT DFU procedure can further be customized by:
 * Generating raw UUID values
 * Changing the default location of the manifests
 
-Instructions for these actions and further customization are described in the :ref:`ug_nrf54h20_suit_customize_dfu`.
+Instructions for these actions and further customization are described in the :ref:`ug_nrf54h20_suit_customize_dfu` page.
 Additionally, you can modify SUIT components within the manifest (see the :ref:`ug_nrf54h20_suit_components` page for more information).