One of the core features of the Memfault Linux SDK is the ability to capture and analyze crashes. Since the inception of the SDK, we’ve been slowly expanding our crash capture and analysis capabilities. Starting from the standard ELF coredump, we’ve added support for capturing only the stack memory and even capturing just the stack trace with no registers and locals present.

Monitoring IoT applications is essential due to their operation in dynamic and challenging environments, which makes them susceptible to various operational and connectivity issues. Application Performance Monitoring (APM) is the key to identifying and resolving these issues in real time, ensuring uninterrupted data flow and functionality. Moreover, the insights gained from APM can optimize device performance, ensure reliability, and reduce operational costs.

This guide provides instructions for setting up an environment for developing, debugging, and programming embedded systems firmware in the Windows Subsystem for Linux (WSL2). WSL2 provides a convenient and stable Linux development environment for working on embedded systems firmware. If you’re curious about toolchain performance, check out this comparison of firmware development environments, but the summary is that WSL2 is about 2x the speed of Windows and similar to “bare metal” Linux.

At Ultrahuman, innovation is at the core of everything we do. Our health devices, powered by the nRF52840 SoC for BLE functionality, rely on Nordic Semiconductor’s renowned wireless technology. For years, the nRF5 SDK was the cornerstone of firmware development for these chipsets, but in 2018, Nordic introduced the nRF-Connect SDK(NCS), built on Zephyr RTOS, signaling a new era for BLE applications.

While using a full-blown filesystem for storing your data in non-volatile memory is common practice, those filesystems are often too big, not to mention annoying to use, for the things I want to do. My solution? I’ve been hard at work creating the sequential-storage crate. In this blog post I’d like to go over what it is, why I created it and what it does.

In this very Memfault-centric post, I’ll be talking about how we shipped our SDK as an ESP-IDF component. This is a continuation of our efforts to make it easier to integrate Memfault into your projects, specifically targeting ESP32-based projects.

Last week, a handful of Memfolks had the opportunity to travel to Austin to attend the first ever Embedded World North America1! Embedded World NA welcomed 3,500 visitors and 180 vendors across 3 days2. While it was surely a smaller showing than Nueremburg’s Embedded World, we still wanted to quickly touch on our takeaways from the event. In this post, we will cover what we learned from the first Embedded World North America.

About a year and a half ago, I decided to take a different approach to setting up a Zephyr environment for a new project at Intercreate. Instead of using my trusty VMWare Workstation Linux VM, I opted for WSL2. I was curious to find out: Would hardware pass-through for debugging work reliably? Would all of the tooling dependencies be supported? What about build system performance?

In this article, we will learn how memory usage patterns can affect the real-time performance of an embedded application, drawing from a recent experience tracing an audio DSP application running on an embedded Linux platform. First, I will introduce the product in question and the real-time audio software I developed for it. Then, I’ll describe the issues I encountered with audio callbacks and the strategy I followed to determine the cause of the issues, ending with my solution and lessons learned.

The JTAG interface is an important tool for debugging and testing embedded systems, providing low-level access to the internal workings of microcontrollers and other integrated circuits. However, this powerful interface also presents significant security threats. In the sixth and final part of this Diving into JTAG article series, we will focus on security issues related to JTAG and the Debug Port.