doc: Doc fixes for 2.9

Doc check and fixes for 2.9 Signed-off-by: Uma Praseeda <[email protected]>
nrfconnect · Dec 11, 2024 · 1f4422e · 1f4422e
1 parent 4c6ab4d
commit 1f4422e
Show file tree

Hide file tree

Showing 115 changed files with 221 additions and 215 deletions.
diff --git a/applications/asset_tracker_v2/doc/asset_tracker_v2_description.rst b/applications/asset_tracker_v2/doc/asset_tracker_v2_description.rst
@@ -121,7 +121,7 @@ Overlay configurations files that enable specific features:
 * :file:`overlay-azure.conf` - Configuration file that enables communication with Azure IoT Hub.
 * :file:`overlay-lwm2m.conf` - Configuration file that enables communication with AVSystem's Coiote IoT Device Management.
 * :file:`overlay-pgps.conf` - Configuration file that enables P-GPS.
-* :file:`overlay-nrf7002ek-wifi-scan-only.conf` - Configuration file that enables Wi-Fi scanning with nRF7002 EK.
+* :file:`overlay-nrf7002ek-wifi-scan-only.conf` - Configuration file that enables Wi-Fi® scanning with nRF7002 EK.
 * :file:`overlay-low-power.conf` - Configuration file that achieves the lowest power consumption by disabling features that consume extra power, such as LED control and logging.
 * :file:`overlay-debug.conf` - Configuration file that adds additional verbose logging capabilities and enables the debug module.
 * :file:`overlay-memfault.conf` - Configuration file that enables `Memfault`_.

diff --git a/applications/asset_tracker_v2/doc/cloud_wrapper.rst b/applications/asset_tracker_v2/doc/cloud_wrapper.rst
@@ -210,7 +210,7 @@ Device-to-cloud (D2C)
 +------------------------------+----------------------------------------------------+
 | Neighbor cell measurements   | ``<topic_prefix>/<imei>/d2c``                      |
 +------------------------------+----------------------------------------------------+
-| Wi-Fi access points          | ``<topic_prefix>/<imei>/d2c``                      |
+| Wi-Fi® access points         | ``<topic_prefix>/<imei>/d2c``                      |
 +------------------------------+----------------------------------------------------+
 | Button presses               | ``<topic_prefix>/<imei>/d2c``                      |
 +------------------------------+----------------------------------------------------+

diff --git a/applications/asset_tracker_v2/doc/data_module.rst b/applications/asset_tracker_v2/doc/data_module.rst
@@ -130,7 +130,7 @@ CONFIG_DATA_SAMPLE_NEIGHBOR_CELLS_DEFAULT
 .. _CONFIG_DATA_SAMPLE_WIFI_DEFAULT:
 
 CONFIG_DATA_SAMPLE_WIFI_DEFAULT
-   This configuration includes Wi-Fi APs during sampling.
+   This configuration includes Wi-Fi® APs during sampling.
    Enabled by default.
 
 Other options:

diff --git a/applications/asset_tracker_v2/doc/location_module.rst b/applications/asset_tracker_v2/doc/location_module.rst
@@ -10,7 +10,7 @@ Location module
 .. important::
    |ATv2_maintenance_note|
 
-The location module controls the GNSS, cellular and Wi-Fi positioning functionality.
+The location module controls the GNSS, cellular and Wi-Fi® positioning functionality.
 It can be used to retrieve the location of the device in the form of events containing a position, velocity and time (PVT) structure.
 
 Features

