When Breakpoints Aren’t Enough: Debugging Faster with ULINKpro Trace

Most embedded developers are familiar with the usual debugging cycle: set a breakpoint, stop the processor, inspect the problem, make a change, and try again.

That works well until the problem depends on timing, interrupts, RTOS task interaction, DMA, communication traffic, or a failure that only occurs occasionally.

At that point, stopping the processor can sometimes hide the very problem you are trying to find.

This is where trace can make a significant difference.

See More Than the Current Breakpoint

A debugger such as Keil ULINK2 provides SWD/JTAG debugging together with Serial Wire Viewer (SWV), giving developers runtime information such as events, exceptions, data activity, and program-counter sampling.

But SWV is still only showing selected information about what happened.

With ULINKpro and ETM instruction trace, the debugger can capture the processor's actual execution history and reconstruct the instructions and code paths that were executed.

Instead of reaching a fault and asking:

“Why did my software end up here?”

you can trace backwards through the execution sequence that led to it.

For complex embedded systems, that difference can dramatically reduce the amount of trial-and-error debugging required.

Why ULINKpro?

ULINKpro combines traditional debugging with high-speed SWV and ETM instruction trace of up to 800 Mbit/s on supported Cortex-M devices. It can also stream trace directly to the host computer, allowing much longer trace sessions.

That gives engineering teams several practical advantages:

• Find intermittent faults faster by examining what happened before a crash or HardFault.
• Debug without constantly stopping the processor, helping preserve real-time behaviour.
• Follow complex execution paths across functions, interrupts and application logic.
• Identify performance bottlenecks using execution profiling.
• Generate code-coverage information during testing.
• Capture longer scenarios instead of repeatedly trying to reproduce the issue.

For example, a normal debugging session might tell you that the processor reached HardFault_Handler().

ETM trace can help reveal the sequence behind it:

Task → ProcessPacket() → Interrupt → Buffer Access → Invalid Pointer → HardFault

That extra context can turn repeated breakpoint placement into a much more focused root-cause investigation.

ULINK2 or ULINKpro?

For everyday firmware development, ULINK2 remains a capable debugger and provides SWV trace for runtime visibility.

ULINKpro becomes valuable when simply knowing the current state is no longer enough.

ULINK2 helps you see what the system is doing.

ULINKpro can help you understand how the system got there.

For RTOS applications, communication stacks, interrupt-heavy firmware, and timing-dependent failures, that execution history can significantly shorten the path from “we reproduced the problem” to “we found the root cause.”

ETM trace does require support from the target processor and the appropriate trace connections on the hardware, but when available, ULINKpro provides a level of visibility that traditional stop-and-go debugging cannot.