DOCSEARCHbyAlgolia
Submit Docs

nRF Cloud Documentation

website·Indexed 33 days ago

https://docs.nrfcloud.com

Documentation for nRF Cloud and its integrated Memfault device monitoring solution. Includes guides on OTA updates, device vitals dashboards, and integration for ARM Cortex-M, Cortex-A, and Cortex-R devices. Covers connectivity protocols like MQTT and CoAP, Android battery debugging, CRA compliance, and the Memfault CLI for automation and CI/CD.

Tokens
265K
Snippets
1K
Records
2.2K
Agent score
65%

What's inside nRF Cloud

  1. Overview of nRF Cloud capabilities

    nRF Cloud is a platform designed for Nordic Semiconductor devices to help develop, deploy, and manage power-efficient IoT devices. It supports various connectivity technologies and protocols, including MQTT and CoAP, and provides REST APIs for cloud-to-cloud connectivity. Key service areas include device management (OTA), device observability, and multi-technology Location Services.

  2. Overview of nRF Cloud capabilities

    nRF Cloud is a cloud platform designed for Nordic devices (Bluetooth, Cellular, Wi-Fi, bare metal, or other RTOS) ranging from powerful SoCs to constrained microcontrollers (MCUs). It provides a centralized system for:

    • Debugging: Automatic crash tracking and remote trace analysis.
    • OTA Updates: Deploying firmware updates to specific device cohorts with staged rollouts and delta releases.
    • Monitoring: Collecting time-series data and device vitals to track fleet health.

    The platform is designed to handle low or intermittent connectivity, allowing data to be rationed in chunks or bridged through a companion device (e.g., a mobile phone).

  3. Overview of the new nRF Cloud FOTA experience

    nRF Cloud now uses Memfault's OTA engine for firmware over-the-air (FOTA) updates. For application (app) updates, no firmware or SDK changes are required on the device side; existing device protocols (CoAP, REST, MQTT) and authentication remain the same.

    New capabilities include:

    • Staged rollouts: Release to a fraction of a cohort first before expanding.
    • Approval workflows: Gate Release activation behind explicit approval.
    • Audit logs: Track changes to projects, releases, and deployments.
    • SBOM management: Manage Software Bill of Materials per version for compliance.
    • Fleet-wide tracking: Monitor update adoption via Software Versions Charts and version matrices.

  4. Overview of nRF Cloud CVE Scanning

    CVE scanning allows developers to continuously check software components in firmware against known security vulnerabilities. It works by matching components from an uploaded Software Bill of Materials (SBOM) against public vulnerability data from the National Vulnerability Database (NVD), GitHub Security Advisories (GHSA), and the CISA Known Exploited Vulnerabilities (KEV) catalog. Scans run automatically upon SBOM upload and whenever vulnerability data is updated.

  5. Overview of MCU Metrics and Prerequisites

    The Memfault SDK includes a metrics component to track system health vitals (e.g., RTOS task time, heap/stack high water marks, battery state of charge, and connectivity stats).

    Prerequisites:

    1. Complete the minimal integration of the Memfault SDK.
    2. Symbol File: You must upload the <project_name>.elf (or .axf/.out) file to Memfault via Software → Symbol Files before sending metrics data, as it is required for processing.

    Rate Limiting: To avoid ingestion rate-limiting, avoid sending metrics data more than once per hour per device.

  6. Overview of Memfault Upload endpoints

    The Upload endpoints allow Devices or external APIs to upload files to the Memfault service. The process typically involves a two-step flow: first preparing the upload to files.memfault.com (using either a Project Key or Basic Auth), and then committing the specific file type (Coredump, Bugreport, MAR File, or Custom Data Recording) for processing within a Project.

  7. Overview of nRF Cloud Location Services types

    nRF Cloud Location Services provide various methods to obtain location data based on accuracy, power constraints, and hardware availability. The uncertainty value returned in responses represents the horizontal positioning error (radius with ~68% probability).

    ServiceTypical AccuracyPower SavingsGNSS RequiredBest Use Case
    Assisted GNSS (A-GNSS)< 10 mLowYesHighest accuracy, clear sky view.
    Predicted GNSS (P-GNSS)< 10 mMediumYesIntermittent connectivity, GNSS-grade accuracy.
    Single-cell (SCELL)< 1000 mHighNoPower-constrained or indoor, coarse location.
    Multicell (MCELL)< 700 mHighNoMultiple cells in range, tighter cellular accuracy.
    Wi-Fi< 100 mHighNoIndoor use with Wi-Fi access points.
    Groundfix< 700 mHighNoBest available fix from combined Cell and Wi-Fi.

  8. Overview of Memfault SDK Self Test

    The Self Test is an optional SDK component used to verify that the Memfault SDK integration is functioning as expected. It includes tests for Device Info, Component Boot, Coredump Region, Data Export, Reboot Reason, Time, Coredump Storage Capacity, and Coredump Storage Operation.

  9. Overview of Memfault Firmware SDK

    Memfault is a device monitoring solution for embedded devices. It collects diagnostics such as coredumps, logs, reboot reasons, and metrics, which are then sent to the Memfault cloud for analysis and issue grouping. The SDK is highly configurable and supports bare-metal or RTOS environments across various data paths (Bluetooth, LTE, Wi-Fi, LoRa, Zigbee, etc.).

    Resource Requirements:

    • Typical compiled SDK size: 5KB flash
    • Typical RAM usage: 1.5KB

  10. Overview of nRF Cloud Over-the-Air (OTA) Updates

    nRF Cloud provides a secure and scalable OTA update system for MCU, Android, and Linux devices. The system works by having devices poll a Device OTA Endpoint; nRF Cloud then determines the appropriate payload to return based on inputs such as the device's current Software Version. To ensure security, it is strongly recommended to sign OTA artifacts to prevent the installation of counterfeit or invalid firmware. Support for signing varies by platform: AOSP builds are signed during image creation, Linux SWUpdate images should be signed, and MCU platforms using MCUBoot have built-in image verification.

  11. Overview of nRF Cloud alert types

    nRF Cloud provides four primary alert types to notify users when monitored devices meet specific conditions:

    Alert typeTriggerPolling frequency
    Fleet threshold alertFleet-wide aggregation of a timeseries metric meets a conditionHourly
    Device threshold alertMetric value in a received report meets a conditionEvaluated immediately upon report arrival
    Device offline alertDevice stops checking in with nRF CloudEvery five minutes
    Reboot alertDevice or fleet reboot count meets a conditionEvaluated when reboot data arrives

  12. Overview of nRF Cloud device onboarding methods

    Onboarding is the process of connecting a device to nRF Cloud and registering its device certificate, enabling the use of nRF Cloud MQTT APIs (via the IoT broker) or CoAP. Depending on the hardware and security requirements, different methods are available:

    • Provisioning Service (Claim): Uses the device's secure identity to claim ownership for remote provisioning and lifecycle security asset management.
    • Provisioning Service (Claim and Auto-onboard): Claims ownership and automatically onboards the device to Device Management and Location Services.
    • Preconnect Onboarding (Certificate-based): Onboards the device using a self-signed device certificate.
    • Preconnect Onboarding (Public Key-based): Uses trusted firmware to create keys and onboards the device using its public key.
    • Pre-provisioned DK/Thingy: Development-only method where Nordic DK and Thingy devices are pre-provisioned; the user associates them with a team using the IMEI and pin.