314
14.1
Introduction
With increasing complexity of embedded systems, demands to debug probes and utilities
(IDE, ...) increase too. With tracing, it is possible to get an even better idea about what is
happening / has happened on the target system, in case of tracking down a specific error.
A special trace component in the target CPU (e.g. ETM on ARM targets) registers instruc-
tion fetches done by the CPU as well as some additional actions like execution/skipping
of conditional instructions, target addresses of branch/jump instructions etc. and provides
these events to the trace probe. Instruction trace allows reproducing what instructions have
been executed by the CPU in which order, which conditional instructions have been exe-
cuted/skipped etc., allowing to reconstruct a full execution flow of the CPU.
Note
To use any of the trace features mentioned in this chapter, the CPU needs to implement
this specific trace hardware unit. For more information about which targets support
tracing, please refer to Target devices with trace support .
14.1.1
What is backtrace?
Makes use of the information got from instruction trace and reconstructs the instruction
flow from a specific point (e.g. when a breakpoint is hit) backwards as far as possible with
the amount of sampled trace data.
Example scenario: A breakpoint is set on a specific error case in the source that the ap-
plication occasionally hits. When the breakpoint is hit, the debugger can recreate the in-
struction flow, based on the trace data provided by J-Trace, of the last xx instructions that
have been executed before the breakpoint was hit. This for example allows tracking down
very complex problems like interrupts related ones, that are hard to find with traditional
debugging methods (stepping, printf debugging, ...) as they change the real-time behavior
of the application and therefore might make the problem to disappear.
14.1.2
What is streaming trace?
There are two common approaches how a trace probe collects trace data:
1. Traditional trace:
Collects trace data while the CPU is running and stores them in a buffer on the trace robe.
If the buffer is full, writes continues at the start of the buffer, overwriting the oldest trace
data in it. The debugger on the PC side can request trace data from the probe only when
the target CPU is halted. This allows doing backtrace as described in What is backtrace?
on page 314.
2. Streaming trace:
Trace data is collected while the CPU is running but streamed to the PC in real-time, while
the target CPU continues to execute code. This increases the trace buffer (and therefore
the amount of trace data that can be stored) to an theoretically unlimited size (on modern
systems multiple terabytes). Streaming trace allows to implement more complex trace
features like code coverage and code profiling as these require a complete instruction flow,
not only the last xx executed instructions, to provide real valuable data.
14.1.3
What is code coverage?
Code coverage metrics are a way to describe the "quality" of code, as "code that is not
tested does not work". A code coverage analyzer measures the execution of code and shows
how much of a source line, block, function or file has been executed. With this information it
is possible to detect code which has not been covered by tests or may even be unreachable.
J-Link / J-Trace (UM08001)
CHAPTER 14
© 2004-2017 SEGGER Microcontroller GmbH & Co. KG
Introduction
Need help?
Do you have a question about the J-Link and is the answer not in the manual?