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 Architecture||Getting Started Guide|
|ARM Cortex-M||ARM Cortex-M Integration Guide|
|nRF Connect SDK||nRF Connect SDK Integration Guide|
|ESP32 ESP-IDF||ESP32 ESP-IDF Integration Guide|
|ESP8266||ESP8266 RTOS Integration Guide|
|Dialog DA1469x||DA1469x 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.
Ingestion of Reboots Events may be rate-limited.
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: