unified breakpoint manager (ubm)processors.wiki.ti.com/images/0/0d/ubm-ext-02.pdf · 37 ti public...

TI Public Data Stephen Lau Oct 3, 20071

Unified Breakpoint Manager (UBM)

Actually, it can do more than just breakpoints…..


What can I do with the UBM Setup:

SW BreakpointsHardware BreakpointsHardware WatchpointsCountersTrace

Examples of things that can be done:Count the # of L1D stalls in an algorithm.Halt the processor whenever a particular data variable is overwritten with a special value.Halt on a particular line at the 10th loop iteration.Setup Trace JobsToggle the EMU1 pin to trigger an external logic analyzer whenever a particular data variable is read.


What NEW features will I get with UBM?Most trigger types are now possible in a single interface

Easy to setup various types of trigger types, such as ranged data watchpoints, chained HW watchpoints, etc.

The UBM dynamically determines what AET resources you have left.It will not allow you to setup an AET job if there are no AET resources available.

Configurable Display ColumnsLoading/Saving breakpoints to a fileGrouping breakpoints, and enabling/disabling groupsAssociate breakpoints to a symbolic location

Automatically adjust to edits, re-compiles/reloadsSetup actions on reaching a breakpoint

Call a GEL fileLoading a file to memory

Can now set data watchpoints from the variable watch windowAbility to see system configured breakpoints (ex: CIO and End of Program Breakpoints)


What other NEW features do I get with UBMCan now access Event triggers on 64x+ devices

Can set up HW Watchpoints on these EventsCan setup Trace triggers based on these Events (Start/Stop Tracing)

Events can be either at the 64x+ subsystem, or come from the SoC(including peripherals)Can also easily generate different actions based on triggers:

Halt CPUToggle EMU0/1 pinGenerate RTOS Interrupt

In existing AET plug-in we can only count basic events, and can only count them. CPU Stalls, L1P Read Miss, L1P Stalls, Etc.

With UBM, we can now access ALL the events on 64x+L1D write miss, hits external, non- cacheable, Dirty Victim Writeback from L2, DMA Snoop Read, Host interrupt, Ethernet MAC interruptEMIFA Error Interrupt, RapidIO interrupt 0, RapidIO error, EDMA3 channel global completion interrupt, Utopia interruptMcBSP0 receive interrupt, Etc. (Many Device specific ones check device datasheet)


Basic UBM Method of Operation1. Create a new event: Breakpoint (Software), Hardware

Breakpoint, Hardware Watchpoint, Count, Trace, etc.2. Open the property page for the new event.3. Configure the event. 4. Check “Enable”5. Click “Submit” in the property page.


Tutorial: Setting a SW Breakpoint


Activate UBM by going to

Debug Breakpoints


The UBM window appears


This button allows you to setup a NEW action. Choose from the drop-down the type of action you need.

In this example, choose “Software Breakpoint”


A Software Breakpoint is now added to the system, and is enabled. If this breakpoint is hit, the black arrow will change.

A red dot is shown in the editor to indicate where the breakpoint is set.

By clicking on the properties page, the action, skip count, and conditions can be changed.


Tutorial: Setting a AET Hardware Breakpoint


Choose Hardware Breakpoint from the drop down menu.


By default, a AET HW breakpoint is not enabled. A property window can be opened to change the breakpoint configuration. In this property window, you can choose: Trigger conditions, Action

taken, Name of breakpoint, etc.


•Clicking on the + sign opens up the type of breakpoint actions. It is currently set to “Point”, which means it will cause an action (in this case Action=Halt Target) whenever the address value is

executed. •Other types of triggers can be

selected.

•You can configure the type of action by selecting the “Action” tab.•Note that the action under “logical properties” is CCS Debugger actions


•In the location tab, you can enter either the address value directly, or the symbolic value. •Note that drag&dropof symbol names, is not supported.


•Type in the physical address value.


•Check the action. “Halt Target” is selected. Other options exist, such as “Toggle EMU pin” or “Generate RTOS Interrupt”


•By default, the AET HW Breakpoint is disabled. You need to check this box to enable the breakpoint.


•Now that it is enabled, you must “Submit” the changes to have them take effect.

•“Submit”

•Icon indicates that job has not been enabled. It will be red when it is enabled.

•Note the job in italics and *, indicating that the job has not been submitted.


•Icon indicates that job is now enabled.

•Icon indicates the location of the AET HW breakpoint.


Type in voidfunc

•You can type in the symbol name •When you press “enter” it will resolve the address.


•If you change the type of breakpoint to “Range”, it will cause an action (such as halt) whenever any code from the region is executed.


Tutorial: Setting up an AET HW Watchpoint

Ex: Halt CPU on any size write access to data memory address range.


•Setup a new AET HW Watchpoint


•In the properties page for the AET HW Watchpoint, the default action is to halt the CPU.


•Click on the “+” of the trigger type to configure the trigger. •It is defaulting to “point” which means it will cause an action when the data address is reached.


•In the location, you can type in the symbol for the data variable. In this case, you use the &xxx to put in the address for the variable xxx.


•This will allow you to select the access width. This is useful if you want to only cause an action for a particular type of access. •Note that “write” is selected as the type of access.


•Once you are done configuring the AET HW Watchpoint, select “enable” and click the “Submit” Button.

