In this topic, we will walk through how to add the Memfault SDK to an nRF Connect SDK Bluetooth LE application. We will cover the key configuration options, how the Memfault Diagnostic Service fits into your application, and how diagnostic data is buffered and transmitted over the existing Bluetooth LE connection.
This topic covers the integration at a conceptual level. In the exercises that follow, we will go through the full setup step by step on the nRF54L15 DK.
Prerequisites
Before integrating the Memfault SDK, you need the following:
An nRF Connect SDK project with Bluetooth LE peripheral functionality. The exercises in this lesson build on the samples from Lesson 4, so any working peripheral application will serve as a starting point.
An nRF Cloud account with a project key. The project key identifies your project in the cloud and is compiled into your firmware. You will set this up in Exercise 1.
A smartphone with the nRF Connect Device Manager app installed. This app acts as the Bluetooth LE central that relays diagnostic data from the peripheral to nRF Cloud over HTTPS.
Enabling the Memfault SDK
The Memfault SDK is included in the nRF Connect SDK and can be enabled with a single Kconfig option in your prj.conf:
CopyCONFIG_MEMFAULT=y
Kconfig This enables the core Memfault subsystem, which includes metric collection, reboot tracking, and coredump capture. The nRF Connect SDK integration automatically enables the Memfault Diagnostic Service (MDS) when Bluetooth is active, so no additional configuration is needed to expose diagnostic data over Bluetooth LE.
There are several additional Kconfig options that are relevant for a Bluetooth LE peripheral application:
CopyCONFIG_MEMFAULT_NCS_PROJECT_KEY="your-project-key-here"
Kconfig This sets the project key that identifies your project in nRF Cloud. The project key is embedded in the firmware at compile time.
CopyCONFIG_MEMFAULT_NCS_BT_METRICS=y
Kconfig This enables the automatic collection of Bluetooth LE connection metrics from the nRF Connect SDK integration layer.
CopyCONFIG_MEMFAULT_METRICS_BLUETOOTH=y
Kconfig This enables the Memfault SDK’s built-in Bluetooth metric collection from the Zephyr Bluetooth stack. Together with CONFIG_MEMFAULT_NCS_BT_METRICS, this provides the full set of Bluetooth LE metrics covered in Topic 2: connection interval, latency, timeout, PHY, data length, RSSI, peer information, and disconnection counts. With both options enabled, the SDK registers its own callbacks and populates the metrics automatically, requiring no additional application code.
How the Memfault Diagnostic Service works
The Memfault Diagnostic Service (MDS) is a custom GATT service that the SDK registers when Bluetooth is enabled. It provides a mechanism for a connected central to read buffered diagnostic data from the peripheral.
The SDK collects data continuously during normal operation. Metrics are accumulated over a configurable heartbeat interval (by default, one hour). At the end of each heartbeat interval, the current metric values are serialized into a compact binary format and stored in a local buffer. Reboot events are captured automatically on each boot by inspecting the SoC reset reason register. Coredumps are captured when the system encounters a fault (such as a hard fault or an application assert) and stored to a dedicated region of flash or RAM, depending on your configuration.
When a central connects and subscribes to the MDS characteristics, the peripheral begins transmitting its buffered data in chunks. The chunk size is determined by the negotiated MTU, which ties back to the throughput optimization from Lesson 4. A larger MTU means fewer chunks and less radio time spent transmitting diagnostic data. The SDK handles the chunking and reassembly, so the application does not need to manage this.
The central collects the chunks and forwards them to nRF Cloud over HTTPS. Once the data reaches nRF Cloud, it is processed and made available in the dashboard. For testing purposes, the nRF Connect Device Manager app is available on iOS and Android for data forwarding on the central. In production, users can leverage the Memfault iOS and Android libraries to collect and forward data to nRF Cloud in their existing mobile or gateway applications.
Impact on power consumption
The Memfault SDK is designed for low-power devices and has negligible impact on CPU and power consumption. Data transmission only occurs when a central is already connected and subscribes to the MDS service. The diagnostic chunks share the existing Bluetooth LE connection, so there is no additional advertising or connection establishment cost. If no central connects, the data stays buffered on the device and consumes no radio power.
The main power cost is the additional radio time to transmit the diagnostic chunks during a connection. This depends on how much data has accumulated and the negotiated connection parameters. For a typical heartbeat with Bluetooth LE metrics (a few hundred bytes), the transmission adds a small number of connection events worth of radio activity. Over a one-hour heartbeat interval, this is negligible compared to the ongoing connection maintenance.
What happens when there is no connection
In many low-power applications, the peripheral is not continuously connected to a central. The device may advertise and connect only periodically, or the user may only open the companion app occasionally. The Memfault SDK handles this by buffering data locally. Metrics, reboot events, and coredumps are stored on the device until a central connects and retrieves them.
The buffer size is configurable through Kconfig. For devices with limited RAM, you can reduce the buffer size at the cost of potentially dropping older data if the buffer fills before a central connects. For devices with external flash (like the 8 MB flash on the nRF54L15 DK), coredumps can be stored to flash, preserving them across reboots.
Adding custom metrics
While the automatic Bluetooth LE metrics cover connection parameters and stability, you may want to track application-specific data points as well. For example, you might want to track sensor sampling counts, application-level error rates, or the number of times a specific feature is used.
Custom metrics are defined in a header file called memfault_metrics_heartbeat_config.def. Each metric is declared with a macro specifying its name and type:
CopyMEMFAULT_METRICS_KEY_DEFINE(my_sensor_sample_count, kMemfaultMetricType_Unsigned)
MEMFAULT_METRICS_KEY_DEFINE(my_error_count, kMemfaultMetricType_Unsigned)
C In your application code, you update these metrics using the Memfault metrics API:
Copy#include "memfault/metrics/metrics.h"
// Increment a counter
memfault_metrics_heartbeat_add(MEMFAULT_METRICS_KEY(my_sensor_sample_count), 1);
// Set a value
memfault_metrics_heartbeat_set_unsigned(MEMFAULT_METRICS_KEY(my_error_count), error_count);
C These custom metrics are included alongside the automatic Bluetooth LE metrics in each heartbeat and appear in the nRF Cloud dashboard on the same device timeline.
Summary
Integrating the Memfault SDK into an nRF Connect SDK Bluetooth LE application requires minimal configuration. Enabling CONFIG_MEMFAULT=y, CONFIG_MEMFAULT_NCS_BT_METRICS=y, and CONFIG_MEMFAULT_METRICS_BLUETOOTH=y gives you automatic collection of the key Bluetooth LE data points covered in the previous topic, with no additional application code needed for the core metrics. The diagnostic data is transmitted over the existing BLE connection through the Memfault Diagnostic Service, with minimal impact on power consumption.
In the exercises, we will go through this integration step by step on the nRF54L15 DK and verify that data arrives in the nRF Cloud dashboard.
