From Texas Instruments Embedded Processors Wiki

This page is currently under construction. The content of this page is due to change quite frequently and thus the quality and accuracy are not guaranteed until this message has been removed. Please feel free to contribute to this page while construction is in progress.

Contents 1 Overview 1.1 Advanced Event Triggering (AET) 1.1.1 Example Use Cases 1.1.2 Advanced Event Triggering Library (AETLIB) 1.1.2.1 Example Use Cases 1.2 XDS560 Trace 1.2.1 PC Trace 1.2.1.1 PC Trace Output Display 1.2.2 Data Trace 1.2.2.1 Data Trace Output Display 1.2.3 Event Trace 1.2.3.1 Event Trace Output Display

Overview

There are many debug features that are embedded into the Keystone family of devices. Some of these are core to the C6000 architecture, while some are new in the C66x generation. Some are focused on debugging at the single core CPU level, while some are focused on visibility at the system level of a multicore application. Some can be used with an emulator while connected to Code Composer Studio and require no CPU cycles, while others can be embedded within an application to provide debug analysis data from fielded devices.

This article makes an attempt to gather details for as many debug tools as possible, discuss the capabilities and limitations of each, and allow the user to decide if a particular tool is right for them.

Advanced Event Triggering (AET)

Advanced Event Triggering consists of additional logic embedded in the C6000 architecture that can be configured to generate a set of triggers based on events occurring within the core. These can speed debug by giving the user visibility into what exactly is occurring on the processor. Requirments:

• AET Enabled Device
  • All C64x
  • Full-GEM 64x+ (Not DaVinci or LC Devices)
  • All 674x
  • All C66x

Example Use Cases

Notes:

• These cases specify the capabilities of the AET Hardware. In some cases, the host software (CCS) might not support specific scenarios. In these cases, this functionality would need to be accessed via the Advanced Event Triggering target Library (discussed later)
• These cases specify AET only use cases. AET can also generate triggers to capture PC trace data. Those use cases will be discussed in the PC trace section.

• Trigger a CPU Halt when a specific section of memory is written to (Hardware Watchpoint)
• Count the number of times a PC address is executed
• Count the number of times a function is entered
• Count the maximum number of cycles between consecutive iterations of an interrupt service routine.

In all but the most basic cases, it's important to understand the underlying hardware of AET in order to get a good picture of it's capabilities. Please refer to the following documents for additional details.

C6000 AET Logic

Advanced Event Triggering Library (AETLIB)

AETLIB is a target side library that allows an application to take advantage of Advanced Event Triggering Features while not connected to a Debugger through an emulator. The advantage of this scenario is that a deployed application can monitor behavior with AET without the need for an emulator. It also gives the user the flexibility to control when AET is enabled in the application and when it is not. Additionally, it gives AET to be configured with Run-time information that would not be available when configuring AET via a debugger (CCS)

Example Use Cases

• OS Stack Monitoring
• Testing for writes to memory locations "owned" by other tasks.

See the following links for more information

• AETLIB

XDS560 Trace

XDS560 Trace allows capturing of PC execution, Data Memory Access, and event data in real time, without any intrusion on the Application. A simplistic view of XDS560 Trace is that of a Logic Analyzer placed on the Program and Data buses and the Event signals. XDS560 Trace consists of two different, independent tracing capabilites, often called PC Trace and Event Trace. The trace data is captured and compressed on-chip by the device's Trace Unit. Then, that data can be passed off to a special XDS560 Trace emulator through additional EMU pins, or it can be stored on-chip into a special buffer called the Embedded Trace Buffer (ETB). The amount of data that can be stored varies significantly between these two options. An XDS560T emulator supports configurable sizes up to 64MB of memory for data capture (This is 64MB of compressed data). The largest ETBs are 16Kb, but on some devices are as small as 2Kb. The choice between the two depends on the application and the goals to be achieved.

PC Trace

PC Trace is the ability to capture program execution and data accesses. Advanced Event Triggering is used to specify when and what to turn on Trace Capture and when to turn if off. A timing stream can also be captured with the PC execution, which will give a cycle accurate analysis of how long each instruction took to execute. Offline, when the data is decompressed and analyzed, the PC execution can be correlated with the Assembly instruction address, the associated function, and even the associated line of the C file.

Template:Useful Tip

PC Trace Output Display

The image below shows an example of the output of PC Trace through the CCSv5 Trace Analyzer Display

Sample PC Trace Output

This specific trace data is for a function called "func2()" that's really just a for loop counting to 100 and incrementing a variable j in the process. It's obvious that this function is not optimized, as each iteration of the loop is taking 21 cycles. Checking loops to see how long they are taking is a reasonable use case for PC trace.

The columns shown can be customized from within Code Composer Studio. Simply right click on the the data, and select column settings.

Data Trace

Data Trace is similar to PC trace in the fact that it monitors data traffic over CPU buses. However, it's different in the fact that it monitors data on the Data Address and Data read and Write buses. Data Trace can be captured side by side with PC trace.

Useful Tip PC Trace compresses very nicely as the data is very correlated with other data around it. Data Trace is completely uncorrelated, so the ability to compress is quite limited. This means that Data Trace is very expensive in terms of a) Trace bandwidth and b) Trace Buffer Memory. When using data trace, please note the following recommendations: Trace uses an 8 Sample Deep FIFO buffer to Data Trace. Data can be processed out of this buffer at a rate of about 1 sample ever 90 cycles. Attempting to capture Data Trace at a rate that consistently exceeds 1 sample every 90 cycles can overflow the FIFO and cause Data Trace loss. There are 2 ways to limit the amount of data that is lost. Configure AET to capture only the minimum amount of data possible. Configure Trace to Stall the CPU in order to avoid trace data loss. This is intrusive to the application, and may cause real-time deadlines to not be met.

Data Trace Output Display

The image below shows an example of the output of Data Trace through the CCSv5 Trace Analyzer Display

Sample Data Trace Output

This specific data is from a trace job configured to monitor the reading of a pre-initialized array in a loop. The Trace Job is configured to capture Trace Read data from a range of addresses.

Event Trace

Event Trace can be thought of as PC trace that can be correlated with up to 4 sets of events. There is no data tracing capability when using Event Trace, and there is no ability to turn event trace on/off at specific locations.

Useful Tip Multiple iterations of event trace can help narrow down what events are causing delays in the code. In the first iteration, break up the events into a few different groups. When you identify which groups are occurring, focus on the members of those groups in a separate iteration of event trace until you have narrowed down the exact event that is causing the issue.

Event Trace Output Display

The image below shows an example of the Event Trace output. In this case, we have selected Stall Events, and Group 1 was assigned to CPU stall events.

Sample Data Trace Output

---

Leave a Comment