diff --git a/applications/matter_bridge/README.rst b/applications/matter_bridge/README.rst
@@ -8,7 +8,7 @@ The bridge device allows the use of non-Matter devices in a :ref:`Matter fabric
 The devices on the non-Matter side of the Matter bridge are called *bridged devices*.
 
 The Matter bridge device functions as a Matter accessory, allowing it to be paired with and controlled through a Matter network.
-This network can be constructed using either a low-power 802.11ax (Wi-Fi 6) or 802.15.4 (Thread) protocol.
+This network can be constructed using either a low-power 802.11ax (Wi-Fi® 6) or 802.15.4 (Thread) protocol.
 
 Currently the Matter bridge application supports the following types of *bridged devices*:
 

diff --git a/applications/matter_bridge/doc/adding_ble_bridged_device_service.rst b/applications/matter_bridge/doc/adding_ble_bridged_device_service.rst
@@ -3,7 +3,7 @@
 Adding support for a new Bluetooth LE service
 #############################################
 
-The Matter Bridge application supports bridging Bluetooth LE devices using :ref:`LED Button Service <lbs_readme>` and :zephyr:code-sample:`ble_peripheral_esp` Bluetooth services.
+The Matter Bridge application supports bridging Bluetooth® LE devices using :ref:`LED Button Service <lbs_readme>` and :zephyr:code-sample:`ble_peripheral_esp` Bluetooth services.
 You can also add support for a proprietary Bluetooth LE service, if required by your use case.
 The functionality of the added Bluetooth LE service has to be represented by one or more device types available in the :ref:`Matter Data Model <ug_matter_device_types>`.
 For example, the :ref:`LED Button Service <lbs_readme>` is represented by the Matter On/Off Light and Matter Generic Switch device types.

diff --git a/applications/matter_bridge/doc/adding_bridged_matter_device.rst b/applications/matter_bridge/doc/adding_bridged_matter_device.rst
@@ -7,7 +7,7 @@ The Matter Bridge application supports bridging only a few Matter device types d
 However, you can select any of the available :ref:`Matter device types <ug_matter_device_types>` and add support to it in the application.
 
 You will need to implement the ``Matter Bridged Device`` and ``Bridged Device Data Provider`` roles based on the :ref:`Matter Bridge architecture <ug_matter_overview_bridge_ncs_implementation>` for the newly added Matter device type.
-The Matter Bridge application supports :ref:`simulated and Bluetooth LE <matter_bridge_app_bridged_support>` bridged device configurations.
+The Matter Bridge application supports :ref:`simulated and Bluetooth® LE <matter_bridge_app_bridged_support>` bridged device configurations.
 In this guide, the simulated provider example is presented, but the process is similar for the Bluetooth LE provider as well.
 
 The following steps show how to add support for a new Matter device type, using  the Pressure Sensor device type as an example.

diff --git a/applications/matter_bridge/doc/adding_bridged_protocol.rst b/applications/matter_bridge/doc/adding_bridged_protocol.rst
@@ -7,7 +7,7 @@ The :ref:`Matter Bridge architecture <ug_matter_overview_bridge_ncs_implementati
 The ``Matter Bridged Device`` represents the side that natively supports Matter, and the ``Bridged Device Data Provider`` represents a non-Matter interface.
 It is not specified what protocol should be used for a ``Bridged Device Data Provider`` role.
 
-The Matter Bridge application supports bridging Matter to Bluetooth LE data providers that use the Bluetooth LE protocol to communicate with physical end devices, and simulated data providers that emulate real devices behavior in the application.
+The Matter Bridge application supports bridging Matter to Bluetooth® LE data providers that use the Bluetooth LE protocol to communicate with physical end devices, and simulated data providers that emulate real devices behavior in the application.
 You can add support for any protocol as long as you are able to describe data model translation between Matter and that protocol.
 
 To provide support for a new protocol, you have to implement the ``Bridged Device Data Provider`` role that is able to communicate with the physical end devices using that protocol.

diff --git a/applications/matter_bridge/doc/matter_bridge_description.rst b/applications/matter_bridge/doc/matter_bridge_description.rst
@@ -19,7 +19,7 @@ The application supports the following development kits:
 
 .. table-from-sample-yaml::
 
-To test the Matter bridge application with the :ref:`Bluetooth LE bridged device <matter_bridge_app_bridged_support>`, you also need the following:
+To test the Matter bridge application with the :ref:`Bluetooth® LE bridged device <matter_bridge_app_bridged_support>`, you also need the following:
 
 * An additional development kit compatible with one of the following Bluetooth LE samples:
 
