doc: Doc check for 3.1.0

umapraseeda · rlubos · commit 2cf084fde86b · 2025-08-12T09:18:24.000+02:00
Doc check for 3.1.0

Signed-off-by: Uma Praseeda &lt;uma.praseeda@nordicsemi.no&gt;
diff --git a/applications/nrf_desktop/bootloader_dfu.rst b/applications/nrf_desktop/bootloader_dfu.rst
@@ -330,7 +330,7 @@ The serial recovery DFU is a feature of MCUboot and you need to enable it in the
 For the configuration details, see the :ref:`nrf_desktop_configuring_mcuboot_bootloader` section.
 
 To start the serial recovery DFU, the device should boot into recovery mode, in which the bootloader is waiting for a new image upload to start.
-In the serial recovery DFU mode, the new image is transferred through an USB CDC ACM class instance.
+In the serial recovery DFU mode, the new image is transferred through a USB CDC ACM class instance.
 The bootloader overwrites the existing application located on the primary slot with the new application image.
 If the transfer is interrupted, the device cannot boot the incomplete application, and the image upload must be performed again.
 
diff --git a/applications/nrf_desktop/doc/cpu_meas.rst b/applications/nrf_desktop/doc/cpu_meas.rst
@@ -23,7 +23,7 @@ Configuration
 *************
 
 To enable this module, use the :ref:`CONFIG_DESKTOP_CPU_MEAS_ENABLE <config_desktop_app_options>` Kconfig option.
-This option selects the :kconfig:option:`CONFIG_NRF_CPU_LOAD` option, which enables the :ref:`cpu_load` library that is used to perform the measurements.
+This option selects the :kconfig:option:`CONFIG_NRF_CPU_LOAD` Kconfig option, which enables the :ref:`cpu_load` library that is used to perform the measurements.
 
 Set the time between subsequent CPU load measurements, in milliseconds, using the :ref:`CONFIG_DESKTOP_CPU_MEAS_PERIOD <config_desktop_app_options>` option.
 
diff --git a/doc/nrf/app_dev/bootloaders_dfu/mcuboot_serial_recovery.rst b/doc/nrf/app_dev/bootloaders_dfu/mcuboot_serial_recovery.rst
@@ -27,7 +27,7 @@ Uploading image
 By default, uploading an image is targeted to the primary slot.
 You can load an image to other slots only if you have enabled the ``CONFIG_MCUBOOT_SERIAL_DIRECT_IMAGE_UPLOAD`` Kconfig option.
 To use progressive slot erasing during image upload, enable the ``CONFIG_BOOT_ERASE_PROGRESSIVELY`` Kconfig option.
-As a result, a device can receive images smoothly and can erase required part of a flash automatically.
+As a result, a device can receive images smoothly and can erase the required part of a flash automatically.
 
 Implementing serial recovery
 ****************************
diff --git a/doc/nrf/app_dev/device_guides/fem/fem_nrf2220.rst b/doc/nrf/app_dev/device_guides/fem/fem_nrf2220.rst
@@ -4,7 +4,7 @@ Enabling support for nRF2220
 ############################
 
 The nRF2220 device is a range extender that you can use with nRF52, nRF53 and nRF54L Series devices.
-The nRF2220 features an GPIO and I2C interface.
+The nRF2220 features a GPIO and I2C interface.
 You can use it to fully control your front-end module.
 To use nRF2220, complete the following steps:
 
@@ -45,7 +45,7 @@ To use nRF2220, complete the following steps:
    The nRF2220 features also a built-in low-attenuation bypass circuit.
    Either the bypass or power amplifier will be used when transmitting RF signals depending on requests made by a protocol driver.
    The control of the output power of the SoC and decision to use either the bypass or the power amplifier occurs automatically.
-#. Add a following I2C bus device node on the devicetree file:
+#. Add the following I2C bus device node on the devicetree file:
 
    .. code-block:: devicetree
 
diff --git a/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_mcuboot_dfu.rst b/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_mcuboot_dfu.rst
@@ -93,7 +93,7 @@ MCUboot supports various methods for updating firmware images.
 On the nRF54H platform, you can use :ref:`swap and direct-xip modes<ug_bootloader_main_config>`.
 
 For more information, see the :file:`samples/zephyr/subsys/mgmt/mcumgr/smp_svr` sample.
