doc: Documentation fixes

Documentation fixes

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

Author: umapraseeda

applications/asset_tracker_v2/src/events/app_module_event.h

@@ -34,7 +34,7 @@ enum app_module_event_type {
 	APP_EVT_LTE_DISCONNECT,
 
 	/** Signal other modules to start sampling and report the data when
-	 *  it's ready.
+	 *  it is ready.
 	 *  The event must also contain a list with requested data types,
 	 *  @ref app_module_data_type.
 	 */

applications/machine_learning/README.rst

@@ -153,7 +153,7 @@ If you build this application for the nRF53 DK, it enables additional features s
 See :ref:`ug_thingy53` for detailed information about the mentioned features.
 
 The nRF53 DK has a J-Link debug IC that can be used to program the firmware.
-Alternatively, firmware can be updated over MCUBoot serial recovery or DFU over-the-air using Simple Management Protocol over Bluetooth.
+Alternatively, firmware can be updated over MCUboot serial recovery or DFU over-the-air using Simple Management Protocol over Bluetooth.
 Keep in mind that if you use bootloader to update firmware, the new firmware must be compatible with used bootloader and partition map.
 
 The nRF53 Development Kit uses RTT as logger's backend.

applications/matter_bridge/doc/adding_ble_bridged_device_service.rst

@@ -240,7 +240,7 @@ The following steps show how to add support for a new Bluetooth LE service calle
                return bt_gatt_subscribe(mDevice.mConn, &mGattSubscribeParams);
             }
 
-#. Add the ``MyBtServiceDataProvider`` implementation created in a previous steps to the compilation process.
+#. Add the ``MyBtServiceDataProvider`` implementation created in a previous step to the compilation process.
    To do that, edit the :file:`CMakeLists.txt` file as follows:
 
    .. code-block:: cmake

applications/matter_bridge/doc/matter_bridge_description.rst

@@ -160,7 +160,7 @@ Button 1:
     :end-before: matter_door_lock_sample_led1_end
 
 LED 2:
-   If the :kconfig:option:`CONFIG_BRIDGED_DEVICE_BT` kconfig option is set to ``y``, shows the current state of Bridge's Bluetooth LE connectivity.
+   If the :kconfig:option:`CONFIG_BRIDGED_DEVICE_BT` Kconfig option is set to ``y``, shows the current state of Bridge's Bluetooth LE connectivity.
    The following states are possible:
 
    * Turned Off - The Bridge device is in the idle state and has no Bluetooth LE devices paired.

applications/nrf_desktop/README.rst

@@ -992,8 +992,8 @@ Measuring HID report rate
 You can measure a HID report rate of your application to assess the performance of your HID device.
 This measurement allows you to check how often the host computer can get user's input from the HID device.
 
-Prerequsites
-~~~~~~~~~~~~
+Prerequisites
+~~~~~~~~~~~~~
 
 The HID report rate can be measured by using either browser-based or platform-specific tools.
 You can use any preferred HID report rate tool.

applications/nrf_desktop/doc/battery_charger.rst

@@ -28,7 +28,7 @@ For this reason, you should set :kconfig:option:`CONFIG_GPIO` option.
 By default, the module is disabled and the :ref:`CONFIG_DESKTOP_BATTERY_CHARGER_NONE <config_desktop_app_options>` option is selected.
 Set the option :ref:`CONFIG_DESKTOP_BATTERY_CHARGER_DISCRETE <config_desktop_app_options>` to enable the module.
 
-The module requires a node labeled ``battery_charger`` with a ``battery-charger`` compatible set in Devicetree.
+The module requires a node labeled ``battery_charger`` with a ``battery-charger`` compatible set in devicetree.
 The charge status output (CSO) GPIO spec, the Enable GPIO spec, and the CSO switching frequency properties are also required.
 See the following snippet for an example:
 

applications/nrf_desktop/doc/ble_qos.rst

