Skip to content
Memfault Firmware SDK
C C++ Python Makefile Shell
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.
.circleci Memfault Firmware SDK 0.0.8 (Build 42628) Nov 7, 2019
makefiles Memfault Firmware SDK 0.0.8 (Build 42628) Nov 7, 2019
tasks Memfault Firmware SDK 0.0.8 (Build 42628) Nov 7, 2019
.codecov.yml Memfault Firmware SDK 0.0.8 (Build 42628) Nov 7, 2019
VERSION Memfault Firmware SDK 0.0.8 (Build 42628) Nov 7, 2019

CircleCI Coverage

Memfault Firmware SDK

Ship Firmware with Confidence.

Getting Started

The Memfault SDK can be integrated with any ARM Cortex-M based MCU.

If you'd like to see the type of data which can be collected before doing any integration, check out

The easiest way to get started integrating is by using a development board for which the Memfault SDK already has a reference integration. At the moment, examples are available for:

  • WICED SDK / Cypress BCM943364WCD1
  • nRF5 SDK / Nordic nRF52840 (PCA10056)

Coming soon:

  • ESP-IDF / Espressif ESP32
  • Apache Mynewt / Nordic nRF52840 (PCA10056)

If you have one of the supported boards and want to jump right in, look at the "Getting Started" section in platforms/**/

Otherwise, continue reading to get an overview of the Memfault Firmware SDK.


The SDK is designed as a collection of components, so you can include only what is needed for your project. The components folder contains the various components of the SDK.

Each component contains a, source code, header files and "platform" header files.

The platform header files describe the interfaces which the component relies on. For some of the popular platforms, we have already implemented platform dependencies. Also see the platforms folder.

Main components

  • panics – fault handling, coredump and reboot tracking and reboot loop detection API.

Please refer to the in each of these for more details.

Support components

  • core – common code that is used by all other components.
  • demo - common code that is used by demo apps for the various platforms.
  • http – http client API, to post coredumps and events directly to the Memfault service from devices.
  • util – various utilities.


The platforms folder contains support files for some of the popular platforms. The structure of each platform folder varies from platform to platform, following the idiosyncrasies of each.

Each platform folder contains at least:

  • - instructions on how to build and run the demo app, as well as integration notes specific for the given platform.
  • **/platform_reference_impl – implementations of platform functionality that the Memfault SDK depends on for the given platform.
  • **/memfault_demo_app – demo application for the given platform (see Demo applications below).
  • Build system files (specific to the platform) to compile the components as well as the demo applications for the platform.

Demo applications

The SDK includes a demo application for each supported platform. The demo application is a typical debug console style application that showcases the various SDK features through console commands.

Check out the platforms folder for the platform of your interest. The platforms/**/ file contains detailed information on how to build and run the demo application for the specific platform.

Common Tasks

The SDK uses pyinvoke to offer a convenient way to run common tasks such as building, flashing, debugging, etc.

Installing Pyinvoke

To install pyinvoke, make sure you have a recent version of Python 3.x installed. Then run pip3 install -r requirements.txt to install it.

Tip: use a virtualenv to avoid conflicts with dependencies of other projects that use Python


To get a list of available "tasks", run invoke --list from anywhere inside the SDK. It will print the list of available tasks, for example:

$ invoke --list
Available tasks:             Build a demo application that runs on the nrf52
  nrf.clean             Clean demo application that runs on the nrf52
  nrf.console           Start a RTT console session

... etc ...

Running the unit tests

The SDK code is covered extensively by unit tests. They can be found in the tests/ folder. If you'd like to run them yourself, make sure you have CPPUTest installed. When using macOS, you can install it from homebrew by running brew install cpputest.

To build and run the unit tests, just run

$ invoke test

To learn more about unit testing best practices for firmware development, check out our blog post on this topic!

The unit tests are run by CircleCI upon every commit to this repo. See badges at the top for build & test coverage status of the master branch.


  • Where are the Makefiles?

    • For each supported platform (see platforms/**), build system files are included for the specific platforms (for example, Makefiles are included for WICED and CMake files for ESP32). At the moment, there are no "generic" build system files provided, but the platform-specific ones are simple enough to serve as examples of how they could be integrated into your own project.
  • Why does a coredump not show up under "Issues" after uploading it?

    • Make sure to upload the symbols to the same project to which you upload coredumps. Also make sure the software type and software version reported by the device (see "Device information" in components/core/ match the software type and software version that was entered when creating the Software Version and symbol artifact online. More information on creating Software Versions and uploading symbols can be found here.
  • I'm getting error XYZ, what to do now?

You can’t perform that action at this time.