Observability and OTA for RTOS and Bare-Metal Devices

4.5 kB of Flash and 1.5 kB of RAM in a minimal configuration.

The Memfault SDK only runs on-demand (when collecting crash information or metrics data), and you can control exactly when and how it runs to customize the CPU impact. We’ve intentionally designed the SDK to have a minimal impact- for the (configurable) hourly metrics collection, expect a few hundred CPU cycles to be spent by the Memfault SDK.

Memfault data can be sent over any transport that provides an eventual path to the internet- even if the device is only intermittently connected, Memfault data can be buffered indefinitely until there’s an opportunity to upload. We have customers using all the popular connectivity protocols, like WiFi, Ethernet, Cellular/LTE, Bluetooth, serial protocols to a gateway device, LoRA, Zigbee, proprietary sub-GHz, Satellite Internet, etc.

Memfault’s data collection is highly configurable- coredumps can be as small as 200 bytes and still provide a useful backtrace. Typical daily bandwidth utilization for hourly heartbeats, with 10-12 Metrics, is about 1.5kB. Coredumps are considered atypical events (and should be minimized!), but they can be tuned to fit the memory + bandwidth needs of the device.

Coredumps are fully configurable- we usually recommend a minimum of about 15kB for RTOS devices, but ideally the entire contents of RAM (eg 256kB) would be captured, to provide a full picture of the system at the point of crash. Memfault provides out-of-the-box coredump flash storage implementations for many popular devices, and a RAM-backed storage implementation that can be used on any device. Coredumps can be stored in any medium that’s accessible from the processor during fault handling.

Metrics are high-level data points about the health of a system- think like the CPU or Memory usage statistics on a computer, but fully customizable to track any property of the device. Ambient temperature, transmission error rates and uptime, memory and cpu utilization, battery utilization, and flash wear tracking are a few examples of common metrics our customers are tracking. Read more about metrics and how they can provide rapid feedback on device performance in this article.

Contact us! We’ve fit the Memfault SDK into systems with very low resource availability. Most features of the SDK are customizable, to best balance functionality with memory footprint. In extreme cases we’ve worked with customers to tune the SDK to provide more tightly targeted data collection, to fit into very tiny footprints.

We take the quality of the SDK very seriously, because it’s a core element of the applications using it. Our SDK exposes a self-test API to verify the internal components are configured correctly. The SDK will also capture crashes that occur inside the SDK itself (they’re very rare!), and metrics can be used to measure if device performance isn’t meeting system requirements, to validate if the SDK is causing problems.

Data capture by the Memfault SDK is fully in your control. We provide guidance on how to exclude sensitive data from ever being collected by the SDK. You’re in complete control on whether data is uploaded to Memfault, so if there are cases when data reporting should be paused, that’s fully supported!