|Non-Confidential||PDF version||ARM DUI0446Z|
|Home > Examining the Target > About trace support|
ARM® DS-5 enables 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.
There 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 function.
In addition, it is common to store trace information in an on-chip 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.
Enables trace capture when execution reaches the selected address.
Disables trace capture when execution reaches the selected address
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 view.
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 captured 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.