-This sample demonstrates how to configure DFU feature in both MCUBoot and user application in your project.
+This sample demonstrates how to configure DFU feature in both MCUboot and user application in your project.
 It uses Simple Management Protocol for DFU and querying device information from the application.
 
 The following build flavours are available:
@@ -152,7 +152,7 @@ Additional Information
 **********************
 
 You can test BLE-based FOTA samples with the `nRF Connect Device Manager`_.
-For DFU over a serial connection, use the :ref:`dfu_tools_mcumgr_cli` tool.
+For DFU over a serial connection, use the :ref:`dfu_tools_mcumgr_cli`.
 
 .. note::
    On the nRF54H20 SoC, Direct XIP mode uses a merged image slot that combines both application and radio core images.
diff --git a/doc/nrf/app_dev/device_guides/nrf54l/kmu_provision.rst b/doc/nrf/app_dev/device_guides/nrf54l/kmu_provision.rst
@@ -152,6 +152,6 @@ If you set the ``SB_CONFIG_SECURE_BOOT_SIGNING_KEY_FILE`` Kconfig option to a PE
 If not, the build will use the default key named :file:`GENERATED_NON_SECURE_SIGN_KEY_PRIVATE.pem`, which is located in the build directory.
 Similarly, MCUboot uses the key file designated by the :Kconfig:option:`SB_CONFIG_BOOT_SIGNATURE_KEY_FILE` option.
 
-At the end of the described process the :file:`keyfile.json` file is generated in the build directory.
+At the end of the described process, the :file:`keyfile.json` file is generated in the build directory.
 This file allows key provisioning to occur simultaneously with the flashing process.
 Alternatively, you can bypass the mentioned Kconfig options and manually place a custom :file:`keyfile.json` in the build directory.
diff --git a/doc/nrf/app_dev/device_guides/nrf54l/vpr_flpr.rst b/doc/nrf/app_dev/device_guides/nrf54l/vpr_flpr.rst
@@ -33,7 +33,7 @@ However, the application core build must incorporate an overlay that enables the
 Bootstrapping the FLPR core
 ===========================
 
-The |NCS| provides a FLPR snippet that adds an overlay required for bootstrapping the FLPR core.
+The |NCS| provides an FLPR snippet that adds an overlay required for bootstrapping the FLPR core.
 Snippet's primary function is to enable the code that transfers the FLPR code to the designated region (if necessary) and to initiate the FLPR core.
 
 When building for the ``nrf54l15dk/nrf54l15/cpuflpr`` target, a minimal sample is automatically loaded onto the application core.
diff --git a/doc/nrf/libraries/caf/leds.rst b/doc/nrf/libraries/caf/leds.rst
@@ -347,7 +347,7 @@ If the flag is not set, the sequence stops and the given LED effect ends.
 Power management events
 =======================
 
-If the :kconfig:option:`CONFIG_CAF_LEDS_PM_EVENTS` Kconfig option is enabled, the module can react to following power management events:
+If the :kconfig:option:`CONFIG_CAF_LEDS_PM_EVENTS` Kconfig option is enabled, the module can react to the following power management events:
 
 * ``power_down_event``
 * ``wake_up_event``
diff --git a/doc/nrf/libraries/caf/sensor_data_aggregator.rst b/doc/nrf/libraries/caf/sensor_data_aggregator.rst
@@ -61,7 +61,7 @@ The aggregator is defined as a separate node in the devicetree and consists of t
 Implementation details
 **********************
 
-|sensor_data_aggregator| subscribes to following sensor manager events:
+|sensor_data_aggregator| subscribes to the following sensor manager events:
 
 * :c:struct:`sensor_state_event`
 * :c:struct:`sensor_event`
diff --git a/doc/nrf/libraries/networking/wifi_prov_core.rst b/doc/nrf/libraries/networking/wifi_prov_core.rst
@@ -76,7 +76,7 @@ The protocol defines four message types:
    FORGET_CONFIG       Erase the configuration and disconnect
    =================== ================================================ =============================
 
-* ``Response``: The message is for the target to provide the feedback on the result of an action to the configurator.
+* ``Response`` - The message is for the target to provide the feedback on the result of an action to the configurator.
 
   The following table details the fields of the ``Response`` message.
 
@@ -88,14 +88,14 @@ The protocol defines four message types:
    device_status       message                 Optional                 The status of the Wi-Fi on the target.
    =================== ======================= ======================== =======================================================================================
 