@@ -33,7 +33,7 @@ Enable the module using the :ref:`CONFIG_DESKTOP_BLE_QOS_ENABLE <config_desktop_
 The option selects :kconfig:option:`CONFIG_BT_HCI_VS_EVT_USER`, because the module uses vendor-specific HCI events.
 
 You can use the :ref:`CONFIG_DESKTOP_BLE_QOS_STATS_PRINTOUT_ENABLE <config_desktop_app_options>` option to enable real-time QoS information printouts through a UART (e.g. a virtual COM port).
-The chosen UART needs to be specified in Devicetree using ``ncs,ble-qos-uart``.
+The chosen UART needs to be specified in devicetree using ``ncs,ble-qos-uart``.
 This option also enables and configures the COM port (USB CDC ACM).
 For this reason, the :kconfig:option:`CONFIG_USB_DEVICE_STACK` must be enabled.
 

applications/nrf_desktop/doc/fast_pair_app.rst

@@ -46,7 +46,7 @@ The option is enabled by default if :kconfig:option:`CONFIG_CAF_BLE_STATE_MAX_LO
 .. note::
    If :kconfig:option:`CONFIG_CAF_BLE_STATE_MAX_LOCAL_ID_BONDS` Kconfig option value is equal to one:
 
-   * Displaying UI indication during the Fast Pair not discoverable advertising (:kconfig:option:`CONFIG_BT_ADV_PROV_FAST_PAIR_SHOW_UI_PAIRING`) is disabled by default in the nRF Desktop advertising data configuration defined in :file:`src/util/Kconfg` file.
+   * Displaying UI indication during the Fast Pair not discoverable advertising (:kconfig:option:`CONFIG_BT_ADV_PROV_FAST_PAIR_SHOW_UI_PAIRING`) is disabled by default in the nRF Desktop advertising data configuration defined in :file:`src/util/Kconfig` file.
    * :ref:`nrf_desktop_ble_state` automatically disconnects new peers right after Bluetooth connection is established if the used Bluetooth local identity is already bonded with another peer.
 
 The :ref:`CONFIG_DESKTOP_FAST_PAIR_LIMIT_NORMAL_PAIRING <config_desktop_app_options>` can be used to allow normal Bluetooth pairing only in the pairing mode.

applications/serial_lte_modem/doc/slm_description.rst

@@ -84,7 +84,7 @@ CONFIG_SLM_NATIVE_TLS_CREDENTIAL_BUFFER_SIZE - Buffer space reserved for loading
 
 CONFIG_SLM_NATIVE_TLS_CREDENTIAL_BUFFER_COUNT - Number of buffers for loading credentials
    The number of buffers available for loading ``sec_tag`` credentials for Mbed TLS.
-   TLS client only needs the buffer when connecting, while TLS server needs the buffer as long as it running.
+   TLS client only needs the buffer when connecting, while TLS server needs the buffer as long as it is running.
    Increase the value if you need both TLS client and server running simultaneously with different ``sec_tags``.
    The default value is ``1``.
 
@@ -246,7 +246,7 @@ CONFIG_SLM_TWI - TWI support in SLM
 .. _CONFIG_SLM_UART_RX_BUF_COUNT:
 
 CONFIG_SLM_UART_RX_BUF_COUNT - Receive buffers for UART.
-   This option defines the amount of buffers for receiving (RX) UART traffic.
+   This option defines the number of buffers for receiving (RX) UART traffic.
    The default value is 3.
 
 .. _CONFIG_SLM_UART_RX_BUF_SIZE:

applications/serial_lte_modem/src/gnss/slm_at_gnss.c

@@ -127,7 +127,7 @@ static void gnss_status_set(enum gnss_status status)
 	/* A notification is sent when the GNSS status is updated.
 	 * However this gets called in interrupt context (from gnss_event_handler()),
 	 * from which UART messages cannot be sent. This task is thus delegated
-	 * to a worker, to which the the new GNSS status is passed.
+	 * to a worker, to which the new GNSS status is passed.
 	 * A FIFO rather than a single variable is used to not miss GNSS status changes
 	 * in case they happen twice (or more) before the worker had the time to process them.
 	 */

doc/nrf/config_and_build/bootloaders/bootloader_config.rst

@@ -20,7 +20,7 @@ However, there are other ways to customize your application using Kconfig option
 Using custom project configurations
 ***********************************
 
-You can use custom project configuration options for the associated image, specifying them at build time using :ref:`ug_multi_image_variables`, either temporarily until you clean the build pristinely or permamently.
+You can use custom project configuration options for the associated image, specifying them at build time using :ref:`ug_multi_image_variables`, either temporarily until you clean the build pristinely or permanently.
 
 For example, you can temporarily assign custom project configurations for both the bootloaders and a sample application as follows:
 

doc/nrf/config_and_build/bootloaders/bootloader_signature_keys.rst

