Sponsored by Nordic Semiconductor
If you’ve ever tried debugging a Bluetooth Low Energy device that’s failing in production—deployed to a customer, thousands of miles away, with no debugger attached—you know exactly how frustrating the process becomes. The customer reports “it stopped working,” but you have no crash logs, no stack traces, and no way to see what actually happened at the moment of failure. You’re left trying to reproduce an issue that might only occur with specific phone models, after hours of use, under conditions you can’t replicate in your lab.
For embedded developers building Bluetooth Low Energy products, this scenario is all too common. Once your devices ship, visibility often diminishes. Building the infrastructure to maintain that visibility—crash capture, fleet monitoring, safe OTA updates—means months of development work that takes you away from your core product features. And that’s assuming you have the expertise to build device management and observability systems that work reliably at scale.
Nordic Semiconductor customers building with the nRF52, nRF53, and nRF54 series have had access to various OTA tools and libraries, but many times you’d piece together different components, build much of the cloud infrastructure yourself, and still end up with gaps in observability.
That’s where the recent acquisition changes things. Nordic Semiconductor acquired Memfault and now offers it as “nRF Cloud powered by Memfault.” This brings enterprise-grade device management and observability directly into the Nordic ecosystem with seamless nRF Connect SDK support and ready-to-use mobile apps (and reference code) for iOS and Android.
In this post, we’ll cover:
- What Memfault brings to Nordic’s Bluetooth Low Energy ecosystem
- How the integration works architecturally with the nRF Connect SDK
- The setup essentials and configuration requirements
- Real-world impact, resource footprint, and when this solution makes sense
🎥 See It In Action
Want to see how easy it is to integrate nRF Cloud into your Bluetooth LE application?
What Memfault Brings to nRF Cloud
The nRF Cloud Memfault integration provides Device Management (progressive OTA rollouts) and Embedded Observability (crash dumps, fleet monitoring, analytics). Both work seamlessly with nRF52/nRF53/nRF54 series chipsets and the nRF Connect Device Manager mobile app.
You get 10 devices completely free, with full-feature access for non-production use. Beyond that, pay-as-you-go pricing starts from $0.10 per device per month with usage-based charges for observability operations. For up-to-date, detailed pricing, refer to the nRF Cloud Pricing Page.
1. Embedded Device Observability
Every crash—hard fault, assertion failure, watchdog reset—triggers automatic coredump capture stored in flash/NVM. This includes everything you’d see with a debugger: program counter, register states, stack trace, and variable values. Next, a Bluetooth Low Energy connection uploads the coredump in small chunks. The platform translates all this information using your uploaded ELF file and presents a fully analyzed crash report.
Instead of “the device stopped working,” you get: … a crash at line 247 in bluetooth_handler.c in the bt_conn_get_info() function with null pointer dereference in register R0, complete call chain, variable states, and correlation with similar crashes across your fleet.
Fleet health monitoring provides continuous visibility. Memfault automatically collects connectivity statistics, battery trends, stability metrics (reboot counts, crash frequency), and memory patterns—viewable per device or aggregated across your fleet, with filtering by firmware version or hardware revision.
Product analytics tracks feature usage, measures how features impact performance (battery, memory, connection stability), and identifies which features deliver the most value.
2. Device and Fleet Management
Rather than deploying to all devices simultaneously, you create customized device groups controlling which devices receive updates and when. Deploy to a 10-device QA group and monitor for 24 hours. Then, expand to 10% of beta, monitor, and expand to 50%. Finally, deploy to full production over the next week.
The dashboard shows exactly how many devices received the update, successfully applied it, and any failures. If crash rates spike, you can abort the rollout with a single button click—devices without updates will remain on their current firmware.
The OTA integrates with the nRF Connect Device Manager mobile app. When users connect, it automatically checks nRF Cloud for updates. If available, the app downloads firmware and transfers it over Bluetooth Low Energy using the SMP protocol. The device receives chunks, writes to flash/NVM, verifies the signature (MCUboot), and reboots.
The mobile app libraries are open source on GitHub (iOS and Android), so you can integrate this functionality into your own customer-facing application.
How the Integration Works
The integration follows a three-tier model: your nRF device, the Bluetooth Low Energy connectivity layer, and the nRF Cloud platform.
At the device level, you run application code on the nRF Connect SDK. You add the Memfault SDK—a lightweight library that adds around 5KB of flash/NVM usage and requires 1.5KB of RAM. This SDK handles crash capture, metric collection, and data packetization.
The connectivity layer uses three key Bluetooth Low Energy GATT services:
1. The Memfault Diagnostic Service (MDS) exposes observability data.
2. The SMP (Simple Management Protocol) service from MCUmgr handles firmware updates.
3. The Device Information Service (DIS) exposes the metadata and information about the hardware, software, etc.
The nRF Connect Device Manager app reads from MDS to upload diagnostic data, uses DIS to identify the device, and uses SMP to transfer new firmware images for OTA device firmware updates (DFU) on the devices of interest.
The cloud side processes everything. When crash dumps arrive, the platform symbolicates them (matching memory addresses to function names using uploaded ELF files), analyzes patterns across your fleet, and presents results in a dashboard. For OTA updates, it hosts firmware images, manages rollout rules, and tracks adoption.
Device-Side Components
The firmware requires several components:
- MCUboot bootloader: verifies signatures, supports A/B partition swapping.
- MCUmgr: implements SMP service for firmware transfers and OTA DFU.
- Memfault SDK: handles crash capture, heartbeat metrics, and event logging.
- Memfault Diagnostic Service (MDS): exposes observability data.
- Device Information Service (DIS): provides device metadata for correlation with firmware builds.
From Crash to Root Cause Analysis
Your Bluetooth Low Energy fitness tracker crashes from a null pointer dereference during a GATT write response. Memfault’s exception handler captures complete processor state—registers, stack contents, configured data regions—writes this compressed snapshot to flash/NVM, and the device reboots.
Hours later, the user opens your app. It connects via Bluetooth Low Energy, and the device provides the crash dump in small chunks. The app uploads it to nRF Cloud, which symbolicates the crash—converting raw addresses like 0x00012A4C into bt_gatt_write_handler() at line 342 in gatt_operations.c.
You see the crash report with full stack trace, register dump, and analysis showing 47 occurrences across 12 devices in the past week—all firmware 1.3.2, same function. You immediately identify and fix the root cause without lab reproduction.
Setting Up nRF Cloud with Your nRF Project
🎥 Companion Video Walkthrough
I’ve created a hands-on video demonstrating the complete setup process using the peripheral_mds example
from nRF Connect SDK. The video shows exactly how straightforward integration is—from enabling configuration flags to testing crash capture and OTA updates
on real hardware.
Prefer visual learning? Watch the demo first → then return here for the technical details.
You’ll primarily configure existing components rather than write extensive code. The setup involves enabling components already in the nRF Connect SDK, adding the Memfault SDK to your build, and configuring a few services.
Prerequisites: nRF Connect SDK version 3.1.0 or later (earlier versions will likely require additional Kconfig configuration for OTA support), an nRF52/nRF53/nRF54 series development kit, an nRF Cloud account (starting with 10 free non-production devices), and the nRF Connect Device Manager app on iOS or Android.
Step #1: Configuring Your Firmware
For testing purposes, I recommend starting with the peripheral_lbs (LED Button Service) or peripheral_mds samples from the nRF Connect SDK, as they include many necessary configurations and provide good foundations for a quick test.
The integration requires enabling several components in your project configuration (prj.conf). Here’s what each does and why you need it:
Core Components:
# Essential Memfault configuration
CONFIG_MEMFAULT=y
CONFIG_BT_MDS=y
# SMP is a must
CONFIG_BT_SMP=y
# Enable OTA updates
CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y
# Memfault firmware identification
CONFIG_MEMFAULT_NCS_FW_TYPE="main"
CONFIG_MEMFAULT_NCS_FW_VERSION_STATIC=y
CONFIG_MEMFAULT_NCS_DEVICE_ID="mfltqs1"
# Testing shell (optional)
CONFIG_SHELL=y
CONFIG_MCUBOOT_SHELL=yDevice Information Service Configuration:
The DIS provides critical metadata that both Memfault and OTA rely on for device identification and firmware correlation:
CONFIG_BT_DIS=y
CONFIG_BT_DIS_SERIAL_NUMBER=y
CONFIG_BT_DIS_SERIAL_NUMBER_STR="mfltqs1"
CONFIG_BT_DIS_HW_REV=y
CONFIG_BT_DIS_HW_REV_STR="nrf54l15dk" # Adjust for your board
CONFIG_BT_DIS_SW_REV=y
CONFIG_BT_DIS_SW_REV_STR="main"
CONFIG_BT_DIS_FW_REV=yFirmware Version Configuration:
You will need to define three matching configurations for the firmware image version:
# MCUBoot image header version should match DIS and Memfault version
CONFIG_BT_DIS_FW_REV_STR="0.0.1"
CONFIG_MEMFAULT_NCS_FW_VERSION="0.0.1"
CONFIG_MCUBOOT_IMGTOOL_SIGN_VERSION="0.0.1"Critical Sysbuild Configuration:
When using sysbuild (required for bootloader integration), create a separate sysbuild.conf file alongside prj.conf:
SB_CONFIG_BOOTLOADER_MCUBOOT=yWithout this, your project compiles, but MCUboot won’t be included, so you’ll have no OTA capability. If using VS Code with the nRF Connect extension, check “Use sysbuild” in build configuration settings (this is also enabled by default in newer versions of the nRF Connect SDK for VS Code Extension).
2. Symbol File Upload and Project Keys
For crash symbolication to work, nRF Cloud needs the ELF symbol file from your build. This file contains mappings between memory addresses and function names, source line numbers, and variable names.
Build and Upload Workflow:
- Build your firmware ( via
west build -b <board name>, or the VS Code Extension) - Find the ELF file (e.g.,
build/peripheral_mds/zephyr/zephyr.elf) - Upload to nRF Cloud via the web interface.
The upload associates your symbol file with a GNU build ID—a unique hash embedded in both the firmware binary and ELF file. When devices send crash dumps, nRF Cloud uses this build ID to automatically select the correct symbol file, even with multiple firmware versions deployed simultaneously. This means you never have to manually specify which symbol file corresponds to which crash.
Project Key Configuration:
Get your project key from the nRF Cloud dashboard and add it to prj.conf:
# ⚠️ Make sure to update this line with YOUR Project Key from https://mflt.io/project-key!
CONFIG_MEMFAULT_NCS_PROJECT_KEY="YOUR_PROJECT_KEY"This key routes diagnostic data to the correct dashboard and organization.
3. Verifying the Integration
After flashing your configured firmware to the device, verify the integration works:
1. Bluetooth Low Energy Connection:
- Open the nRF Connect Device Manager app
- Scan for your device
- Select your device
- Send a “Hello!” message to initiate a connection
- Allow the pairing and bonding of the device to your smartphone
- Confirm you see “Observability: Streaming” and “OTA: Supported” status indicators
2. Test Crash Capture:
If your firmware includes Memfault shell commands (available if you enabled the shell in prj.conf), trigger a test crash:
uart:~$ mflt test assertThe device crashes, captures the coredump, and reboots. Reconnect with the app to upload the crash dump.
Within minutes, you’ll see the fully symbolicated crash report in your nRF Cloud dashboard showing the exact line in the Memfault test code where the assertion occurred.
3. Test OTA Update:
To test OTA updates, perform the following steps:
- Increment/increase your firmware version number for the following KConfig definitions:
CONFIG_BT_DIS_FW_REV_STRCONFIG_MEMFAULT_NCS_FW_VERSIONCONFIG_MCUBOOT_IMGTOOL_SIGN_VERSION
- Rebuild and upload both the new firmware binary and symbol file to nRF Cloud
- Create a new release in the dashboard, then activate it for your device.
- Connect with the mobile app—it will detect the update, download it, transfer it over Bluetooth Low Energy, and the device will reboot into the new firmware.
nRF Cloud Hands-On Video Demo
Practical Considerations
Resource Footprint and Performance Impact
The Memfault SDK is designed specifically for resource-constrained embedded devices, so the footprint is quite reasonable for most Bluetooth Low Energy applications.
- Flash/NVM: Memfault SDK typically adds around 5 KB to your firmware image (exact size depends on enabled features and compiler optimization). MCUboot bootloader adds additional flash/NVM overhead (typically 16-32kB depending on enabled security features and target hardware), but this is necessary for secure OTA updates regardless of using Memfault.
- RAM usage is approximately 1.5 KB for the default circular buffer configuration. This buffer stores heartbeat metrics and event data until cloud upload. You can tune buffer size based on device constraints—smaller buffers lose older data if devices don’t connect frequently, while larger buffers provide more historical data at RAM cost.
- Performance impact during normal operation is minimal. The SDK operates primarily in background contexts (collecting periodic metrics, logging events). The only real-time overhead comes from exception handlers executing during crashes—but at that point, the device is crashing anyway, so a small additional capture time doesn’t affect user experience.
During Bluetooth Low Energy transmission, you may notice negligible bandwidth and power consumption impacts, but the SDK transfers data in small chunks that fit within typical Bluetooth Low Energy MTU sizes, avoiding fragmentation or special handling.
Pricing and Cost Considerations
I recommend starting with the free tier (10 devices with full feature access for non-production use) during development and testing. Beyond that, the Pro tier uses pay-as-you-go pricing starting at $0.10 per device per month, with OTA updates included and usage-based charges for observability operations. Enterprise options with fixed annual pricing are also available for larger deployments.
On all pricing plans, the cost per device discounts significantly as you grow, with total costs easily justified by reduced support costs and faster fix deployments.
When Using nRF Cloud Makes Sense
This integration is particularly well-suited for:
- Consumer devices with regular firmware updates (fitness trackers, smart home devices, health monitors) that benefit from progressive rollouts and crash analysis
- Products requiring regulatory compliance (EU Cyber Resilience Act, US Cyber Trust Mark), needing secure remote updates
- Complex applications with sophisticated behavior (multiple sensors, state machines, varied phone compatibility), where field debugging without lab reproduction is critical
- Battery-powered devices where product analytics identify unexpected power consumption patterns based on real-world usage
- Production deployments beyond 10-50 devices up to millions, where automated rollout management, fleet-wide metrics, and centralized crash analysis become essential
Integration effort takes minutes, not days, not weeks—primarily configuration-based, with a comprehensive quick start guide and active DevZone community support.
Frequently Asked Questions
Q: Does nRF Cloud work with Nordic’s nRF52, nRF53, and nRF54 series?
Yes. nRF Cloud, powered by Memfault, offers integration support for all nRF52, nRF53, and nRF54 series chipsets. The setup has been tested with nRF Connect SDK version 3.1.0. Earlier SDK versions may work with additional Kconfig configuration adjustments, but v3.1.0 or later is recommended for the most straightforward integration.
Q: How much flash and RAM overhead does Memfault add?
The Memfault SDK adds around 5 KB of flash/NVM usage and approximately 1.5 KB of RAM. The MCUboot bootloader adds 16-32 KB to flash/NVM usage depending on enabled security features and target hardware, but is required for OTA regardless of Memfault.
Q: Can I use nRF Cloud in my own mobile app instead of nRF Connect Device Manager?
Yes. The nRF Connect Device Manager libraries are open source on GitHub for both iOS and Android. You can integrate the same OTA and observability functionality into your customer-facing application.
Q: How much does nRF Cloud powered by Memfault cost?
The free tier includes 10 devices with full feature access for non-production use. The Pro tier starts at $0.10 per device per month with pay-as-you-go pricing, OTA updates included, and usage-based charges for observability operations. Enterprise plans with fixed annual pricing are available for production deployments. Visit the nRF Cloud Pricing Page for current details.
Q: What’s the difference between MDS and DIS in Bluetooth Low Energy?
MDS (Memfault Diagnostic Service) is a Memfault-specific GATT service that handles observability data transfer (crash dumps, metrics, logs). DIS (Device Information Service) is a standard Bluetooth service providing static device metadata (firmware version, hardware revision, serial number). Both are required for the integration.
Q: How do I trigger a test crash to verify nRF Cloud is working?
Use the Memfault shell command: mflt test assert. The device will crash, capture the coredump, and reboot. Reconnect with the mobile app to upload the crash dump to nRF Cloud.
Q: Does nRF Cloud help with regulatory compliance like the EU Cyber Resilience Act or the US Cyber Trust Mark program?
Yes. nRF Cloud provides infrastructure to satisfy secure remote update capabilities and vulnerability management requirements for both the EU Cyber Resilience Act and the US Cyber Trust Mark program with minimal custom development:
Summary
Nordic Semiconductor’s integration of Memfault into nRF Cloud brings enterprise-grade device management and observability to Bluetooth Low Energy developers. The platform addresses one of embedded development’s most persistent challenges: gaining visibility into production device performance and safely deploying firmware updates at scale.
What is offered:
- Automatic crash capture with full symbolication—see exactly where crashes occur without lab reproduction
- Fleet-wide health monitoring and product analytics across all your devices
- Progressive OTA rollouts with abort capabilities—deploy safely with visibility at every stage
- Around 5 KB flash/NVM overhead with seamless nRF Connect SDK integration
- 10 free devices for non-production use, then pay-as-you-go starting at $0.10 per device per month
With regulatory requirements (EU Cyber Resilience Act enforcement, US Cyber Trust Mark) and customer expectations for devices that improve over time, robust device management and observability are becoming more essential. The nRF Cloud integration provides a turnkey solution leveraging Nordic’s existing development tools.
Resources:
- nRF Cloud Sign-up – Start with 10 free devices and full feature access
- Memfault Quick Start Guide – Step-by-step integration instructions for nRF Connect SDK
- nRF Connect Device Manager on GitHub (iOS)
- nRF Connect Device Manager on GitHub (Android)
- Nordic DevZone – Community support, discussions, and technical resources
