you to perform tracing on your application or system. Tracing enables you to
non-invasively capture, in real-time, the instructions and data accesses that were
executed. It is a powerful tool that enables you to investigate problems while the
system runs at full speed. These problems can be intermittent, and are difficult to
identify through traditional debugging methods that require starting and stopping
the processor. Tracing is also useful when trying to identify potential bottlenecks
or to improve performance-critical areas of your application.
When a program fails, and the trace buffer is enabled, you can see
the program history associated with the captured trace. With this program history,
it is easier to walk back through your program to see what happened just before the
point of failure. This is particularly useful for investigating intermittent and
real-time failures, which can be difficult to identify through traditional debug
methods that require stopping and starting the processor. The use of hardware
tracing can significantly reduce the amount of time required to find these failures,
because the trace shows exactly what was executed.
Before the debugger can trace your platform, you must ensure that:
you have a debug hardware agent, such as an ARM DSTREAM unit or a software debug agent such as ARM VSTREAM, with a connection to a trace stream.
the debugger is connected to the debug hardware agent.
Trace is typically provided by an external hardware block connected to the processor. This is known as an Embedded Trace Macrocell (ETM) or Program Trace Macrocell (PTM) and is an optional part of an ARM
architecture-based system. System-on-chip designers might omit this block from their silicon to reduce costs. These blocks observe (but do not affect) the processor behavior and are able to monitor instruction execution and data accesses.
are two main problems with capturing trace. The first is that
with very high processor clock speeds, even a few seconds of operation can mean
billions of cycles of execution. Clearly, to look at this volume of information
would be extremely difficult. The second problem is that data trace requires very
high bandwidth as every load or store operation generates trace information. This is
a problem because typically only a few pins are provided on the chip and these
outputs might be able to be switched at significantly lower rates than the processor
can be clocked at. It is very easy to exceed the capacity of the trace port. To
solve this latter problem, the trace macrocell tries to compress information to
reduce the bandwidth required. However, the main method to deal with these issues is
to control the trace block so that only selected trace information is gathered. For
example, trace only execution, without recording data values, or trace only data
accesses to a particular peripheral or during execution of a particular
In addition, it is common to store trace information in an
memory buffer, the Embedded Trace Buffer (ETB).
This alleviates the problem of getting information off-chip at speed, but has an
additional cost in terms of silicon area and also provides a fixed limit on the
amount of trace that can be captured.
The ETB stores the compressed trace information in a circular fashion,
continuously capturing trace information until stopped. The size of the ETB varies between chip implementations, but a buffer of 8 or 16kB
is typically enough to hold a several thousand lines of program trace.
Trace ranges enable you to restrict the capture of trace to a linear range of memory. A trace range has a start and end address in virtual memory, and any execution within this address range is captured. In contrast to trace start and end points, any function calls made within a trace
range are only captured if the target of the function call is also within the specified address range. The number of trace ranges that can be enabled is determined by the debug hardware in your processor.
Trace capture is enabled by default when no trace ranges are set. Trace capture is disabled by default when any trace ranges are set, and is only enabled when within the defined ranges.
You can configure trace ranges using the Ranges tab in the Trace view. The start and end address for each range can either be an absolute address or an expression, such as the name of a function. Be aware that optimizing compilers might rearrange or minimize
code in memory from that in the associated source code. This can lead to code being unexpectedly included or excluded from the trace capture.
Trace points enable you to control precisely where in your program trace is captured. Trace points are non-intrusive and do not require stopping the system to process. The maximum number of trace points that can be set is determined by the debug hardware in your processor. The
following types of trace points are available:To set trace points in the source view, right-click in the margin and select the required option from the DS-5 Breakpoints context menu. To set trace points in the Disassembly view, right-click on an instruction and
select the required option from the DS-5 Breakpoints context menu. Trace points are listed in the Breakpoints view.
- Trace Start Point
Enables trace capture when execution reaches the selected address.
- Trace Stop Point
Disables trace capture when execution reaches the selected address
- Trace Trigger Point
Marks this point in your source code so that you can more easily locate it
in the Trace view.
Trace Start Points and Trace Stop Points enable and disable capture of trace respectively. Trace points do not take account of nesting. For example, if you hit two Trace Start Points in a row, followed by two Trace Stop Points, then the trace is disabled immediately when the first
Trace Stop Point is reached, not the second. With no Trace Start Points set then trace is enabled all the time by default. If you have any Trace Start Points set, then trace is disabled by default and is only enabled when the first Trace Start Point is hit.
Trace trigger points enable you to mark interesting locations in your source
code so that you can easily find them later in the Trace view. The first time a
Trigger Point is hit a Trace Trigger Event record is inserted into the trace buffer.
Only the first Trigger Point to be hit inserts the trigger event record. To
configure the debugger so that it stops collecting trace when a trace trigger point
is hit, use the Stop Trace Capture On Trigger
checkbox in the Properties tab of the Trace
This does not stop the target. It only stops the trace capture. The target continues running normally until it hits a breakpoint or until you click the Interrupt icon in the Debug Control view.
When this is set you can configure the amount of trace that is
before and after a trace trigger point using the Post-Trigger
Capture Size field in the Properties tab of
the Trace view. If you set this field to:
The trace capture stops as soon as possible after the first trigger point is hit. The trigger event record can be found towards the end of the trace buffer.
The trace capture stops after the first trigger point is hit and an additional 50% of the buffer is filled. The trigger event record can be found towards the middle of the trace buffer.
The trace capture stops after the first trigger point is hit and an additional 99% of the buffer is filled. The trigger event record can be found towards the beginning of the trace buffer.
Due to target timing constraints the trigger event record might get pushed out of the trace buffer.
Being able to limit trace capture to the precise areas of interest is especially helpful when using a capture device such as an ETB, where the quantity of trace that can be captured is very small.
Select the Find Trigger Event record option in the view menu to locate Trigger Event record in the trace buffer.
Trace trigger functionality is dependent on the target platform being able to
signal to the trace capture hardware, such as ETB or DSTREAM, that a trigger condition has occurred. If this hardware
signal is not present or not configured correctly then it might not be possible
to automatically stop trace capture around trigger points.