@@ -14,7 +14,7 @@ Dedicated host tools like :doc:`mcuboot:imgtool` can be used to sign application
 When you use |NSIB|, a private/public key pair is by default generated during the build when you are :ref:`ug_bootloader_adding_immutable_keys`.
 You can use the methods described in the following sections to explicitly define how the key pair is to be generated.
 
-When you use MCUboot or you are :ref:`ug_bootloader_adding_upgradable_mcuboot`, MCUBoot uses keys that were generated once and are stored in the public MCUboot Git repository be default.
+When you use MCUboot or you are :ref:`ug_bootloader_adding_upgradable_mcuboot`, MCUboot uses keys that were generated once and are stored in the public MCUboot Git repository by default.
 
 .. note::
     These key pairs should only be used during development.

doc/nrf/dev_model_and_contributions/adding_code.rst

@@ -128,7 +128,7 @@ This repository showcases the following features of both the |NCS| and Zephyr:
 * Custom :ref:`devicetree bindings <zephyr:dt-bindings>`
 * Out-of-tree :ref:`drivers <zephyr:device_model_api>`
 * Out-of-tree libraries
-* Example CI configuration (using Github Actions)
+* Example CI configuration (using GitHub Actions)
 * Custom :ref:`west extension <zephyr:west-extensions>`
 
 .. example_app_end

doc/nrf/dev_model_and_contributions/code_base.rst

@@ -93,7 +93,7 @@ nRF repositories
   * Usually licensed for use on Nordic products only.
 
   nRF repositories are stand-alone and have no upstreams, since they are unique to the |NCS|.
-  Some examples of repositories of this type are:
+  Following are some examples of this type of repositories:
 
   * `sdk-nrf`_: The main repository for Nordic-developed software.
   * `sdk-nrfxlib`_: A repository containing linkable libraries developed by Nordic.

doc/nrf/device_guides/working_with_nrf/nrf53/nrf5340.rst

@@ -598,9 +598,9 @@ If not changed, then the default child image prefix for MCUboot is ``mcuboot_``
 
 .. note::
 
-   The application core can be reverted, but doing so bricks the network core upon revertion, as the reversion process fills the network core with the content currently in the RAM that pcd uses.
-   To enable this, define the ``USE_NRF53_MULTI_IMAGE_WITHOUT_UPGRADE_ONLY`` Kconfig option in the project-level Kconfig file.
-   When this is option is defined, you can enable it by setting :kconfig:option`CONFIG_USE_NRF53_MULTI_IMAGE_WITHOUT_UPGRADE_ONLY`.
+   The application core can be reverted, but doing so breaks the network core upon reversal, as the reversion process fills the network core with the content currently in the RAM that PCD uses.
+   To enable this, define the :kconfig:option:`CONFIG_USE_NRF53_MULTI_IMAGE_WITHOUT_UPGRADE_ONLY` Kconfig option in the project-level Kconfig file.
+   When this option is defined, you can enable it by setting :kconfig:option:`CONFIG_USE_NRF53_MULTI_IMAGE_WITHOUT_UPGRADE_ONLY`.
 
 The :kconfig:option:`CONFIG_NRF53_MULTI_IMAGE_UPDATE` option selects this feature by default if these options and all its other dependencies are asserted.
 

doc/nrf/device_guides/working_with_nrf/nrf70/developing/fw_patches_ext_flash.rst

@@ -10,14 +10,14 @@ Firmware patches in the external memory
 This guide explains the available options for having the nRF70 Series firmware patches reside in the external memory.
 
 .. note::
-  External memory refers to the memory that is outside the SoC, for example, an external flash memory chip, or external non-volatile memory (NVM) chip etc.
+   External memory refers to the memory that is outside the SoC, for example, an external flash memory chip, or external non-volatile memory (NVM) chip.
 
 Overview
 ********
 
-By default the nRF70 Series firmware patches are built as part of the nRF Wi-Fi driver code, residing in on-chip memory.
+By default, the nRF70 Series firmware patches are built as part of the nRF Wi-Fi driver code, residing in on-chip memory.
 The firmware patches include code that is executed on the nRF70 Series device.
-The size of the firmware patches may be considerably large, which limits the amount of on-chip code memory available for the user application.
+The size of the firmware patches might be considerably large, which limits the amount of on-chip code memory available for the user application.
 In order to increase the amount of on-chip memory available for user applications, the nRF Wi-Fi driver supports the option of using external memory, if that is available.
 
 Prerequisites
@@ -30,7 +30,7 @@ Before using this feature, make sure that the following prerequisites are comple
    The maximum size of all the firmware patches combined is 128 KB.
 
 .. note::
-    Currently, in Nordic Semiconductor SoCs, access to external memory and the Execute in Place (XIP) feature are available through the QSPI interface only.
+   Currently, in Nordic Semiconductor SoCs, access to external memory and the Execute in Place (XIP) feature are available through the QSPI interface only.
 
 Supported platforms
 ===================
@@ -41,7 +41,7 @@ The following platforms are supported:
 * nRF52840 DK with nRF7002 EK as a shield
 
 .. note::
-    Due to limitations mentioned above, the nRF7002 DK is not supported as it needs access to external memory through the SPI interface.
+   Due to limitations mentioned above, the nRF7002 DK is not supported as it needs access to external memory through the SPI interface.
 
 Available options
 *****************
@@ -56,12 +56,12 @@ Using XIP access
 
 If the application supports XIP from external memory, then the firmware patches can be loaded as part of the nRF Wi-Fi driver code (RODATA) and then relocated to the external memory.
 The nRF Wi-Fi driver accesses the firmware patches using XIP feature and downloads the firmware patches to the nRF70 device.
-To enable this feature, set the :kconfig:option:`CONFIG_NRF_WIFI_PATCHES_EXT_FLASH_XIP` kconfig option to ``y``.
+To enable this feature, set the :kconfig:option:`CONFIG_NRF_WIFI_PATCHES_EXT_FLASH_XIP` Kconfig option to ``y``.
 Once the build is complete, the feature can be verified by checking the memory regions summary in the build output.
 A new memory region called ``EXTFLASH`` is added to the memory regions summary, and the firmware patches are placed in this region.
 The size of the ``FLASH`` used is reduced by the size of the firmware patches.
 
-A sample memory regions summary is shown below:
+Following is a sample summary of the memory regions:
 
 .. code-block:: console
 
@@ -77,8 +77,8 @@ Using QSPI transfers to RAM
 The nRF Wi-Fi driver supports the option for offloading the nRF70 firmware patch to external non-XIP memory.
 In this case the upload of the firmware patch from the external memory to the nRF70 device happens in two stages:
 
-* first the firmware patch is loaded from the external memory onto internal RAM and
-* then it is uploaded to the nRF70 device.
+1. The firmware patch is loaded from the external memory onto internal RAM.
+#. The firmware patch is uploaded to the nRF70 device.
 
 This feature can be enabled using DTS or :ref:`snippets` feature or by using :ref:`partition_manager`.
 
@@ -87,13 +87,13 @@ Configuration
 
 The following configuration options are available:
 
-* :kconfig:option:`CONFIG_NRF_WIFI_PATCHES_EXT_FLASH_STORE`: Enables the option to store the firmware patch in external non-XIP memory.
-* :kconfig:option:`CONFIG_NRF_WIFI_FW_FLASH_CHUNK_SIZE`: Defines the size of the chunks used to read the firmware patches from the external non-XIP memory.
+* :kconfig:option:`CONFIG_NRF_WIFI_PATCHES_EXT_FLASH_STORE` - Enables the option to store the firmware patch in external non-XIP memory.
+* :kconfig:option:`CONFIG_NRF_WIFI_FW_FLASH_CHUNK_SIZE` - Defines the size of the chunks used to read the firmware patches from the external non-XIP memory.
   The default value is 8192 bytes.
 
 The external memory partition name must be defined in the devicetree or in the partition manager configuration file.
 
-* ``nrf70_fw_partition``: Defines the name of the external memory partition that stores the firmware patches.
+* ``nrf70_fw_partition`` - Defines the name of the external memory partition that stores the firmware patches.
   This must be defined in the devicetree, for example:
 
 .. code-block:: dts
@@ -110,7 +110,7 @@ The external memory partition name must be defined in the devicetree or in the p
         };
     };
 
-* ``nrf70_wifi_fw`` : Defines the name of the external memory partition that stores the firmware patches.
+* ``nrf70_wifi_fw`` - Defines the name of the external memory partition that stores the firmware patches.
   This must be defined in the partition manager configuration file, for example:
 
 .. code-block:: console
@@ -128,7 +128,7 @@ See :ref:`nrf7002dk_nrf5340` for general instructions on building.
 
 Additionally, you must enable either the `nrf70-fw-patch-ext-flash` snippet or the :kconfig:option:`CONFIG_PARTITION_MANAGER_ENABLED` option.
 
