On-Demand Webinar: Beyond Breakpoints, Advanced Debugging Strategies for Modern Embedded Systems

Embedded systems have gotten harder to debug, not because engineers got worse at it, but because the systems changed. Interrupt-driven and event-driven code replaced simple procedural flows. Multicore, real-time constraints, and power sensitivity added layers that a breakpoint and a printf statement were never built to handle. 

The result is teams spending hours, days, or weeks reproducing a single defect. Shawn Prestridge, IAR's US FAE Manager, points out that engineers commonly spend more than half of their development lifecycle in test and fix.

For most teams, the bottleneck is not a lack of debugging tools. It is not knowing which tool in the box actually fits the problem in front of them.

Watch the session

In this recorded conversation between Wevolver and IAR, Shawn Prestridge walks through the debugging techniques that close that gap, with live examples from IAR's embedded workbench.

You will learn:

• How conditional and complex breakpoints let you stop on the exact iteration or condition you care about, using full C syntax with ANDs and ORs, without touching your source code
• How a hard fault destroys the software stack on many ARM cores, and why trace and stack analysis can reconstruct what happened when call frame information alone cannot
• What a log breakpoint does differently from a printf statement, since it gets you the same output without instrumenting your code or changing its timing
• How skip counts stop you from manually hitting F5 through hundreds of loop iterations to reach the one that matters
• Why power debugging matters even for teams that have never treated power as a software concern
• How CI/CD, automated testing, and static and dynamic analysis catch defects before they reach a shared code base

Why watch it

Debugging has not become harder because engineers are less capable. It has become harder because the systems themselves stopped behaving predictably. Shawn, who has worked in embedded development since the mid-1990s, describes the shift plainly: procedural code that always returned to its caller has given way to event-driven systems where the next sequence of calls is never fully known in advance. That shift is what makes a bug hard to reproduce, not just hard to fix.

Some teams still relying on basic breakpoints and printf statements are not doing anything wrong. Those tools have their place. But as Shawn puts it, when the only tool you have is a hammer, every problem looks like a nail, even the ones that need a screwdriver. The cost of that mismatch shows up directly in release timelines: every hour spent bisecting code with trial-and-error breakpoints, or waiting for a bug to reproduce itself, is an hour not spent building.

One example from the session captures the difference well. A hard fault on an ARM-based core often destroys the software stack, so by the time an engineer notices the system has stopped responding, the call information needed to explain why is already gone. Standard debugging leaves the engineer bisecting code with breakpoints, narrowing down the fault location one guess at a time. Trace and stack analysis instead reconstructs the execution history directly, turning a guessing exercise into a direct answer.

Learn from the source

This session is hosted by Samir Jaber, Wevolver's webinar host and editor-in-chief of Wevolver's Edge AI Technology reports, in conversation with Shawn Prestridge, IAR's US FAE Manager. Shawn has worked in embedded firmware development and debugging since 1993 and has spent more than eighteen years at IAR, giving him a direct view of how debugging practice has changed across three decades of embedded development.