@@ -28,7 +28,7 @@ To test the Matter bridge application with the :ref:`Bluetooth LE bridged device
 
 * A micro-USB cable for every development kit to connect it to the PC.
 
-To commission the Matter bridge device and control it remotely through a Wi-Fi network, you also need a Matter controller device :ref:`configured on PC or smartphone <ug_matter_configuring>`.
+To commission the Matter bridge device and control it remotely through a Wi-Fi® network, you also need a Matter controller device :ref:`configured on PC or smartphone <ug_matter_configuring>`.
 This requires additional hardware depending on your setup.
 
 .. note::
@@ -437,7 +437,7 @@ CONFIG_BRIDGE_TEMPERATURE_SENSOR_BRIDGED_DEVICE
 .. _CONFIG_BRIDGE_MIGRATE_PRE_2_7_0:
 
 CONFIG_BRIDGE_MIGRATE_PRE_2_7_0
-``bool`` - Enable migration of bridged device data stored in old scheme from pre nRF SDK 2.7.0 releases.
+``bool`` - Enable migration of bridged device data stored in old scheme from pre |NCS| 2.7.0 releases.
 
 .. _CONFIG_BRIDGE_MIGRATE_VERSION_1:
 
@@ -564,7 +564,7 @@ The current maximum number of Bluetooth LE connections that can be selected usin
 
          .. group-tab:: Matter bridge over Thread
 
-            You can not increase the default number of Bluetooth LE connections in this configuration using overlays.
+            You cannot increase the default number of Bluetooth LE connections in this configuration using overlays.
             This is because the configuration uses both Thread and Bluetooth LE protocols, and limited RAM memory.
             You can still increase the number of connections by modifying the board files and decreasing the buffer sizes.
             The default number of connections is ``10``, which effectively means 9 bridged devices.

diff --git a/applications/matter_weather_station/README.rst b/applications/matter_weather_station/README.rst
@@ -9,7 +9,7 @@ Thingy:53: Matter weather station
 
 This Matter weather station application demonstrates the usage of the :ref:`Matter <ug_matter>` application layer to build a weather station device using the Nordic Thingy:53.
 Such a device lets you remotely gather different kinds of data using the device sensors, such as temperature, air pressure, and relative humidity.
-The device works as a Matter accessory device, meaning it can be paired and controlled remotely over a Matter network built on top of a low-power, 802.15.4 Thread or 802.11ax (Wi-Fi 6) network.
+The device works as a Matter accessory device, meaning it can be paired and controlled remotely over a Matter network built on top of a low-power, 802.15.4 Thread or 802.11ax (Wi-Fi® 6) network.
 You can use this application as a reference for creating your own application.
 
 .. note::

diff --git a/applications/nrf_desktop/application_kconfig.rst b/applications/nrf_desktop/application_kconfig.rst
@@ -98,8 +98,8 @@ See the :file:`Kconfig.defaults` file for details related to the default common
 
 .. _nrf_desktop_bluetooth_configuration:
 
-Bluetooth configuration
-***********************
+Bluetooth® configuration
+************************
 
 The nRF Desktop application introduces application-specific configuration options related to Bluetooth connectivity configuration.
 These options are defined in :file:`Kconfig.ble` file.

diff --git a/applications/nrf_desktop/bluetooth.rst b/applications/nrf_desktop/bluetooth.rst
@@ -7,7 +7,7 @@ nRF Desktop: Bluetooth
    :local:
    :depth: 2
 
-The nRF Desktop devices use :ref:`Zephyr's Bluetooth API <zephyr:bluetooth>` to handle the Bluetooth LE connections.
+The nRF Desktop devices use :ref:`Zephyr's Bluetooth API <zephyr:bluetooth>` to handle the Bluetooth® LE connections.
 
 This API is used only by the application modules that handle such connections.
 The information about peer and connection state is propagated to other application modules using :ref:`app_event_manager` events.

diff --git a/applications/nrf_desktop/board_configuration.rst b/applications/nrf_desktop/board_configuration.rst
@@ -40,7 +40,7 @@ nRF52840 Gaming Mouse (``nrf52840gmouse``)
       * The reference design is defined in :file:`nrf/boards/nordic/nrf52840gmouse` for the project-specific hardware.
       * To achieve gaming-grade performance:
 
-        * The application is configured to act as a gaming mouse, with both Bluetooth LE and USB transports enabled.
+        * The application is configured to act as a gaming mouse, with both Bluetooth® LE and USB transports enabled.
         * Bluetooth is configured to use Nordic's SoftDevice link layer.
 
       * The configuration with the B0 bootloader is set as default.

diff --git a/applications/nrf_desktop/doc/bas.rst b/applications/nrf_desktop/doc/bas.rst
@@ -24,7 +24,7 @@ Configuration
 
 The module is enabled with the :ref:`CONFIG_DESKTOP_BAS_ENABLE <config_desktop_app_options>` option, that is implied by the :ref:`CONFIG_DESKTOP_BT_PERIPHERAL <config_desktop_app_options>` option.
 The Battery Service is required for the HID peripheral device.