-  The ``status`` field can take one of following values:
+  The ``status`` field can take one of the following values:
 
-  * ``SUCCESS``: The operation is dispatched successfully.
-  * ``INVALID_ARGUMENT``: The argument is invalid.
-  * ``INVALID_PROTO``: The message cannot be encoded or decoded.
-  * ``INTERNAL_ERROR``: The operation cannot be dispatched properly.
+  * ``SUCCESS`` - The operation is dispatched successfully.
+  * ``INVALID_ARGUMENT`` - The argument is invalid.
+  * ``INVALID_PROTO`` - The message cannot be encoded or decoded.
+  * ``INTERNAL_ERROR`` - The operation cannot be dispatched properly.
 
-* ``Result``: The message is for the target to provide feedback on the Wi-Fi status to the configurator asynchronously.
+* ``Result``- The message is for the target to provide feedback on the Wi-Fi status to the configurator asynchronously.
 
   The following table details the fields of the ``Result`` message.
 
diff --git a/doc/nrf/libraries/security/trusted_storage.rst b/doc/nrf/libraries/security/trusted_storage.rst
@@ -176,7 +176,7 @@ These APIs will internally use this library to store persistent keys.
 Dependencies
 ************
 
-This library has dependencies to following libraries:
+This library has dependencies to the following libraries:
 
 * :ref:`lib_hw_unique_key`
 * :ref:`Zephyr's settings subsystem <zephyr:settings_api>`
diff --git a/doc/nrf/protocols/matter/end_product/security.rst b/doc/nrf/protocols/matter/end_product/security.rst
@@ -160,7 +160,7 @@ For example:
 See the :file:`samples/matter/common/src/app/matter_init.cpp` file for a usage example.
 
 Due to limited slots available in the KMU, the maximum number of Matter fabric is limited.
-The following table shows the all crypto materials used in Matter, the number of slots needed for each key and a Kconfig option that can be used to adjust the number of each key type:
+The following table shows all the crypto materials used in Matter, the number of slots needed for each key and a Kconfig option that can be used to adjust the number of each key type:
 
 .. list-table:: KMU slots used by Matter crypto materials
    :widths: auto
@@ -346,7 +346,7 @@ This operation requires two additional KMU slots to store the nonce and the auth
 If the :kconfig:option:`CONFIG_CHIP_CRYPTO_PSA_DAC_PRIV_KEY_KMU_ENCRYPTED` Kconfig option is set to ``n``, then the DAC private key is stored in the KMU without encryption and utilizes two KMU slots.
 
 By default, the DAC private key occupies the last slots dedicated for application purposes.
-For the non-encrypted version, it occupies last two slots (178 and 179), and for the encrypted version, it occupies the last four slots (176-179).
+For the non-encrypted version, it occupies the last two slots (178 and 179), and for the encrypted version, it occupies the last four slots (176-179).
 You can change the default slots by setting the :kconfig:option:`CONFIG_CHIP_CRYPTO_PSA_DAC_PRIV_KEY_KMU_SLOT` Kconfig option to the first slot number of the desired slots, making sure that all slots fit within the possible range.
 This means you can set it to slot numbers 0-176 for encrypted, or 0-178 for non-encrypted.
 To read more about KMU slots, see the :ref:`ug_nrf54l_crypto_kmu_slots` section of the :ref:`ug_nrf54l_cryptography` page, which details the KMU peripheral.
diff --git a/doc/nrf/protocols/thread/configuring.rst b/doc/nrf/protocols/thread/configuring.rst
@@ -88,7 +88,7 @@ In addition to the required configuration, you can configure other features such
 
 Depending on your configuration needs, you can also set the following options:
 
-* :kconfig:option:`CONFIG_NET_SOCKETS` - This option enables API similar to BSD Sockets on top of the native Zephyr networking API.
+* :kconfig:option:`CONFIG_NET_SOCKETS` - This option enables an API similar to BSD Sockets on top of the native Zephyr networking API.
   This configuration is needed for managing networking protocols.
   This configuration is available only if Zephyr networking layer is enabled.
 * :kconfig:option:`CONFIG_OPENTHREAD_SHELL` - This option enables OpenThread CLI (see `OpenThread CLI Reference`_).
diff --git a/doc/nrf/releases_and_maturity/migration/migration_3.1_54h_suit_ironside.rst b/doc/nrf/releases_and_maturity/migration/migration_3.1_54h_suit_ironside.rst
@@ -134,8 +134,8 @@ the script does the following:
   #. It extracts the address/value pairs from the ``PERIPHCONF`` section of the Zephyr ELF image.
   #. It generates two Intel HEX files:
 