-For example, to build the :ref:`wifi_shell_sample` sample for the nRF5340 DK with the ``nrf70-fw-patch-ext-flash`` snippet enabled, run the following commands:
+For example, to build the :ref:`wifi_shell_sample` sample for the nRF5340 DK with the ``nrf70-fw-patch-ext-flash`` snippet enabled, run the following commands.
 
 With west
 ^^^^^^^^^
@@ -165,7 +165,7 @@ With CMake
 Programming
 -----------
 
-To program the firmware image with the firmware patches stored in the external memory, use the following commands:
+To program the firmware image with the firmware patches stored in the external memory, use the following commands.
 
 With west
 ^^^^^^^^^
@@ -185,7 +185,7 @@ For example, for nrfjprog:
 
 .. code-block:: console
 
-    nrfjprog -f nrf53 -s 0 --program build/zephyr/merged.hex ---sectorerase --qspisectorerase --verify --reset
+   nrfjprog -f nrf53 -s 0 --program build/zephyr/merged.hex ---sectorerase --qspisectorerase --verify --reset
 
 Updating firmware patches
 =========================

doc/nrf/device_guides/working_with_nrf/nrf70/nrf7002eb_gs.rst

@@ -14,7 +14,7 @@ The nRF7002 EB can be used to provide Wi-Fi® connectivity to compatible develop
 The nRF7002 EB has a :term:`Printed Circuit Board (PCB)` edge connector that can be used with a compatible development board such as the Nordic Thingy:53, an IoT prototyping platform from Nordic Semiconductor.
 There are also castellated holes on the side of the board that allow the EB to be used as a breakout board that can be soldered to other PCB assemblies.
 
-If this is your first time developing with a Nordic DK, read the appropriate getting started tutorial first:
+If this is your first time developing with a Nordic Semiconductor DK, read the appropriate getting started tutorial first:
 
 * :ref:`ug_nrf7002_gs`
 * :ref:`ug_thingy53_gs`

doc/nrf/device_guides/working_with_nrf/nrf70/nrf7002ek_gs.rst

@@ -15,7 +15,7 @@ The kit can be used to provide Wi-Fi® connectivity and Wi-Fi-based locationing
 The nRF7002 EK features the nRF7002 companion IC.
 In addition, the shield may be used to emulate the nRF7001 and nRF7000 companion IC variants.
 
-If this is your first time developing with a Nordic DK, read the appropriate getting started tutorial first:
+If this is your first time developing with a Nordic Semiconductor DK, read the appropriate getting started tutorial first:
 
 * :ref:`ug_nrf7002_gs`
 * :ref:`ug_nrf52_gs`

doc/nrf/device_guides/working_with_nrf/nrf91/nrf91_features.rst

@@ -258,12 +258,13 @@ You can hardcode the information in the application, or you can use a functional
 Samples and applications implementing FOTA
 ==========================================
 
-* :ref:`http_modem_full_update_sample` sample - performs a full firmware OTA update of the modem.
-* :ref:`http_modem_delta_update_sample` sample - performs a delta OTA update of the modem firmware.
-* :ref:`http_application_update_sample` sample - performs a basic application FOTA update.
-* :ref:`aws_iot` sample - performs a FOTA update using MQTT and HTTP, where the firmware download is triggered through an AWS IoT job.
-* :ref:`azure_iot_hub` sample - performs a FOTA update from the Azure IoT Hub.
-* :ref:`asset_tracker_v2` application - performs FOTA updates of the application, modem (delta), and boot (if enabled). It also supports nRF Cloud FOTA as well as AWS or Azure FOTA. Only one must be configured at a time.
+* :ref:`http_modem_full_update_sample` sample - Performs a full firmware OTA update of the modem.
+* :ref:`http_modem_delta_update_sample` sample - Performs a delta OTA update of the modem firmware.
+* :ref:`http_application_update_sample` sample - Performs a basic application FOTA update.
+* :ref:`aws_iot` sample - Performs a FOTA update using MQTT and HTTP, where the firmware download is triggered through an AWS IoT job.
+* :ref:`azure_iot_hub` sample - Performs a FOTA update from the Azure IoT Hub.
+* :ref:`asset_tracker_v2` application - Performs FOTA updates of the application, modem (delta), and boot (if enabled).
+  It also supports nRF Cloud FOTA as well as AWS or Azure FOTA. Only one must be configured at a time.
 
 .. _nrf91_ug_gnss:
 .. _nrf9160_ug_gnss: