Data Breakpoint/Watchpoint

Data Breakpoints

Data Breakpoint (also known as watchpoint) is a simulation debug feature supported by Code Composer Studio that halts simulation when an access is made to a targeted memory location. The access could be from the CPU or from the DMA (if supported by the particular device configuration). Debug reads and writes to memory locations do not cause data breakpoints to trigger.

Supported Configurations

Currently available on C64xx CPU cycle accurate and C6416 Functional Simulators.

Data Breakpoint feature will figure as a menu option only if the above configurations are selected during Code Composer Studio Setup.

Usage

Load the program that you intend to debug using data breakpoints.

Follow the below steps to use this feature:-

To Create New Data Breakpoint

There are two ways to create a new data breakpoint:-

1.In the Debug tab of the CCS menu, click on Breakpoints, that opens up the Unified Breakpoint Manager window

OR

1.Directly click the Breakpoint Manager icon in the CCS window to open up the Unified Breakpoint Manager window.

2.Click on New, and a drop-down box appears that shows New Watchpoint as an option, if it is supported on this particular Simulator configuration.

3.Clicking on New Watchpoint, will prompt you to enter a Location and an event for the data Breakpoint. Enter a Location for the Data Breakpoint and an Event to break on.

• Location can be specified either as an absolute Memory address, or a symbol name. For e.g., to create a watchpoint on a global variable defined in a .c file as:- int IntegerA; specify the watchpoint Location as:- &IntegerA

• Following Events can be specified:
  • Memory Read
  • Memory Write
  • All Access Types

4. The above steps create a Data Breakpoint with some default settings as shown.

To an existing Data Breakpoint

1.Clicking on the Property Manager tab in the Breakpoint Manager window opens up the property window of the breakpoint that allows you to modify it

2.The properties are displayed with their current values along and clicking on them will display a small description at the bottom. Modify the properties as appropriate.

3.After making all possible modifications, click on Submit Changes to have the properties take effect on the Simulator target.

4.If the properties are such that the particular breakpoint cannot be enabled on the simulator target, a message window pops up and the data breakpoint shows as disabled in the Unified Breakpoint Manager.

In this case, modify it suitably, save it and click on the Enable click box in the Property Window or in the Unified Breakpoint Manager.

Options are available in the Unified Breakpoint Manager to Disable or Delete the breakpoints as required.

On trigger

When a breakpoint is triggered, the execution Halts.

It shows up in the Unified Breakpoint Manager window as a Red indicator next to the triggered breakpoint.

Also, in the properties of the breakpoint in the Property window, it will indicate which “Initiator” caused the breakpoint (in Gray).

Misc info

1. Data breakpoints can be set on addresses of local variables on stack once they are within scope. However, on a Reset Reload of the program, these addresses are lost, hence the data breakpoint needs to be set again.

2. Multiple breakpoints with overlapping address ranges can be set on the simulator target.

3. Setting of data breakpoints, will affect simulation speed. But if all breakpoints are disabled, simulation speed should not be affected.

4. The default setting of the breakpoint may be not the desired setting. Make sure you modify the properties of the breakpoint and "Submit Changes" for it to have effect on the target.

5.Conditional breakpoints can be set, by specifying condition in the Property Window using a suitable operator, and a constant value to compare with the contents of targeted memory location

6. There is a restriction on the length of the breakpoint, in case you set Conditional Breakpoints.

Data Breakpoint/Watchpoint on CCSv4

Data Breakpoint/Watchpoint is supported on Code_Composer_Studio_v4. Check the recording of watchpoint for usage - link

What if I need to use this on Hardware?

See: Advanced Event Triggering and Unified Breakpoint Manager

Difference between Software and Hardware Breakpoints

As the names might indicate, a hardware breakpoint is implemented in hardware and a software breakpoint is implemented in software. But what does that mean to the user? When should they use a hardware breakpoint? A software breakpoint? What are the advantages and disadvantages of each?

Software Breakpoints

When a software breakpoint is set, the emulation driver reads the instruction at that location, removes the first byte of the instruction, and replaces it with a software breakpoint op-code. This software breakpoint op-code is what tells the CPU to halt at this instruction. The byte that was removed from the instruction is then placed into a breakpoint table where it is associated with the address that it was removed from. The driver will then read back the instruction to be sure that the breakpoint has been set properly.

When a RUN is issued from the Code Composer Studio, the CPU is started running. Periodically, CCS polls the target for status to see if it has halted. As long as the CPU continues to run, CCS does nothing except continue polling. If CCS determines that the CPU has halted, it first queries the CPU to see how it halted. (i.e. software breakpoint, hardware breakpoint, embedded breakpoint, user halt) If the CPU returns a status of “Halted by Software Breakpoint”, the driver reads the PC, looks up the breakpoint in the breakpoint table, and replaces the breakpoint op-code with the byte from the actual instruction. (The user should never see the breakpoint op-code in the disassembly window.) If the breakpoint remains enabled after the instruction has been executed by either a run or a step, the first byte of the instruction gets replaced again by the software breakpoint op-code.

Since software breakpoints are implemented in software, their number is virtually unlimited. So long as there is memory on the host to store the breakpoint information, a software breakpoint can be implemented. However, software breakpoints can only be used in RAM. If the target memory cannot be written to, then the breakpoint op-code cannot be inserted. If it’s necessary to set a breakpoint in ROM, Hardware Breakpoints should be used.

Hardware Breakpoints

As noted earlier, Hardware Breakpoints are implemented in the Advanced Event Triggering hardware. This means that there are physical hardware units located on chip to enable hardware breakpoints. The Breakpoint portion of these analysis units is basically a set of address comparators. The user can program the comparators to watch for a specific address on the Program Address bus. When that address appears on the bus, the breakpoint triggers and halts the CPU.

While the CPU is running, CCS simply continues to poll the target for status until it sees a HALT. If a hardware breakpoint is encountered, CCS first checks why the target is halted. A Hardware Break status tells CCS that it has to do nothing in the way of checking the breakpoint table.

The advantage of hardware breakpoints that they can be used in any type of memory. A hardware breakpoint works as well in RAM as in ROM. However, the limitation of hardware breakpoints is that there is a very small number of them. Typical TI targets usually have 2 or 4 hardware breakpoints on chip. Additionally, these analysis units can be used for more than just hardware breakpoints. They also can have event counters and timers on them. If a counter or timer is being used, that’s one less unit that’s available for a hardware breakpoint. More details can be found on the Advanced Event Triggering topic.

Embedded Breakpoints

An embedded breakpoint is a breakpoint that is implemented in target code. Not all targets necessarily have embedded breakpoints. On the C55x, the embedded breakpoint is implemented with the estop_1() assembly instruction. Embedded breakpoints are really software breakpoints, but they are implemented in the target application, and the debugger doesn’t have to do anything with the breakpoint table.

Embedded breakpoints only work if an emulator and debugger are connected to an application. This keeps code in the field from inadvertently halting if an embedded breakpoint has been implemented in code. If a debugger is not connected, the embedded breakpoint is handled as a NOP (No Operation). There are details about these in the software breakpoint topic.

	Hardware Breakpoint	Software Breakpoint
Number Available	Very Few (usually 2 or 4)	Virtually Unlimited
Target Memory	Any	Only RAM

Code Composer Studio will automatically take care of deciding between a hardware and a software breakpoint if the memory is mapped correctly. If no memory map is used, CCS will only try to set a software breakpoint. If the memory is not RAM, the Breakpoint set will fail.

FAQ

Q: Can I use this to break on a data address with a specific data value?

A: Yes.

Related

• Watchpoints for C28x in CCS 4
• Advanced Event Triggering
• AETLib
• General description of Breakpoint