Percepio adds Zephyr monitoring to Detect 2026.1

Percepio has extended its Detect 2026.1 embedded observability platform with native support for Zephyr RTOS, allowing developers to record diagnostic evidence from running devices after selected faults or unexpected behaviour. The update builds on support for FreeRTOS and introduces a way to capture traces, logs and optional core dumps without streaming every operating detail continuously to a host. The objective is to make intermittent failures easier to investigate when an engineer cannot reproduce the original conditions on a laboratory bench.

Real-time operating systems coordinate several tasks on limited processing hardware while preserving required response times. Failures may involve rare timing interactions, resource exhaustion or unexpected interrupt behaviour that disappear when extra debug instrumentation changes the workload. Conventional development can rely on breakpoints and live trace connections, but those techniques may not be available once hardware is deployed in the field. A compact diagnostic snapshot preserves selected information for later analysis without requiring engineers to be present when the fault occurs.

Percepio describes monitoring that triggers when a defined anomaly, application event or crash occurs. On supported Arm Cortex-M hardware, developers can also call an API to capture a snapshot and related call-stack information for conditions that have not caused a fatal RTOS error. This is useful when a task misses a deadline or a sensor reports an unexpected state but the system continues operating. Capture settings must still be chosen carefully so diagnostic collection does not overload flash storage, memory or the processor.

The update can feed information into Tracealyzer and related debugging tools to examine task scheduling and interactions around a triggering event. A trace may show that one task waited unexpectedly for a resource or that a higher-priority routine delayed essential work. A core dump offers different information about processor state and memory at a particular moment. Developers need to correlate both with firmware version, configuration and time of occurrence to establish a credible root cause rather than assuming the last visible task caused the problem.

Zephyr is used across a broad range of embedded devices, with configurations differing by hardware architecture, drivers and enabled RTOS features. Native integration can reduce the effort of adding observability, but developers must verify the supported operating modes and overhead for each product. In a highly constrained microcontroller, even a small memory reserve can compete with communications buffers or application code. Measurements under maximum workload and fault conditions are necessary before enabling diagnostic functions in a production build.

Data handling deserves attention where snapshots may include application information or fragments of memory. An event trace from a medical or industrial system may reveal identifiers, settings or operational behaviour that should not be widely accessible. Teams need secure storage, controlled retrieval and an appropriate retention policy. On connected products, sending diagnostic information over a network introduces additional risk; on isolated equipment, field-service procedures must establish how it can be recovered without disrupting essential functions.

Developers also need criteria for deciding which events are worth capturing. A very sensitive threshold can produce more diagnostic information than a device can store or a team can use, while a threshold that is too high may miss the onset of failure. Selecting triggers is an engineering task grounded in the application’s expected timing, resource use and error handling. Captured information should be checked against known faults in a controlled test environment so teams can establish whether the tool preserves the evidence necessary to distinguish genuine defects from ordinary operating variation.

Detect 2026.1 extends the tools available for diagnosing Zephyr-based software in environments where failures are difficult to reproduce. It does not make the application deterministic by itself or replace verification, code review and hazard analysis. The practical value lies in whether captured evidence helps engineers identify intermittent faults faster while keeping the diagnostic footprint acceptable for the deployed hardware. Bench testing under realistic scheduling and memory pressure remains the first step before field use.