-For more information about the Bluetooth configuration in the nRF Desktop, see the :ref:`nrf_desktop_bluetooth_guide` documentation.
+For more information about the Bluetooth® configuration in the nRF Desktop, see the :ref:`nrf_desktop_bluetooth_guide` documentation.
 
 Implementation details
 **********************

diff --git a/applications/nrf_desktop/doc/ble_adv.rst b/applications/nrf_desktop/doc/ble_adv.rst
@@ -7,7 +7,7 @@ Bluetooth LE advertising module
    :local:
    :depth: 2
 
-In nRF Desktop, the |ble_adv| is responsible for controlling the Bluetooth LE advertising for the nRF Desktop peripheral device.
+In nRF Desktop, the |ble_adv| is responsible for controlling the Bluetooth® LE advertising for the nRF Desktop peripheral device.
 
 Module events
 *************

diff --git a/applications/nrf_desktop/doc/ble_passkey.rst b/applications/nrf_desktop/doc/ble_passkey.rst
@@ -22,7 +22,7 @@ Module events
 Configuration
 *************
 
-The module requires the basic Bluetooth configuration, as described in :ref:`nrf_desktop_bluetooth_guide`.
+The module requires the basic Bluetooth® configuration, as described in :ref:`nrf_desktop_bluetooth_guide`.
 The module can be used only for nRF Desktop Bluetooth Peripheral devices (:ref:`CONFIG_DESKTOP_BT_PERIPHERAL <config_desktop_app_options>`).
 
 Use the option :ref:`CONFIG_DESKTOP_BLE_ENABLE_PASSKEY <config_desktop_app_options>` to enable the module.

diff --git a/applications/nrf_desktop/doc/ble_qos.rst b/applications/nrf_desktop/doc/ble_qos.rst
@@ -88,7 +88,7 @@ The module is a configuration channel listener and provides the following config
    Average rating threshold for approving a blocked Bluetooth LE channel that is under evaluation by the QoS module.
    Fixed point value with 1/100 scaling.
 * ``wifi_rating_inc``
-   Wi-Fi strength rating multiplier.
+   Wi-Fi® strength rating multiplier.
    Increase the value to block Wi-Fi faster.
    Fixed point value with 1/100 scaling.
 * ``wifi_present_threshold``

diff --git a/applications/serial_lte_modem/doc/GNSS_AT_commands.rst b/applications/serial_lte_modem/doc/GNSS_AT_commands.rst
@@ -97,7 +97,7 @@ In periodic navigation mode, the ``<interval>`` and ``<timeout>`` parameters are
    When using P-GPS, make sure that the value of the :kconfig:option:`CONFIG_SLM_PGPS_INJECT_FIX_DATA` Kconfig option matches your use case.
    It is enabled by default but should be disabled if the device is expected to move distances longer than a few dozen kilometers between fix attempts.
 
-As an alternative to GNSS-based positioning, see :ref:`#XNRFCLOUDPOS <SLM_AT_NRFCLOUDPOS>` for cellular and Wi-Fi positioning.
+As an alternative to GNSS-based positioning, see :ref:`#XNRFCLOUDPOS <SLM_AT_NRFCLOUDPOS>` for cellular and Wi-Fi® positioning.
 
 Unsolicited notification
 ~~~~~~~~~~~~~~~~~~~~~~~~

diff --git a/applications/serial_lte_modem/doc/NRFCLOUD_AT_commands.rst b/applications/serial_lte_modem/doc/NRFCLOUD_AT_commands.rst
@@ -196,7 +196,7 @@ nRF Cloud location
 ==================
 
 The ``#XNRFCLOUDPOS`` command sends a request to nRF Cloud to determine the device's location.
-The request uses information from the cellular network, Wi-Fi access points, or both.
+The request uses information from the cellular network, Wi-Fi® access points, or both.
 
 .. note::
    To use ``#XNRFCLOUDPOS``, the following preconditions apply:

diff --git a/doc/_utils/redirects.py b/doc/_utils/redirects.py
@@ -206,6 +206,7 @@
     ("app_dev/device_guides/working_with_nrf/nrf54l/nrf54l15_gs", "gsg_guides"),
     ("device_guides/working_with_nrf/nrf54l/testing_dfu", "app_dev/device_guides/nrf54l/testing_dfu"), # Testing the DFU solution
     ("app_dev/device_guides/working_with_nrf/nrf54l/testing_dfu", "app_dev/device_guides/nrf54l/testing_dfu"),
+    ("app_dev/device_guides/nrf54l/snippets", "app_dev/device_guides/nrf54l/index"), # Removed after 2.8.0
     ("ug_nrf53", "app_dev/device_guides/nrf53/index"), # Developing with nRF53 Series (landing)
     ("nrf53", "app_dev/device_guides/nrf53/index"),
     ("device_guides/nrf53", "app_dev/device_guides/nrf53/index"),

diff --git a/doc/_zoomin/ncs.tags.yml b/doc/_zoomin/ncs.tags.yml
@@ -206,7 +206,6 @@ mapping_topics:
   - nrf/app_dev/device_guides/nrf70/nrf7002ek_dev_guide.html: ["evaluation-kits"]
   - nrf/app_dev/device_guides/nrf70/constrained.html: ["kconfig"]
   - nrf/app_dev/device_guides/nrf54l/*.html: ["nrf54-series", "nrf54l15"]
-  - nrf/app_dev/device_guides/nrf54l/snippets.html: ["nrf54l05", "nrf54l10"]
   - nrf/app_dev/device_guides/nrf54h/*.html: ["nrf54-series", "nrf54h20", "development-kits"]
   - nrf/app_dev/device_guides/nrf53/index.html: ["nrf5340", "thingy53", "development-kits",
                                                  "prototyping-platforms"]
@@ -387,6 +386,7 @@ mapping_topics:
                                                      "nrf7000"]
   - nrf/libraries/networking/wifi_mgmt_ext.html: ["wifi", "nrf70-series", "nrf7002", "nrf7001",
                                                   "nrf7000"]
+  - nrf/libraries/networking/ot_rpc.html: ["thread"]
   - nrf/libraries/networking/wifi_ready: ["wifi", "nrf70-series", "nrf7002", "nrf7001", "nrf7000"]
   - nrf/libraries/nfc/*.html: ["nfc"]
   - nrf/libraries/others/adp536x.html: ["pmic"]

diff --git a/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_adding_sysbuild.rst b/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_adding_sysbuild.rst
@@ -361,7 +361,7 @@ Using MCUboot in firmware loader mode
 
 MCUboot includes a firmware loader mode supported in sysbuild.
 This mode enables a project configuration that includes MCUboot instance (optionally with serial recovery), a main application not intended for firmware updates, and a secondary application which is dedicated to loading firmware updates.
-The benefit of this configuration is having a dedicated application for loading firmware updates, for example, over Bluetooth.
+The benefit of this configuration is having a dedicated application for loading firmware updates, for example, over Bluetooth®.
 This allows the main application to be larger in comparison to any symmetric size dual-bank mode update, which helps on devices with limited flash or RAM.
 
 To use this mode, you must create a static partition file for the application that designates the addresses and sizes of the main image and firmware loader applications.

diff --git a/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_quick_start.rst b/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_quick_start.rst
@@ -87,7 +87,7 @@ The following APIs are essential for interacting with the bootloader or implemen
    * - :ref:`lib_fota_download`
      - | Library in the nRF Connect SDK providing functions for downloading firmware files as upgrade candidates to the DFU target.
        | It is commonly used by IoT libraries, including the nRF Cloud library.
-     - OTA (LTE, Wi-Fi)
+     - OTA (LTE, Wi-Fi®)
    * - :ref:`zephyr:blinfo_api`
      - API that enables applications to access shared data from a bootloader.
      - --

diff --git a/doc/nrf/app_dev/config_and_build/cmake/index.rst b/doc/nrf/app_dev/config_and_build/cmake/index.rst
@@ -122,7 +122,7 @@ This is how you can specify them:
       * :makevar:`SNIPPET` - Select the snippet from the list in the :guilabel:`Snippets` menu.
       * Other variables - Provide CMake arguments in the :guilabel:`Extra CMake arguments` field, preceded by ``--``.
 
-      For example, to build the :ref:`location_sample` sample for the nRF9161 DK with the nRF7002 EK Wi-Fi support, select ``nrf9161dk/nrf9161/ns`` in the :guilabel:`Board` menu, :file:`overlay-nrf7002ek-wifi-scan-only.conf` in the :guilabel:`Extra Kconfig fragments` menu, and provide ``-- -DSHIELD=nrf7002ek`` in the :guilabel:`Extra CMake arguments` field.
+      For example, to build the :ref:`location_sample` sample for the nRF9161 DK with the nRF7002 EK Wi-Fi® support, select ``nrf9161dk/nrf9161/ns`` in the :guilabel:`Board` menu, :file:`overlay-nrf7002ek-wifi-scan-only.conf` in the :guilabel:`Extra Kconfig fragments` menu, and provide ``-- -DSHIELD=nrf7002ek`` in the :guilabel:`Extra CMake arguments` field.
 
    .. group-tab:: Command line
 

diff --git a/doc/nrf/app_dev/config_and_build/sysbuild/sysbuild_images.rst b/doc/nrf/app_dev/config_and_build/sysbuild/sysbuild_images.rst
@@ -3,6 +3,10 @@
 Sysbuild images
 ###############
 
+.. contents::
+   :local:
+   :depth: 2
+
 :ref:`configuration_system_overview_sysbuild` allows you to add additional images to your builds.
 
 

diff --git a/doc/nrf/app_dev/device_guides/fem/21540ek_dev_guide.rst b/doc/nrf/app_dev/device_guides/fem/21540ek_dev_guide.rst
@@ -7,7 +7,7 @@ Developing with the nRF21540 EK
    :local:
    :depth: 2
 
-The nRF21540 :term:`Evaluation Kit (EK)` is an RF :term:`Front-End Module (FEM)` for Bluetooth Low Energy, Bluetooth Mesh, 2.4 GHz proprietary, Thread, and Zigbee range extension.
+The nRF21540 :term:`Evaluation Kit (EK)` is an RF :term:`Front-End Module (FEM)` for Bluetooth® Low Energy, Bluetooth Mesh, 2.4 GHz proprietary, Thread, and Zigbee range extension.
 When combined with an nRF52 or nRF53 Series SoC, the nRF21540 RF FEM's +21 dBm TX output power and 13 dB RX gain ensure a superior link budget for up to 16x range extension.
 
 .. figure:: images/nrf21540ek.png

diff --git a/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_suit_customize_dfu.rst b/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_suit_customize_dfu.rst
@@ -96,9 +96,9 @@ Using Nordic Semiconductor templates directly in a product is strongly discourag
 
 The build system searches for the manifest templates in the following order:
 
-#. It checks if the :kconfig:option:`SB_CONFIG_SUIT_ENVELOPE_ROOT_TEMPLATE_FILENAME` or :kconfig:option:`CONFIG_SUIT_ENVELOPE_TEMPLATE_FILENAME` file exists in the :file:`<sample-dir>/suit/${SB_CONFIG_SOC}/` directory.
+#. It checks if the file provided in :kconfig:option:`SB_CONFIG_SUIT_ENVELOPE_ROOT_TEMPLATE_FILENAME` or :kconfig:option:`CONFIG_SUIT_ENVELOPE_TEMPLATE_FILENAME` exists in the :file:`<sample-dir>/suit/${SB_CONFIG_SOC}/` directory.
 
-#. It checks if the :kconfig:option:`SB_CONFIG_SUIT_ENVELOPE_ROOT_TEMPLATE_FILENAME` or :kconfig:option:`CONFIG_SUIT_ENVELOPE_TEMPLATE_FILENAME` file exists in the :file:`<sdk-nrf-dir>/nrf/config/suit/templates/${SB_CONFIG_SOC}/${SB_CONFIG_SUIT_BASE_MANIFEST_VARIANT}/` directory.
+#. It checks if the file provided in :kconfig:option:`SB_CONFIG_SUIT_ENVELOPE_ROOT_TEMPLATE_FILENAME` or :kconfig:option:`CONFIG_SUIT_ENVELOPE_TEMPLATE_FILENAME` exists in the :file:`<sdk-nrf-dir>/nrf/config/suit/templates/${SB_CONFIG_SOC}/${SB_CONFIG_SUIT_BASE_MANIFEST_VARIANT}/` directory.
 
 The build system selects the set of files from the first successful step.