•Icon indicates that job has not been enabled. It will be red when it is enabled.

•Note the job in italics and *, indicating that the job has not been submitted.


•Job has been submitted and enabled.


Tutorial: Setting up a Counter

Ex: Count the # of program cache misses (that need to go to external memory) in a certain

section of code


•Select the “Count” Option in the UBM

•A dialog will show up, allowing you to select what type of counter you need.


•The “Count Event” Properties page opens, allowing you to configure the type of event to be counted.


•Select the type of event you want to count: Memory, Stall, or System.


•Stall has been chosen, allow the user to select the types of stalls that are counted. Checking the boxes will enable the particular type of stall event.


•If memory is chosen, then a different set of options become available. Again, checking the boxes will enable the particular type of stall event.


•In selecting memory event, you can choose the type of Level 1 Program (L1P) Read Misses to count. In this case, I am only interested in the those L1P misses which hit the external memory. This means the L1P access misses the L1 Program cache, and misses the L2 Program cache, and is forced to go to the external memory interface. This is a very costly type of cache event.


•Scroll down in the properties page, and select “In PC Range” to select the program range for which you want the cache events to be counted. This allows the counting of events to be narrowed down to a particular program region.


•I wish to have the entire inclusive program range, so select “inclusive”


•Add in the program addresses regions.

•Once the program is run, click refresh to get an updated “count” value.

•Refresh


Tutorial: Using UBM with XDS560 Trace

Ex: Trace the program execution until a variable is corrupted.

Ex: “Show me how I corrupted my program stack.”


•Create a new “Trace” event


•Standard Trace has been selected. Click + to configure the information trace will collect.


•Select the types of trace that you want to get. •In this case, Program address and timestamp are selected.


•After submit the job, the trace ON is now enabled. •If this is the first trace event setup, then the XDS560 Trace system will start up.


•Create a new Trace Event. We will use this one to stop the XDS560 Trace collection upon a data write to a data variable.


•Change the “Action” to select “End All Trace”•This will stop all trace collection.


•In “Trigger Type” select “Data Memory”. •We want to stop all tracing if any application code writes to the Data_4 variable. •Set the “Location Type” to be “Range” and set the start and end locations to be the start and end address for the “Data_4” variable.•If the location range was the top of the stack, then this technique would allow us to examine trace on any stack overflow. •Remember to click “Enable” AND “Submit”


•After running the trace system, and looking at the end of the trace buffer, we can see that we have stopped tracing upon the first data write to the Data_4 variable.


Tutorial: Configuring Event Trace

“Help me optimize my cache operations by showing me where I have cache misses in my

code.”


•If the trace type of “Event” is selected instead of “Standard”, then the trace system will be configured for “Event Tracing”•This will allow the user to select from several global categories: Stall, Memory, System, and External. •Note that event types are determined by the device being used. This information should be in the datasheet.

•In this case, I have chosen to view all types of CPU stalls as well as any type of L1P cache stall. •Event 1 is setup for CPU stalls, and Event 2 is setup for L1P stalls. Thus, in the trace display, if there are any “1” in the stall event column, they will be CPU stalls. If there are any “2 in the stall event calumn, they will be L1P stalls. •This information helps a user to determine the type of stall on a per-line basis.


•From the trace output, we can see that we have CPU stalls and not L1P stalls. •This is because the Stall Cycles display shows “1” instead of “2”•Note that the meaning of “1” and “2” is wholly dependint on how you configure the events.


Summary


UBM SummaryReplacing existing AET plug-ins, and will transition into CCS-EclipseSingle place to setup

SW BreakpointsHW BreakpointsHW WatchpointsCountersTrace Jobs

Dynamically determines resources available for useEnables EVENT capabilities for Watchpoints AND XDS560 Trace


Backup


Frequently Asked QuestionsHow are hardware program data breakpoints different from software breakpoints?

Software breakpoints are created by having the debugger (CCS) write a breakpoint instruction into the memory location. When the CPU hits that breakpoint instruction, it halts and the debugger places the instruction back for execution. Hardware breakpoints use on-chip comparators to compare a desired program address with the each fetched program address. When they match, the CPU is halted for debug purposes. Hardware breakpoint can work in ROM where as software breakpoint cannot.You can have an unlimited number of software breakpoints, but hardare breakpoints are limited by what the hardware is able to support.


ETB

Embedded Trace Buffer


ETB BasicsWhat is ETB?

ETB stands for “Embedded Trace Buffer”ETB is an on-chip memory buffer where the trace information is stored.

Where is ETB available?ETB is only available on certain devices.

How big is the ETB buffer?The size depends on the chip designer. Typically, it will be between 2-8K.

Is an XDS560 Trace Hardware unit needed to use the ETB?No

Can ETB be used concurrently with the XDS560 TraceYes, but there are limitations

A device with multiple cores has several operating options:All cores use their individual ETBOne user selected core outputs Trace to the XDS560 Trace, while others use their individual ETB. One user selected core outputs Trace to the XDS560 Trace.


Using ETB

Select the type of Trace receiver

The Trace control now shows ETB as the type of Trace Receiver

Additional Tabs for each core

unified breakpoint manager (ubm)processors.wiki.ti.com/images/0/0d/ubm-ext-02.pdf · 37 ti public...

Documents