Skip to main content

Reboot Reason Tracking

There are many reasons a device may reboot in the field — whether it be due to a crash, a brown out, or a firmware update.

Within the Memfault UI, reboot events are displayed for each device as well as summarized in the main "Overview" dashboard:

In this guide we will walk through how to use the reboot tracking module from the memfault-firmware-sdk to collect this data.


This guide assumes you have already completed the minimal integration of the Memfault SDK. If you have not, check out the appropriate guide in the table below.

MCU ArchitectureGetting Started Guide
ARM Cortex-MARM Cortex-M Integration Guide
nRF Connect SDKnRF Connect SDK Integration Guide
ESP32 ESP-IDFESP32 ESP-IDF Integration Guide
ESP8266ESP8266 RTOS Integration Guide
Dialog DA1469xDA1469x Integration Guide


The reboot tracking module utilizes a noinit region of RAM to track information about reboots across resets.

  • If a MCU fault takes place, the fault reason will automatically be tracked
  • If the device reboots and the reason is not known, the device reset reason will be derived from the MCU reset reason register that was part of your initial port.
Rate Limiting

Ingestion of Reboots Events may be rate-limited.

Tracking custom reset reasons#

Sometimes resets take place due to software initiated behavior (i.e firmware update, button resets, etc). Recording when and where these types of resets take place can easily be achieved with Memfault's memfault_reboot_tracking_mark_reset_imminent API. For example, consider we want to track anytime a reset occurs due to an over-the-air update:

#include "memfault/components.h"
// [...]
void ota_finalize_and_reboot(void) {
// The pc & lr which result in the reboot can always be *optionally* recorded
void *pc;
void *lr;
sMfltRebootTrackingRegInfo reg_info = {
.pc = (uint32_t)pc,
.lr = (uint32_t)lr,
// Note: "reg_info" may be NULL if no register information collection is desired
// [... logic to reboot the MCU ...]