Beyond Breakpoints: The Debugging Hardware Already Inside Your Microcontroller

An embedded system occasionally misses a deadline. Most of the time, its control task finishes comfortably within its budget. Sometimes it runs late. Adding diagnostic output changes how often the problem occurs. A breakpoint lets you inspect the variables, but stopping the processor interrupts the timing relationship you need to understand.

What happened during the failing run?

A breakpoint exposes the processor's state after it stops. Logging records the events that the firmware was programmed to report. Neither necessarily preserves the sequence that led to the failure. Many ARM Cortex-M microcontrollers, however, contain hardware that can help recover part of that history. Depending on the device, this hardware can count processor activity, report selected memory accesses and exceptions, sample execution, or generate instruction traces.

In my work developing embedded debugging and trace tools at BKPT, I keep encountering the same gap: a capability can exist in the silicon without becoming useful evidence on an engineer's desk. Closing that gap means understanding what the hardware observes, how the information reaches the host, and what conclusions a recording can support.

Start with the Question

Hardware trace is often introduced as a collection of acronyms. A more useful starting point is the question you need to answer.

To find where the processor spends its time, a statistical execution profile may be enough. To investigate interrupt activity or selected CPU accesses to a variable, event trace may be more useful. To understand the execution path leading to a fault, an instruction trace may provide the missing history.

On supported Cortex-M implementations, the Data Watchpoint and Trace unit, or DWT, provides features such as counters, program counter sampling, and exception or data-access tracing. Features vary by implementation. The processor family name alone does not establish what a particular chip supports, so the processor and device documentation matter. [1]

These observations answer different questions. Samples can identify a frequently executing function without recording every invocation. A configured data trace can report matching CPU accesses without requiring a print statement at each access. Neither provides a complete record of everything happening in the system.

The Instrumentation Trace Macrocell, or ITM, offers another route for information. Firmware can write messages or structured events to its stimulus ports, commonly transported through Serial Wire Output, or SWO. This is useful for marking application activity, but the firmware still executes instructions to produce those messages. Hardware transport does not eliminate the cost of software instrumentation. [2]

Instruction trace addresses the execution path itself. An Embedded Trace Macrocell, or ETM, produces execution information that decoding software can present as instruction history, calls, and source navigation. It can reveal an unexpected branch or sequence of calls without adding logging to those paths. [1, 3]

That history has limits. Browsing an earlier instruction does not restore the processor to its previous state. Cortex-M instruction trace alone does not provide the historical value of every register or variable. Choosing the right observation is the first engineering decision; collecting more data helps only when it answers the question under investigation.

Follow the Trace Out of the Chip

Finding a trace feature in a processor manual is only the beginning. The microcontroller manufacturer must have included the relevant block and connected it to a usable output or storage destination. The package and board must expose any required signals. The probe must support the capture method, and the host software must configure and decode it correctly.

A board can support ordinary debugging while leaving trace signals inaccessible. A probe can support SWO while lacking the hardware needed to capture a parallel instruction-trace interface. Two devices using the same Cortex-M core can offer different practical options. Whether you use tools from SEGGER, BKPT Labs, or another vendor, verify the exact target, probe, and capture mode together.

This helps explain why tracing can feel difficult to set up. The configuration spans processor architecture, device integration, board design, probe behavior, and host software. When one part is missing or misconfigured, the result may be an empty trace window with little indication of where the problem lies.

Cost matters as well, particularly for sustained external instruction capture. Receiving a fast trace stream reliably requires suitable acquisition hardware and enough bandwidth throughout the capture path. Dedicated instruments offer capabilities that a basic programming and debugging probe may lack.

There are also simpler entry points. Supported SWO workflows can expose selected events through an existing probe. Some devices contain an on-chip trace buffer that can be retrieved through the debug connection, providing a recent window of execution without a separate high-speed trace connection. [4]

The buffer's capacity limits how much history survives. In circular operation, a new trace replaces the old trace, so a long test run may leave only a short tail of execution available for inspection. That tail may be exactly what a fault investigation needs. A problem that unfolds over a longer period may require sustained external capture.

Use each capture to narrow the investigation

Returning to the system that occasionally misses its deadline, a useful first capture might combine application markers around the control task with supported exception tracing. The markers identify the work being measured, while exception events help show how interrupt activity relates to it. Measuring durations also requires suitable timestamps and an understanding of the relevant clocks.

Suppose, in this example, failing iterations coincide with additional interrupt activity. That observation narrows the investigation, but it does not yet establish the cause. The interrupt handler might be doing excessive work, or another condition might be causing both the interrupts and the delay.

The next capture should address that uncertainty. Selected data-access events could help investigate shared state. Instruction history could expose a retry path or an unexpected call sequence, provided the relevant execution fits within the capture.

