doc: review comment updates

divipillai · divipillai · commit f82bc5ed966e · 2025-10-21T11:33:53.000+02:00
review comment updates

Signed-off-by: divya pillai &lt;divya.pillai@nordicsemi.no&gt;
diff --git a/README.md b/README.md
@@ -25,18 +25,14 @@ Modules communicate through [zbus](https://docs.nordicsemi.com/bundle/ncs-latest
 
 > **Note**: If you're new to nRF91 series and cellular IoT, consider taking the [Nordic Developer Academy Cellular Fundamentals Course](https://academy.nordicsemi.com/courses/cellular-iot-fundamentals).
 
-## Documentation
-
-For official documentation for the Asset tracker template, see [documentation](https://docs.nordicsemi.com/bundle/asset-tracker-template-latest/page/index.html).
-
 ## Quick Start
 
 For detailed setup instructions using the [nRF Connect for VS Code extension](https://docs.nordicsemi.com/bundle/nrf-connect-vscode/page/index.html) and advanced configuration options, see the [Getting Started Guide](docs/common/getting_started.md).
 
 For pre-built binaries, refer to the latest tag and release artifacts documentaion; [release artifacts](docs/common/release.md).
 
 > [!TIP]
-> Use the [Download nRF Connect for Desktop Quick Start application](https://www.nordicsemi.com/Products/Development-tools/nrf-connect-for-desktop/download#infotabs) for a guided setup and provisioning process.
+> Download and run the [Quick Start app](https://docs.nordicsemi.com/bundle/nrf-connect-quickstart/page/index.html) in the [nRF Connect for Desktop](https://www.nordicsemi.com/Software-and-Tools/Development-Tools/nRF-Connect-for-desktop)`_ for a guided setup and provisioning process.
 
 ### Prerequisites
 
diff --git a/docs/common/customization.md b/docs/common/customization.md
@@ -33,7 +33,7 @@ To add a new zbus event, complete the following procedure:
     };
     ```
 
-2. Implement publishing of VBUS connected and disconnected events by modifying the existing `event_callback()` function in `power.c`:
+1. Implement publishing of VBUS connected and disconnected events by modifying the existing `event_callback()` function in `power.c`:
     ```c
     if (pins & BIT(NPM13XX_EVENT_VBUS_DETECTED)) {
         LOG_DBG("VBUS detected");
@@ -70,7 +70,7 @@ To add a new zbus event, complete the following procedure:
     }
     ```
 
-3. Make sure the channel is included in the subscriber module (for example, `main.c`). Add the channel to the channel list:
+1. Make sure the channel is included in the subscriber module (for example, `main.c`). Add the channel to the channel list:
 
     ```c
     # define CHANNEL_LIST(X)      \
@@ -84,7 +84,7 @@ To add a new zbus event, complete the following procedure:
     X(POWER_CHAN,  struct power_msg) \
     ```
 
-4. Implement a handler for the new events in the subscriber module (for example, in the main module's state machine in `running_run`):
+1. Implement a handler for the new events in the subscriber module (for example, in the main module's state machine in `running_run`):
 
     ```c
     if (state_object->chan == &POWER_CHAN) {
@@ -136,7 +136,7 @@ To add a new zbus event, complete the following procedure:
     }
     ```
 
-5. Test the implementation by connecting and disconnecting VBUS to verify the LED patterns change as expected.
+1. Test the implementation by connecting and disconnecting VBUS to verify the LED patterns change as expected.
 
 ## Add environmental sensor
 
@@ -171,7 +171,7 @@ Thingy:91 X is used as an example, as it is a supported board in the template wi
     };
     ```
 
-2. Update the environmental module's state structure to include the magnetometer device reference and data storage:
+1. Update the environmental module's state structure to include the magnetometer device reference and data storage:
 
     ```c
     struct environmental_state_object {
@@ -187,7 +187,7 @@ Thingy:91 X is used as an example, as it is a supported board in the template wi
     };
     ```
 
-3. Initialize the device reference using the devicetree label:
+1. Initialize the device reference using the devicetree label:
 
     ```c
     struct environmental_state_object environmental_state = {
@@ -196,7 +196,7 @@ Thingy:91 X is used as an example, as it is a supported board in the template wi
     };
     ```
 
-4. Update the sensor sampling function signature to include the magnetometer device:
+1. Update the sensor sampling function signature to include the magnetometer device:
 
      ```c
      static void sample_sensors(const struct device *const bme680, const struct device *const bmm350)
@@ -208,7 +208,7 @@ Thingy:91 X is used as an example, as it is a supported board in the template wi
      sample_sensors(state_object->bme680, state_object->bmm350);
     ```
 
-5. Implement sensor data acquisition using the Zephyr Sensor API:
+1. Implement sensor data acquisition using the Zephyr Sensor API:
 
     ```c
     err = sensor_sample_fetch(bmm350);
@@ -241,7 +241,7 @@ Thingy:91 X is used as an example, as it is a supported board in the template wi
     };
     ```
 
-6. Update the `environmental_msg` structure in `environmental.h` to include the magnetic field data:
+1. Update the `environmental_msg` structure in `environmental.h` to include the magnetic field data:
 
     ```c
     struct environmental_msg {
@@ -254,9 +254,9 @@ Thingy:91 X is used as an example, as it is a supported board in the template wi
     };
     ```
 
-    The magnetometer data is now part of the environmental message and will be automatically handled by the storage module through the existing `ENVIRONMENTAL` data type. No changes to `storage_data_types.h` or `storage_data_types.c` are needed since the existing `environmental_check()` and `environmental_extract()` functions will handle the entire structure including the magnetic field data.
+    The magnetometer data is now part of the environmental message and will be automatically handled by the storage module through the existing `ENVIRONMENTAL` data type. No changes to `storage_data_types.h` or `storage_data_types.c` are needed since the existing `environmental_check()` and `environmental_extract()` functions will handle the entire structure, including the magnetic field data.
 
-7. Add cloud integration in the `send_storage_data_to_cloud()` function in `cloud.c` to send magnetometer data to nRF Cloud. Add this code after the existing environmental sensor data handling:
+1. Add cloud integration in the `send_storage_data_to_cloud()` function in `cloud.c` to send magnetometer data to nRF Cloud. Add this code after the existing environmental sensor data handling:
 
     ```c
     #if defined(CONFIG_APP_ENVIRONMENTAL)
@@ -316,14 +316,14 @@ To add your own module, complete the following steps:
     mkdir -p app/src/modules/dummy
     ```
 
-2. Create the following files in the module directory:
+1. Create the following files in the module directory:
 
     - `dummy.h` - Module interface definitions.
     - `dummy.c` - Module implementation.
     - `Kconfig.dummy` - Module configuration options.
     - `CMakeLists.txt` - Build system configuration.
 
-3. In `dummy.h`, define the module's interface:
+1. In `dummy.h`, define the module's interface:
 
     ```c
     #ifndef _DUMMY_H_
@@ -363,7 +363,7 @@ To add your own module, complete the following steps:
     #endif /* _DUMMY_H_ */
     ```
 
-4. In `dummy.c`, implement the module's functionality:
+1. In `dummy.c`, implement the module's functionality:
 
     ```c
     #include <zephyr/kernel.h>
@@ -521,7 +521,7 @@ To add your own module, complete the following steps:
                     K_LOWEST_APPLICATION_THREAD_PRIO, 0, 0);
     ```
 
-5. In `Kconfig.dummy`, define module configuration options:
+1. In `Kconfig.dummy`, define module configuration options:
 
     ```kconfig
     menuconfig APP_DUMMY
@@ -557,20 +557,20 @@ To add your own module, complete the following steps:
     endif # APP_DUMMY
     ```
 
-6. In `CMakeLists.txt`, configure the build system to include the source files of the module:
+1. In `CMakeLists.txt`, configure the build system to include the source files of the module:
 
     ```cmake
     target_sources(app PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/dummy.c)
     target_include_directories(app PRIVATE .)
     ```
 
-7. Add the module to the main application's CMakeLists.txt:
+1. Add the module to the main application's CMakeLists.txt:
 
     ```cmake
     add_subdirectory(src/modules/dummy)
     ```
 
-8. Increase `CONFIG_TASK_WDT_CHANNELS` in the `prj.conf` file to accommadate for the new module's task watchdog integration.
+1. Increase the value of the `CONFIG_TASK_WDT_CHANNELS` Kconfig option in the `prj.conf` file to accommadate for the new module's task watchdog integration.
 
 The dummy module is now ready to use. It provides the following functionality:
 
diff --git a/docs/common/getting_started.md b/docs/common/getting_started.md
@@ -1,4 +1,4 @@
-# Getting Started
+# Getting started
 
 To get started with Asset tracker template, you need to set up the development environment, build the application, and run it on supported hardware.
 You can use any of the following tools, depending on your preferred development environment:
@@ -31,7 +31,7 @@ For pre-built binaries, refer to the latest tag and the [release artifacts](rele
 
 * **nRF Connect SDK toolchain v3.0.0 or later**
 
-    - Follow the instructions in the [sdk-manager command](https://docs.nordicsemi.com/bundle/nrfutil/page/nrfutil-sdk-manager/nrfutil-sdk-manager.html) documentation to install v3.1.0 of the nRF Connect SDK toolchain.
+    - Follow the instructions in the [sdk-manager command](https://docs.nordicsemi.com/bundle/nrfutil/page/nrfutil-sdk-manager/nrfutil-sdk-manager.html) documentation to install v3.0.0 of the nRF Connect SDK toolchain.
 
 ## Supported boards
 
@@ -50,13 +50,13 @@ The Asset Tracker Template is continuously verified in CI on the following board
 Before initializing, start the toolchain environment:
 
 ```shell
-nrfutil sdk-manager toolchain launch --ncs-version v3.1.0 --shell
+nrfutil sdk-manager toolchain launch --ncs-version v3.0.0 --shell
 ```
 
-Alternatively, you can run the command with a specific nRF Connect SDK version. For example, if you are using v3.1.0, run:
+Alternatively, you can run the command with a specific nRF Connect SDK version. For example, if you are using version 3.0.1, run:
 
 ```shell
-nrfutil sdk-manager toolchain launch --ncs-version v3.1.0 -- <your command>
+nrfutil sdk-manager toolchain launch --ncs-version v3.0.0 -- <your command>
 ```
 
 To run for instance the `west` command with the specified version of toolchain. You can create an alias or shell function for this command to avoid typing it in full every time.
@@ -128,7 +128,7 @@ west build -p -b thingy91x/nrf9151/ns -- -DEXTRA_CONF_FILE="overlay-memfault.con
 
 To connect to [nRF Cloud](https://nrfcloud.com), the device must be provisioned to your account. You can provision the device using one of the following methods:
 
-* **Quickstart application**: Use the [Download nRF Connect for Desktop](https://www.nordicsemi.com/Products/Development-tools/nrf-connect-for-desktop/download#infotabs) Quick Start application for a streamlined setup process.
+* **Quickstart application**: Use the [Quick Start app](https://docs.nordicsemi.com/bundle/nrf-connect-quickstart/page/index.html) in the [nRF Connect for Desktop](https://www.nordicsemi.com/Software-and-Tools/Development-Tools/nRF-Connect-for-desktop)`_  for a streamlined setup process.
 * **Manual provisioning**: Follow the detailed steps in the [Provisioning](provisioning.md) documentation.
 
 The provisioning process establishes the necessary credentials and certificates for secure communication between your device and nRF Cloud.
@@ -155,7 +155,7 @@ To test that everything is working as expected, you can do the following:
 
     ```shell
 
-    *** Booting nRF Connect SDK v3.1.0-3bfc46578e42 ***
+    *** Booting nRF Connect SDK v3.0.0-3bfc46578e42 ***
     *** Using Zephyr OS v4.0.99-a0e545cb437a ***
     Attempting to boot slot 0.
     Attempting to boot from address 0x8200.
@@ -174,7 +174,7 @@ To test that everything is working as expected, you can do the following:
     [00:00:00.257,324] <inf> spi_nor: GD25LE255E@0: 32 MiBy flash
     [00:00:00.311,828] <inf> wifi_nrf_bus: SPIM spi@b000: freq = 8 MHz
     [00:00:00.311,889] <inf> wifi_nrf_bus: SPIM spi@b000: latency = 0
-    ]mJ*** Using nRF Connect SDK v3.1.0-3bfc46578e42 ***
+    ]mJ*** Using nRF Connect SDK v3.0.0-3bfc46578e42 ***
     *** Using Zephyr OS v4.0.99-a0e545cb437a ***
     [00:00:00.520,202] <dbg> main: main: Main has started
     [00:00:00.520,263] <dbg> main: running_entry: running_entry
diff --git a/docs/common/location_services.md b/docs/common/location_services.md
@@ -1,4 +1,4 @@
-# Location Services
+# Location services
 
 The Asset Tracker uses [nRF Cloud's location services](https://docs.nordicsemi.com/bundle/nrf-cloud/page/LocationServices/LSOverview.html) to provide accurate device positioning through multiple methods. This document explains the available location services and their capabilities.
 
diff --git a/docs/common/provisioning.md b/docs/common/provisioning.md
@@ -52,7 +52,7 @@ To update device credentials:
 
 ### Manual
 
-1. Log in to the In [nRF Cloud](https://nrfcloud.com/#/) portal.
+1. Log in to the [nRF Cloud](https://nrfcloud.com/#/) portal.
 1. Select **Security Services** in the left sidebar.
 
    A panel opens to the right.
diff --git a/docs/common/release.md b/docs/common/release.md
@@ -1,61 +1,61 @@
-# Release Artifacts
+# Release artifacts
 
 This document provides a comprehensive overview of all firmware deliverables and artifacts generated by the Asset Tracker Template.
 Each firmware variant is optimized for specific use cases and hardware platforms.
 
-## Firmware Deliverables
+## Firmware deliverables
 
 The Asset Tracker Template generates multiple firmware artifacts for different hardware platforms and configurations. Each artifact is built to serve specific development, testing, or production needs.
 
-### Primary Release Artifacts
+### Primary release artifacts
 
-#### Standard Firmware Variants
+#### Standard firmware variants
 
-| **Artifact Name** | **Hardware Platform** | **Description** | **Use Case** |
+| **Artifact name** | **Hardware platform** | **Description** | **Use case** |
 |-------------------|----------------------|----------------|--------------|
 | `att-thingy91x-{VERSION}.hex` | Thingy:91 X (nRF9151) | Standard production firmware with all core features enabled | Production deployment on Thingy:91 X devices |
 | `att-thingy91-{VERSION}.hex` | Thingy:91 (nRF9160) | Legacy production firmware for older Thingy:91 devices | Production deployment on original Thingy:91 devices |
 | `att-nrf9151dk-{VERSION}.hex` | nRF9151 DK | Development kit firmware with full feature set | Development and testing on nRF9151 DK |
 | `att-nrf9160dk-{VERSION}.hex` | nRF9160 DK | Development kit firmware for nRF9160-based boards | Development and testing on nRF9160 DK |
 | `att-nrf9161dk-{VERSION}.hex` | nRF9161 DK | Development kit firmware for nRF9161-based boards | Development and testing on nRF9161 DK |
 
-#### Debug and Development Variants
+#### Debug and development variants
 
-| **Artifact Name** | **Hardware Platform** | **Description** | **Use Case** |
+| **Artifact name** | **Hardware platform** | **Description** | **Use case** |
 |-------------------|----------------------|----------------|--------------|
 | `att-thingy91x-{VERSION}-debug.hex` | Thingy:91 X (nRF9151) | Debug build with enhanced logging and diagnostic features. **Note: This build uploads diagnostic and crash data to Memfault using Nordic's account and is intended for internal use only.** | Development debugging and issue investigation |
 | `att-thingy91x-{VERSION}-mqtt.hex` | Thingy:91 X (nRF9151) | Firmware with MQTT cloud connectivity instead of CoAP | Testing MQTT-based cloud communication |
 
-#### Specialized Configuration Variants
+#### Specialized configuration variants
 
-| **Artifact Name** | **Hardware Platform** | **Description** | **Use Case** |
+| **Artifact name** | **Hardware platform** | **Description** | **Use case** |
 |-------------------|----------------------|----------------|--------------|
 | `att-thingy91x-{VERSION}-mtrace.hex` | Thingy:91 X (nRF9151) | Firmware with modem trace output enabled through UART 1 | Cellular connectivity debugging and analysis |
 | `att-nrf9151dk-{VERSION}-mtrace.hex` | nRF9151 DK | Firmware with modem trace output enabled through UART 1  | Cellular connectivity debugging and analysis |
 | `att-nrf9161dk-{VERSION}-mtrace.hex` | nRF9161 DK | Firmware with modem trace output enabled through UART 1  | Cellular connectivity debugging and analysis |
 | `att-nrf9151dk-{VERSION}-ext-gnss.hex` | nRF9151 DK | Firmware configured for external GNSS antenna | Testing with external GNSS antenna setup |
 
-### Configuration Overlays
+### Configuration overlays
 
 The firmware variants are built using different configuration overlays that modify the base functionality:
 
-| **Overlay File** | **Purpose** | **Key Features** |
+| **Overlay file** | **Purpose** | **Key features** |
 |------------------|-------------|------------------|
 | `overlay-etb.conf` | Embedded Trace Buffer (ETB) support | Hardware-level debugging and trace collection |
 | `overlay-memfault.conf` | Memfault integration | Crash reporting and device monitoring |
 | `overlay-storage-minimal.conf` | Minimal storage configuration | Reduced memory footprint with passthrough-only storage |
 | `overlay-upload-modem-traces-to-memfault.conf` | Modem trace to Memfault | Automatic upload of modem traces for analysis |
 
-### Hardware Platform Support
+### Hardware platform support
 
-#### Thingy:91 X (Primary Platform)
+#### Thingy:91 X (Primary platform)
 
 - **SoC**: nRF9151
 - **Features**: Full sensor suite, battery operation, compact form factor
 - **Target Use**: Production IoT deployments, prototyping
 - **Memory Reports**: ROM and RAM usage reports generated for optimization
 
-#### Development Kits
+#### Development kits
 
 - **nRF9151 DK**: Primary development platform for nRF9151-based projects
 - **nRF9160 DK**: Legacy development support for nRF9160-based projects
diff --git a/docs/common/test_and_ci_setup.md b/docs/common/test_and_ci_setup.md
@@ -1,4 +1,4 @@
-# Testing and CI Setup
+# Testing and CI setup
 
 The Asset Tracker Template features a comprehensive testing infrastructure with tests run both on real hardware (on target) and emulation.
 Code analysis is performed through compliance checks and SonarCloud analysis.
diff --git a/docs/common/tooling_troubleshooting.md b/docs/common/tooling_troubleshooting.md
@@ -8,6 +8,22 @@ For more knowledge on debugging and troubleshooting [nRF Connect SDK](https://gi
 - [nRF Connect SDK Debugging Guide](https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/test_and_optimize/debugging.html)
 - [Zephyr Debugging Guide](https://docs.zephyrproject.org/latest/develop/debug/index.html)
 
+## Tools for debugging and troubleshooting
+
+You can use the following tools for debugging and troubleshooting for the Asset Tracker Template:
+
+- [Shell Commands](#shell-commands)
+- [Debugging Tools](#debugging-tools)
+
+    - [Low Power Profiling](#low-power-profiling)
+    - [GDB Debugging](#gdb-debugging)
+    - [SEGGER SystemView](#segger-systemview)
+    - [Thread Analysis](#thread-analysis)
+    - [Hardfaults](#hardfaults)
+
+- [Memfault Remote Debugging](#memfault-remote-debugging)
+- [Modem Tracing](#modem-tracing)
+
 ## Shell Commands
 
 The template provides several shell commands for controlling and monitoring device behavior. Connect to the device's UART interface using either:
diff --git a/docs/index.md b/docs/index.md
@@ -31,6 +31,9 @@ For detailed setup instructions using the [nRF Connect for VS Code extension](ht
 
 For pre-built binaries, refer to the latest tag and release artifacts documentation; [release artifacts](docs/common/release.md).
 
+> [!TIP]
+> Download and run the [Quick Start app](https://docs.nordicsemi.com/bundle/nrf-connect-quickstart/page/index.html) in the [nRF Connect for Desktop](https://www.nordicsemi.com/Software-and-Tools/Development-Tools/nRF-Connect-for-desktop)`_ for a guided setup and provisioning process.
+
 ### Prerequisites
 
 * nRF Connect SDK development environment ([setup guide](https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/installation.html))
diff --git a/mkdocs.yml b/mkdocs.yml

Original file line number	Diff line number	Diff line change
`@@ -1,4 +1,4 @@`
`1`		`-# Location Services`
	`1`	`+# Location services`
`2`	`2`
`3`	`3`	`The Asset Tracker uses [nRF Cloud's location services](https://docs.nordicsemi.com/bundle/nrf-cloud/page/LocationServices/LSOverview.html) to provide accurate device positioning through multiple methods. This document explains the available location services and their capabilities.`
`4`	`4`
Original file line number	Diff line number	Diff line change
`@@ -1,4 +1,4 @@`
`1`		`-# Testing and CI Setup`
	`1`	`+# Testing and CI setup`
`2`	`2`
`3`	`3`	`The Asset Tracker Template features a comprehensive testing infrastructure with tests run both on real hardware (on target) and emulation.`
`4`	`4`	`Code analysis is performed through compliance checks and SonarCloud analysis.`