Operations | Monitoring | ITSM | DevOps | Cloud

We’re happy to announce that our Trace Export Plugin for MPLAB X IDE has been updated to version 2.3.1 and now supports the latest versions of Microchip’s IDE, including MPLAB X v6.20 and v6.25. This plugin enables saving trace files from Percepio’s TraceRecorder library via the MPLAB X IDE debugger, making it easy to open the trace in Percepio Tracealyzer and related tools.

When using Percepio TraceRecorder, kernel objects like queues, semaphores and mutexes are named using their address by default. This can be a bit hard to follow for complex traces. However, it is quite easy to set more descriptive custom names for your RTOS kernel objects. This by calling the “SetName” functions (or macros) found in the TraceRecorder API, for example: The first argument is the pointer to the object (i.e. the object address).

About 15 years ago, I worked at a company building network security appliances (with ARM-based network processors) and was responsible for the development of custom Linux firmware. The product launch was successful; we shipped and managed a large fleet of devices in the field. After a few firmware releases, we received alerts from the device management system telling us that there were intermittent problems. Remoted into the appliances but could not reproduce the error.

If you’ve been building embedded systems for a while, chances are you know Percepio for Tracealyzer. And we’re proud of that. For over a decade, Tracealyzer has been helping engineers visualize and solve complex RTOS issues faster, with over 30 ways to slice and understand system behavior. But in 2025, embedded systems demand more. They’re always on. Always connected. And increasingly, always business-critical.

Regulations like the EU’s Cyber Resilience Act (CRA) are top of mind for many in the embedded software world right now, and understandably so. The pressure to comply is real, especially for teams already juggling tight schedules and complex development environments. But as disruptive as these mandates might feel, they also present an opportunity and perhaps a necessary nudge to adopt better habits that can strengthen the software we build, far beyond compliance.

If you’ve been working with Zephyr RTOS, you know how powerful and flexible it is for embedded development. At Percepio, we appreciate Zephyr’s hardware abstraction and kernel architecture, which make it easy to get up and running on a wide range of hardware. Now, we have exciting news for developers looking to improve their Zephyr debugging and performance analysis: we’ve validated that Percepio Tracealyzer works on over 600 Zephyr-supported development boards!

The world of embedded systems evolves, with devices growing ever more sophisticated and software-centric. In this new landscape, with highly interconnected environments that defy traditional testing and debugging approaches, a reactive, fire-fighting mentality is no longer sufficient. Developers need a proactive strategy to gain continuous visibility into system behaviour—a strategy known as observability-driven development (ODD).

FreeRTOS 11 introduced symmetric multi-processing (SMP) support in the mainline kernel, meaning a single FreeRTOS kernel is managing multiple processor cores. This allows for high performance but also makes the runtime system more complex, meaning higher risk of issues and more difficult debugging. System tracing with Percepio Tracealyzer can offer an effective remedy by providing insight into the system execution.

There have been significant improvements in Tracealyzer over the last years. If you haven’t tried it in a while—or if you’re just getting started—here are some tips and tricks that can be handy when analyzing your FreeRTOS applications. As you may know, the TraceRecorder library automatically records task scheduling and FreeRTOS API calls using the standard trace hooks in the FreeRTOS kernel.

You hear us at Percepio talking about Observability a lot. For customers using our award-winning Tracealyzer tool, this might sound a bit strange – isn’t Tracealyzer about diagnostics, debugging and profiling? Mostly, yes, but let me share why we are putting so much emphasis on our Continuous Observability solutions.