Each recording should lead to a more specific question. This also helps control trace volume: enable the sources needed to test the current explanation, then refine the configuration as the evidence develops.

Software instrumentation remains useful throughout the process. A compact event marking a transaction boundary can give hardware observations application meaning. Its cost still needs to be accounted for, and the recording should distinguish events generated by firmware from events observed by the processor's trace hardware.

Treat the Recording as a Measurement

A convincing graph can still support an incorrect conclusion. When building trace tools, representing uncertainty is as consequential as decoding packets. Engineers need to know what produced each value, what its timestamp represents, and whether information may be missing.

A periodically read variable is a sample; it may change several times between reads. A DWT access event describes an observed CPU access. It does not establish that every direct memory access (DMA) transfer or autonomous peripheral change was observed. Even after the CPU halts, peripherals and DMA may continue operating unless the device and debugger explicitly freeze them.

Time requires the same care. The host time at which a USB transfer arrives differs from the target time at which an event occurred. Putting two series on one axis does not establish that their clocks are aligned. Instruction order, instruction count, processor cycles, and elapsed time are distinct measurements. Remember TOCTOU (Time of check to time of use) is another one to watch out for.

Capture completeness matters too. A transport can overflow, a decoder can lose synchronization, or a circular buffer can overwrite the beginning of the sequence under investigation. A missing event may indicate missing data rather than absent behavior.

Those limits should remain visible when a recording is saved and reopened. Without them, another engineer may draw a stronger conclusion than the original capture supports.

The executable belongs with the recording as well. Compressed instruction-trace decoding depends on the executed program image, and useful source navigation requires corresponding debug information. Even a nearby build can produce misleading results. Preserve the matching binary, symbols, source revision, and capture configuration together. [3]

AI Needs Evidence from the Running Chip

‍AI-assisted development makes this observation gap especially clear. An assistant working from source code can suggest possible execution paths and explanations for a fault. Those explanations remain hypotheses about a system it has not observed. If its access ends at building and flashing the firmware, it is effectively blind once the microcontroller starts running. The source alone cannot tell it which interrupt arrived during a particular iteration or which branch the processor actually took.

An assistant connected to a debugger, logs, or a test system can use the evidence those tools provide. Trace adds another source of evidence, including execution history that a stopped debugger or a few log messages may not preserve. The same observation tools engineers need can help an AI assistant check whether its explanation matches the behavior of the device.

Consider the missed deadline again. From a code review, an assistant might identify a loop in an interrupt handler as a possible source of delay. That is a useful lead. A suitable capture could help establish whether the handler ran during the failing iteration, whether execution reached the suspected loop, and, with appropriate timing information, how much of the available budget it consumed. After a change, another capture could test whether the measured behavior improved.

For tool builders, this means making captures accessible to software as well as readable on a screen. Decoded events should retain their timing information, the identity of the matching firmware, and any known gaps or uncertainty. An assistant needs those limits to interpret a recording responsibly. Giving AI access to trace does not make every internal state observable, but it gives the investigation measurements from the actual device to work with. Better code reasoning still needs a way to check what happened on the chip.

Make Observation Part of Development

Getting started does not require enabling every trace source. Choose a question that matters to the current project, then check the exact device documentation and board schematic. Identify the available counters, trace sources, outputs, and buffers, and establish which of them your probe and software can use.

Begin with a short, controlled capture containing behavior you can recognize. Confirm that expected events appear, inspect the available loss indicators, and check what the timestamps mean before using the setup to explain an intermittent failure.

Once the capture is trustworthy, preserve it. A recording lets another engineer inspect the evidence after the bench session ends. With suitable timing information and sufficient coverage, the same measurement can support a regression check: did a change introduce an unexpected path, increase interrupt activity, or violate an established execution budget?

Board design deserves attention here, too. Trace-pin routing, connectors, and access to debug signals determine which future investigations will be possible. Reviewing these options while designing the board can prevent an otherwise capable chip from becoming difficult to observe.

The processor may already contain much of the observation hardware you need. Connecting it to a specific engineering question, checking the capture's limits, and preserving the evidence make that hardware useful. When the next failure depends on timing or execution history, a recording of the relevant behavior can give the investigation a concrete place to begin.

References

[1] Arm. Cortex-M3 Technical Reference Manual.

https://documentation-service.arm.com/static/5e8e107f88295d1e18d34714

[2] STMicroelectronics. AN4989: Introduction to debug toolbox for STM32 MCUs.

https://www.st.com/resource/en/application_note/an4989-introduction-to-debug-toolbox-for-stm32-mcus-stmicroelectronics.pdf

[3] Linaro. OpenCSD Library - Programmers Guide.

https://github.com/Linaro/OpenCSD/blob/master/decoder/docs/prog_guide/prog_guide_main.md

[4] Arm. How to debug: CoreSight basics (Part 3).

https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/how-to-debug-coresight-basics-part-3