-    * :file:`uicr.hex` - the new UICR entries
-    * :file:`periphconf.hex` - the MRAM-resident ``PERIPHCONF`` blob
+    * :file:`uicr.hex` - The new UICR entries
+    * :file:`periphconf.hex` - The MRAM-resident ``PERIPHCONF`` blob
 
 Both HEX files must be programmed alongside your firmware image.
 ``west flash`` handles this automatically.
diff --git a/samples/bluetooth/fast_pair/locator_tag/README.rst b/samples/bluetooth/fast_pair/locator_tag/README.rst
@@ -1362,7 +1362,7 @@ The SMP UUID is placed in the advertising data when Fast Pair advertising is in
 Device Firmware Update (DFU)
 ============================
 
-This sample uses following components for the DFU functionality:
+This sample uses the following components for the DFU functionality:
 
 * :ref:`MCUboot bootloader <mcuboot:mcuboot_ncs>` (for supported board targets)
 * :ref:`zephyr:app-version-details`
diff --git a/samples/bluetooth/mesh/dfu/target/README.rst b/samples/bluetooth/mesh/dfu/target/README.rst
@@ -141,8 +141,7 @@ The sample can also be the Target node updated by any firmware image that is com
 In both cases, the firmware needs to be signed and the firmware version increased to pass the validation when the MCUboot swaps the images.
 
 To set a new version, alter the Kconfig option :kconfig:option:`CONFIG_MCUBOOT_IMGTOOL_SIGN_VERSION` to a version that is higher than the default version of: ``"1.0.0+0"``.
-Then, after rebuilding the sample, the binary of the updated sample can be found in :file:`samples/bluetooth/mesh/dfu/target/build/target/zephyr/zephyr.signed.bin` or
-:file:`samples/bluetooth/mesh/dfu/target/build/dfu_application.zip`.
+Then, after rebuilding the sample, the binary of the updated sample can be found in :file:`samples/bluetooth/mesh/dfu/target/build/target/zephyr/zephyr.signed.bin` or :file:`samples/bluetooth/mesh/dfu/target/build/dfu_application.zip`.
 The file format to use depends on the tool you are using for the DFU procedure.
 
 To perform a DFU with this sample, the following additional information is required:
diff --git a/samples/cellular/modem_shell/README.rst b/samples/cellular/modem_shell/README.rst
@@ -951,7 +951,7 @@ Power measurements
 ==================
 
 You can perform power measurements using the `Power Profiler Kit II (PPK2)`_.
-See the documentation for instructions on how to setup the DK for power measurements.
+See the documentation for instructions on how to set up the DK for power measurements.
 The documentation shows, for example, how to connect the wires for both source meter and ampere meter modes.
 The same instructions are valid also when using a different meter.
 
diff --git a/samples/nrf5340/netboot/README.rst b/samples/nrf5340/netboot/README.rst
@@ -127,7 +127,7 @@ After programming the sample to your development kit, complete the following ste
       For testing purposes, use nRF Util to program the update image directly into the update slot.
 
 #. Reset the kit.
-#. Observe that the output includes the following lines indicating that the MCUBoot in the application core has read the update image and performed a firmware update of the network core:
+#. Observe that the output includes the following lines indicating that the MCUboot in the application core has read the update image and performed a firmware update of the network core:
 
    .. code-block:: console
 
diff --git a/snippets/nordic-flpr/README.rst b/snippets/nordic-flpr/README.rst
@@ -6,7 +6,5 @@ Nordic FLPR snippet with execution from SRAM (nordic-flpr)
 Overview
 ********
 
-This snippet allows users to build Zephyr with the capability to boot Nordic FLPR
-(Fast Lightweight Peripheral Processor) from application core.
-FLPR code is to be executed from SRAM, so the FLPR image must be built
-without the ``xip`` board variant, or with :kconfig:option:`CONFIG_XIP` disabled.
+This snippet allows you to build Zephyr with the capability to boot Nordic FLPR (Fast Lightweight Peripheral Processor) from the application core.
+The FLPR code must be executed from SRAM, so the FLPR image must be built without the ``xip`` board variant, or with the :kconfig:option:`CONFIG_XIP` Kconfig option disabled.
