feat: add nRF Cloud provisioning support

Add support for nRF Cloud provisioning:
- Modify the cloud module to include states for provisioning.
- Add support for reprovisioning of the device via the device shadow.
  The device will initiate reprovisioning if receiving provisioning
  commands via the device shadow. This pipeline can be used to issue
  other commands as well. Reboot also added as an example command.

  If the device has no valid credentials after boot, it is considered
  unclaimed. The user needs to claim the device using the attestation
  token. The device will back off using the cloud built-in backoff
  mechanism until it's claimed and provisioning can start.

  If the device is claimed and authenticated, it will start the
  connection immediately as before.

- Update main CDDL format to be able to parse the new shadow format.
- Add on-target test that tests different provisioning scenarios
  on target.

Documentation on how to use the feature will follow.

Signed-off-by: Simen S. Røstad <simen.rostad@nordicsemi.no>

Author: simensrostad

README.md

@@ -14,104 +14,81 @@
 
 ## Overview
 
-The Asset Tracker Template is a framework for developing IoT applications on nRF91-based devices. Built on the [nRF Connect SDK](https://www.nordicsemi.com/Products/Development-software/nRF-Connect-SDK) and [Zephyr RTOS](https://docs.zephyrproject.org/latest/), it provides a modular, event-driven architecture suitable for battery-powered IoT use cases. The framework supports features such as cloud connectivity, location tracking, and sensor data collection.
+The Asset Tracker Template is a modular framework for developing IoT applications on nRF91-based devices. Built on [nRF Connect SDK](https://www.nordicsemi.com/Products/Development-software/nRF-Connect-SDK) and [Zephyr RTOS](https://docs.zephyrproject.org/latest/), it provides an event-driven architecture for battery-powered IoT use cases with cloud connectivity, location tracking, and sensor data collection.
 
-The system is organized into modules, each responsible for a specific functionality, such as managing network connectivity, handling cloud communication, or collecting environmental data. Modules communicate through [zbus](https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/services/zbus/index.html) channels, ensuring loose coupling and maintainability.
+The system uses modules that communicate through [zbus](https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/services/zbus/index.html) channels for loose coupling and maintainability. It's suitable for asset tracking, environmental monitoring, and other IoT applications requiring modularity and power efficiency.
 
-This template is suitable for applications like asset tracking, environmental monitoring, and other IoT use cases requiring modularity, configurability, and efficient power management. It includes a test setup with GitHub Actions for automated testing and continuous integration.
+**Supported hardware**: [Thingy:91 X](https://www.nordicsemi.com/Products/Development-hardware/Nordic-Thingy-91-X), [nRF9151 DK](https://www.nordicsemi.com/Products/Development-hardware/nRF9151-DK)
 
-**Supported and verified hardware**:
-
-* [Thingy:91 X](https://www.nordicsemi.com/Products/Development-hardware/Nordic-Thingy-91-X)
-* [nRF9151 DK](https://www.nordicsemi.com/Products/Development-hardware/nRF9151-DK)
-
-If you are not familiar with the nRF91 series SiPs and cellular in general, it's recommended to go through the [Nordic Developer Academy Cellular Fundamentals Course](https://academy.nordicsemi.com/courses/cellular-iot-fundamentals) to get a better understanding of the technology and how to customize the template for your needs.
-
-## System Architecture
-
-The template consists of the following modules:
-
-* [**Main module**](docs/modules/main.md): Central coordinator implementing business logic and control flow.
-* [**Network module**](docs/modules/network.md): Manages LTE connectivity and tracks network status.
-* [**Cloud module**](docs/modules/cloud.md): Handles communication with nRF Cloud using CoAP.
-* [**Location module**](docs/modules/location.md): Provides location services using GNSS, Wi-Fi and cellular positioning.
-* [**LED module**](docs/modules/led.md): Controls RGB LED for visual feedback on Thingy:91 X.
-* [**Button module**](docs/modules/button.md): Handles button input for user interaction.
-* [**FOTA module**](docs/modules/fota.md): Manages firmware over-the-air updates.
-* [**Environmental module**](docs/modules/environmental.md): Collects environmental sensor data.
-* [**Power module**](docs/modules/power.md): Monitors battery status and provides power management.
-
-The image below illustrates the system architecture and the interaction between the modules.
-The zbus channels are indicated with colored arrows showing the direction of communication, with the arrows pointing in to the module that is subscribing to the respective channel.
-
-![System overview](docs/images/system_overview.svg)
-
-The system archtecture is described in more detail in the [Architecture](docs/common/architecture.md) document.
-
-### Key Technical Features
-
-1. **State Machine Framework (SMF)**
-   * Each module implements its own state machine using Zephyr's [State Machine Framework](https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/services/smf/index.html).
-   * Run-to-completion model ensures predictable behavior.
-
-2. **Message-Based Communication (zbus)**
-   * Modules communicate through dedicated message channels using [zbus](https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/services/zbus/index.html).
-
-3. **Modular Architecture**
-   * Separation of concerns between modules.
-   * Each module that performs blocking operations runs in its own thread and use zbus message subscribers to queue messages.
-   * Non-blocking modules use zbus listeners for immediate processing.
-
-4. **Power Optimization**
-   * LTE Power Saving Mode (PSM) enabled by default.
-   * Configurable power-saving features.
-
-### Customization and Extension
-
-The framework is designed for customization, allowing developers to:
-
-* Modify the central business logic in the `main.c` file.
-* Enable, disable and configure modules via Kconfig options.
-* Add new modules following the established patterns.
-* Modify existing modules to suit specific requirements.
-* Contribute to the open-source project by submitting improvements, bug fixes, or new features.
-
-More information on how to customize the template can be found in the [Customization](docs/common/customization.md) document.
+> **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).
 
 ## Quick Start
 
-This section provides a brief introduction to building and running the Asset Tracker Template on supported hardware. For detailed instructions, refer to the [Getting Started](docs/common/getting_started.md) document.
+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).
 
 ### Prerequisites
 
-* nRF Connect SDK development environment ([Getting started guide](https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/installation.html))
+* nRF Connect SDK development environment ([setup guide](https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/installation.html))
 
 ### Build and Run
 
-1. Initialize workspace:
+<details>
+<summary>1. <strong>Initialize workspace:</strong></summary>
 
 ```shell
 # Launch toolchain
-nrfutil sdk-manager toolchain launch --ncs-version v3.0.0 --shell # Or the version you are using
+nrfutil sdk-manager toolchain launch --ncs-version v3.0.0 --shell
 
 # Initialize workspace
 west init -m https://github.com/nrfconnect/Asset-Tracker-Template.git --mr main asset-tracker-template
 cd asset-tracker-template/project/app
 west update
 ```
+</details>
 
-2. Build and flash:
+<details>
+<summary>2. <strong>Build and flash:</strong></summary>
 
 ```shell
 west build --pristine --board thingy91x/nrf9151/ns
 west thingy91x-dfu  # For Thingy:91 X serial bootloader
-# Or if you use an external debugger (ensure that nRF9151 is selected with the switch on the Thingy:91 X)
+# Or with external debugger:
 west flash --erase
 ```
+</details>
+
+<details>
+<summary>3. <strong>Provision device:</strong></summary>
+
+Use [nRF Connect for Desktop Quickstart](https://docs.nordicsemi.com/bundle/nrf-connect-desktop/page/index.html) to provision the device for nRF Cloud CoAP connectivity. See [Provisioning](docs/common/provisioning.md) for details.
+</details>
+
+## System Architecture
+
+Core modules include:
+
+* **[Main](docs/modules/main.md)**: Central coordinator implementing business logic
+* **[Network](docs/modules/network.md)**: LTE connectivity management
+* **[Cloud](docs/modules/cloud.md)**: nRF Cloud CoAP communication
+* **[Location](docs/modules/location.md)**: GNSS, Wi-Fi, and cellular positioning
+* **[LED](docs/modules/led.md)**: RGB LED control for Thingy:91 X
+* **[Button](docs/modules/button.md)**: User input handling
+* **[FOTA](docs/modules/fota.md)**: Firmware over-the-air updates
+* **[Environmental](docs/modules/environmental.md)**: Sensor data collection
+* **[Power](docs/modules/power.md)**: Battery monitoring and power management
+
+![System overview](docs/images/system_overview.svg)
+
+### Key Features
+
+* **State Machine Framework (SMF)**: Predictable behavior with run-to-completion model
+* **Message-Based Communication**: Loose coupling via [zbus](https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/services/zbus/index.html) channels
+* **Modular Architecture**: Separation of concerns with dedicated threads for blocking operations
+* **Power Optimization**: LTE PSM enabled by default with configurable power-saving features
 
-For detailed setup including nRF Cloud provisioning and advanced build configurations, see [Getting Started](docs/common/getting_started.md).
+The architecture is detailed in the [Architecture documentation](docs/common/architecture.md).
 
-## Further reading
+## Table of Content
 
 * [Getting Started](docs/common/getting_started.md)
 * [Architecture](docs/common/architecture.md)
@@ -138,7 +115,7 @@ For detailed setup including nRF Cloud provisioning and advanced build configura
   * [Modem Tracing](docs/common/tooling_troubleshooting.md#modem-tracing)
   * [Common Issues and Solutions](docs/common/tooling_troubleshooting.md#common-issues-and-solutions)
 
-### Modules
+### Module Documentation
 
 * [Button](docs/modules/button.md)
 * [Cloud](docs/modules/cloud.md)

app/Kconfig.sysbuild

@@ -21,4 +21,7 @@ endchoice
 config PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY
 	default y if BOARD_NRF9151DK_NRF9151_NS
 
+config MCUBOOT_USE_ALL_AVAILABLE_RAM
+	default y
+
 source "${ZEPHYR_BASE}/share/sysbuild/Kconfig"

app/boards/thingy91x_nrf9151_ns.conf

@@ -36,8 +36,6 @@ CONFIG_NET_STATISTICS_WIFI=y
 # Heap allocations should be changed when CONFIG_LOCATION_METHOD_WIFI_SCANNING_RESULTS_MAX_CNT
 # and CONFIG_NRF_WIFI_SCAN_MAX_BSS_CNT (which should be the same value) are changed.
 CONFIG_NRF_WIFI_CTRL_HEAP_SIZE=10240
-CONFIG_HEAP_MEM_POOL_SIZE=6144
-CONFIG_HEAP_MEM_POOL_IGNORE_MIN=y
 
 # Wi-Fi location
 CONFIG_LOCATION_METHOD_WIFI=y

app/prj.conf

@@ -25,7 +25,7 @@ CONFIG_TFM_SPM_LOG_LEVEL_DEBUG=y
 CONFIG_MAIN_STACK_SIZE=2560
 # Extended AT host/monitor stack/heap sizes since some nrf_cloud credentials are longer than 1024 bytes.
 CONFIG_AT_MONITOR_HEAP_SIZE=2176
-CONFIG_HEAP_MEM_POOL_SIZE=10000
+CONFIG_HEAP_MEM_POOL_SIZE=12288
 CONFIG_HEAP_MEM_POOL_IGNORE_MIN=y
 CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=1280
 
@@ -230,3 +230,17 @@ CONFIG_TASK_WDT_MIN_TIMEOUT=10000
 # Device power management
 CONFIG_PM_DEVICE=y
 CONFIG_PM_DEVICE_SHELL=y
+
+# nRF Cloud Provisioning
+CONFIG_MODEM_ATTEST_TOKEN=y
+CONFIG_NRF_PROVISIONING=y
+CONFIG_NRF_PROVISIONING_LOG_LEVEL_DBG=y
+CONFIG_NRF_PROVISIONING_CBOR_RECORDS=5
+CONFIG_NRF_PROVISIONING_COAP=y
+CONFIG_NRF_PROVISIONING_CODEC=y
+CONFIG_NRF_PROVISIONING_CBOR=y
+CONFIG_NRF_PROVISIONING_WITH_CERT=y
+CONFIG_NRF_PROVISIONING_RX_BUF_SZ=4096
+CONFIG_NRF_PROVISIONING_TX_BUF_SZ=4096
+CONFIG_NRF_PROVISIONING_CODEC_AT_CMD_LEN=2048
+CONFIG_NRF_PROVISIONING_CODEC_RX_SZ_START=2048

app/src/cbor/CMakeLists.txt

@@ -13,7 +13,7 @@ set(zcbor_command
 	--cddl ${CMAKE_CURRENT_SOURCE_DIR}/device_shadow.cddl
 	--decode # Generate decoding functions
 	--short-names # Attempt to make generated symbol names shorter (at the risk of collision)
-	-t config-object # Create a public API for decoding the "config-object" type from the cddl file
+	-t desired-object # Create a public API for decoding the "desired-object" type from the cddl file
 	--output-cmake device_shadow.cmake # The generated cmake file will be placed here
 )
 execute_process(COMMAND ${zcbor_command}

app/src/cbor/cbor_helper.c

@@ -4,22 +4,47 @@
  * SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
  */
 #include <errno.h>
+#include <string.h>
+
+#include "cbor_helper.h"
 #include "device_shadow_decode.h"
 
-int get_update_interval_from_cbor_response(const uint8_t *cbor,
-					   size_t len,
-					   uint32_t *interval_sec)
+#include <zephyr/logging/log.h>
+
+LOG_MODULE_REGISTER(cbor_helper, CONFIG_APP_LOG_LEVEL);
+
+int get_parameters_from_cbor_response(const uint8_t *cbor,
+				      size_t len,
+				      uint32_t *interval_sec,
+				      uint32_t *command_type)
 {
-	struct config_object object = { 0 };
-	size_t not_used;
+	int err;
+	struct desired_object desired_object = { 0 };
+	size_t decode_len = len;
 
-	int err = cbor_decode_config_object(cbor, len, &object, &not_used);
+	if (!cbor || !interval_sec || !command_type || len == 0) {
+		return -EINVAL;
+	}
 
+	err = cbor_decode_desired_object(cbor, decode_len, &desired_object, &decode_len);
 	if (err) {
+		LOG_ERR("cbor_decode_desired_object, error: %d", err);
+		LOG_HEXDUMP_ERR(cbor, len, "Unexpected CBOR data");
 		return -EFAULT;
 	}
 
-	*interval_sec = object.update_interval;
+	if (desired_object.config_present && desired_object.config.update_interval_present) {
+		*interval_sec = desired_object.config.update_interval.update_interval;
+	} else {
+		LOG_DBG("Update interval parameter not present");
+	}
+
+	if (desired_object.command_present) {
+		*command_type = desired_object.command.type;
+		/* ID entry not used */
+	} else {
+		LOG_DBG("Command parameter not present");
+	}
 
 	return 0;
 }

app/src/cbor/cbor_helper.h

@@ -6,18 +6,23 @@
 
 #include <zephyr/types.h>
 
+#define CLOUD_COMMAND_TYPE_PROVISION 1
+#define CLOUD_COMMAND_TYPE_REBOOT 2
+
 /**
- * @brief Get the update interval from a CBOR buffer.
+ * @brief Get the device shadow parameters from a CBOR buffer.
  *
  * @param[in]  cbor         The CBOR buffer.
  * @param[in]  len          The length of the CBOR buffer.
- * @param[out] interval_sec The update interval in seconds.
+ * @param[out] interval_sec Update interval in seconds.
+ * @param[out] command_type Cloud command type.
  *
  * @returns 0 If the operation was successful.
  *	    Otherwise, a (negative) error code is returned.
  * @retval -EFAULT if the CBOR buffer is invalid.
  *
  */
-int get_update_interval_from_cbor_response(const uint8_t *cbor,
-					   size_t len,
-					   uint32_t *interval_sec);
+int get_parameters_from_cbor_response(const uint8_t *cbor,
+				      size_t len,
+				      uint32_t *interval_sec,
+				      uint32_t *command_type);

app/src/cbor/device_shadow.cddl

@@ -1,5 +1,25 @@
-config-object = {
-    "config": {
-        "update_interval": uint .size 4
-    }
+; Device Shadow Desired Object Definition
+; ---------------------------------------
+; This section defines the structure of the "desired" object in the device shadow.
+; All sections are optional, but if present, they must appear in the specified order when decoding the CBOR buffer.
+;
+; Sections:
+; 1. "config": Contains device configuration parameters.
+;    - "update_interval": (optional) A 4-byte unsigned integer specifying the update interval.
+;    - Additional configuration parameters may be included as key-value pairs (tstr => any).
+;
+; 2. "command": (optional) An array specifying a command for the device to execute.
+;    - Structure: [type, id]
+;      - type: 4-byte unsigned integer indicating the command type.
+;      - id:   4-byte unsigned integer indicating the command ID.
+;
+; Any additional fields may be included as key-value pairs (tstr => any).
+
+desired-object = {
+    ? "config": {
+        ? "update_interval": uint .size 4,
+        * tstr => any
+    },
+    ? "command": [type: uint .size 4, id: uint .size 4],
+    * tstr => any
 }