Skip to main content

Quickstart Nordic nRF52/53/54

info

The following assumes you already have a Memfault Account. If you don't yet have an account, reach out to us!

tip

You can follow an interactive version of this guide in the Memfault dashboard.

This quickstart guide shows how to integrate and verify the Memfault SDK with the Nordic nRF52, nRF53, and nRF54 series SOCs, using the Nordic nRF-Connect SDK (NCS).

Set up the SDK​

Enabling Memfault requires adding some Kconfig settings to the application.

Add the following code snippet to the project's prj.conf file:

prj.conf
# Enable Memfault! 🎉
CONFIG_MEMFAULT=y
CONFIG_MEMFAULT_NCS_PROJECT_KEY="wmDVO14tfdVSNwfgTIA9kYFNAWuuvjvJ"

# Enable the Memfault Diagnostic Service
CONFIG_BT_MDS=y

# Enable Bluetooth Memfault Metrics
# Note: requires BT_SMP (bonding) enabled
CONFIG_MEMFAULT_NCS_BT_METRICS=y

# Configure the Memfault software_version and device_serial defaults.
# Note: in production, you will want to use memfault_ncs_device_id_set()
# to apply the real device serial on system initialization (i.e. retrieved
# from NVS, for the serial written during manufacturing)
CONFIG_MEMFAULT_NCS_FW_TYPE="app"
CONFIG_MEMFAULT_NCS_DEVICE_ID_STATIC=y
CONFIG_MEMFAULT_NCS_DEVICE_ID="ncs-ble-testdevice"

# Enable the Zephyr shell for testing the integration
CONFIG_SHELL=y

Enable the Memfault Diagnostic Service (MDS) in the advertising data, and configure the MDS callback data structure in the project's main.c file:

main.c
// Add the MDS header
#include <bluetooth/services/mds.h>

// Add the MDS UUID in the advertising data, so the MDS app can automatically
// find the device. This is optional.
static const struct bt_data ad[] = {
	BT_DATA_BYTES(BT_DATA_FLAGS, (BT_LE_AD_GENERAL | BT_LE_AD_NO_BREDR)),
	BT_DATA_BYTES(BT_DATA_UUID128_ALL, BT_UUID_MDS_VAL),
};

// If this error is encountered:
// > E: Too big advertising data
// > Advertising failed to start (err -22)
// Move the DEVICE_NAME or other fields to the scan response data
static const struct bt_data sd[] = {
	BT_DATA(BT_DATA_NAME_COMPLETE, DEVICE_NAME, DEVICE_NAME_LEN),
	BT_DATA_BYTES(BT_DATA_UUID128_ALL, BT_UUID_LBS_VAL),
};

// Register the MDS callback before starting advertisement.
int main(void)
{
	...
	static const struct bt_mds_cb mds_cb = {
		.access_enable = NULL,
	};
	err = bt_mds_cb_register(&mds_cb);
	if (err) {
		printk("Memfault Diagnostic service callback registration failed (err %d)\n", err);
		return 0;
	}
	...

Perform a full rebuild of the project. This example command is building the Peripheral LBS example in the nRF-Connect SDK for an nRF5340 DK.

west build --pristine=always --board nrf5340dk_nrf5340_cpuapp nrf/samples/bluetooth/peripheral_lbs

Flash the board:

west flash --erase

Note: --erase will clear any pairing information stored in non-volatile memory. Use this option to clear Bluetooth settings if pairing fails.

Confirm that advertising starts successfully. For the example project used here, several shell prints indicate success:

Bluetooth initialized
Advertising successfully started

Connect a serial console and confirm the Memfault shell command group is available by running mflt help:

uart:~$ mflt help
mflt - Memfault Test Commands
Subcommands:
  clear_core          : clear coredump collected
  export              : dump chunks collected by Memfault SDK using
                      https://mflt.io/chunk-data-export
  get_core            : check if coredump is stored and present
  get_device_info     : display device information
  get_latest_release  : checks to see if new ota payload is available
  coredump_size       : print coredump computed size and storage capacity
  heartbeat_dump      : dump current Memfault metrics heartbeat state
  post_chunks         : Post Memfault data to cloud
  test                : commands to verify memfault data collection
                      (https://mflt.io/mcu-test-commands)

If you encounter configuration or other build errors, please contact us!

Hello, Memfault!​

To start sending data to Memfault:

  1. Upload the build/zephyr/zephyr.elf file to Memfault by navigating to Software → Symbol Files, and clicking the "Upload Symbol File" button.

    Screenshot of the Upload Symbol File button

    tip

    If there are code changes, make sure to always upload the symbol file before sending data to Memfault.

  2. Install the nRF Memfault for Android or the nRF Memfault for iOS application on your mobile test device. The Memfault MDS Web Bluetooth app is also available for forwarding data through a web browser client. However, we suggest using the mobile app, and the following steps will guide you through using it.

  3. Open the mobile app:

    Screenshot of the NRF Memfault application's initial screen

  4. Tap Start:

    Screenshot of the NRF Memfault application's scanner screen

  5. Select the device:

    Screenshot of the NRF Memfault application's device selection screen

    Note: the mobile and web apps search for MDS in the advertising packet by default. Adjust the scan filter in the app for all devices if you did not add MDS to the advertising packet.

  6. Tap Connect, and complete the BLE pairing process (if your device uses secure pairing). Chunks should be uploaded:

    Screenshot of the NRF Memfault application's status screen

    Note: if pairing fails, clear the pairing information on both devices. The pairing information on the nRF52/53 can be cleared by flashing the device via west flash --erase.

  7. Navigate to the Integration Hub → Processing Log and confirm that the data was received by Memfault. It should look something like this:

    Screenshot of the Processing Log showing a received reboot event

Investigate a Crash​

In order to see crash data within Memfault, first initiate a crash from your device.

  1. Trigger a crash by running mflt test assert. The device should crash and restart:

    uart:~$ mflt test assert
    E: ***** USAGE FAULT *****
    E:   Attempt to execute undefined instruction
    E: r0/a1:  0x00008001  r1/a2:  0x2000bb98  r2/a3:  0x2001255c
    E: r3/a4:  0x000292f3 r12/ip:  0x00032373 r14/lr:  0x0001bc09
    E:  xpsr:  0x21000000
    E: r4/v1:  0x00000000  r5/v2:  0x00000001  r6/v3:  0x00032373
    E: r7/v4:  0x2000bba8  r8/v5:  0x2000bc28  r9/v6:  0x0002c108
    E: r10/v7: 0x00000002  r11/v8: 0x00000000    psp:  0x2000bb78
    E: EXC_RETURN: 0xffffffbc
    E: Faulting instruction address (r15/pc): 0x0001bc08
    *** Booting nRF Connect SDK d96769faceca ***
    I: Reset Reason, RESETREAS=0x8
    I: Reset Causes:
    I:  Software
    I: GNU Build ID: 139a1ac3d293a5e2e8220d4aaf2fafa9ad9633cf
    Starting Bluetooth Peripheral LBS example

  2. Connect the MDS mobile app and wait for the data to upload.

  3. Navigate back to the Processing Log, and confirm that a coredump was received. It can take up to 5 minutes for the coredump to appear:

    Screenshot of the Processing Log showing a received coredump

  4. In the Sidebar, navigate to the Issues page and see the coredump once it processes:

    Screenshot of the Issue List

  5. Click on its title to go through to the Trace view, and see details of the coredump:

    Screenshot of the Issue Detail view

Monitor the Fleet​

Heartbeat Metrics are automatically collected by the Memfault SDK on an hourly interval. To verify metrics are working, trigger a Heartbeat and upload the data:

  1. Run the mflt test heartbeat shell command, and wait for the MDS mobile app to upload the data (this can be prompted by disconnecting/reconnecting if it doesn't automatically happen after a few seconds):

    uart:~$ mflt test heartbeat
    Triggering Heartbeat

  2. Navigate to the Processing Log, and confirm that the heartbeat appears. This can also take up to 5 minutes. Clicking on Inspect Payload (the icon) on the Processing Log entry should show decoded data:

    Screenshot of the Processing Log showing a received heartbeat report

  3. Click on Dashboards → Metrics, and inspect the aggregate metric charts. You may need to refresh the charts using the icon in the bottom left corner of each chart:

    Screenshot of a dashboard card task stack low water mark graph

    tip

    Make sure the matching Symbol File was uploaded before uploading the Heartbeat data. The Processing Log will show an error if the symbol was missing. To fix it, upload the Symbol File, and re-run the steps above.

Examine a Device​

Make sure that all the data you've uploaded so far is appearing on your Device's details page.

Note: this step should be run after a Heartbeat is uploaded in "Monitor the Fleet".

  1. Navigate to the Fleet → Devices page, and select the device reporting in to view its Device Timeline.

  2. Click on the sample in the Timeline to inspect the uploaded Heartbeat record. It should look something like this:

    Screenshot of the device timeline

  3. Click on the Traces tab to see the Trace you uploaded earlier:

    Screenshot of traces tab

  4. Click on the Reboots tab to see the Reboot you uploaded earlier:

    Screenshot of reboots tab

Last updated on
This page is human-authored. If you see any errors, outdated information, or any other suggestions for improving the contents, please contact us!