Open the project Breakpoints.X

Click on the Open Project button and open the Breakpoints.X project. If you have not downloaded the files, you can find them in the Exercise Files section of this page.

Open the Watches window

Display the Watches tab by selecting it from the menu: Window > Debugging > Watches.

Open the saved Watches window

Click on the Gem and Folder button in the window’s sidebar.

In the file dialog that opens, select the ..\Breakpoints.X\Breakpoints.xwatch file and click the Select button.

Open the Action Items window

Display the Action Items tab by selecting from the menu: Window > Action Items. When done, you should have at least three tabs open at the bottom right of the Integrated Development Environment (IDE). If for some reason the Output tab isn’t visible, it should open automatically when a project is built.

Set a line breakpoint

In the Action Items window, double-click on [Exercise 1]. This will take you to a comment immediately above the line of code we are interested in. In the glyph margin (grey bar on left of editor with line numbers), left-click on the line number next to the code LATA = 0;.

Debug the project

This will build the project in debug mode, program the target through the REAL ICE/ICD 3, and run the program. The debugger should pause the program when the breakpoint is hit. You should notice that the program counter (indicated by a green arrow in the glyph margin) points to the next line of code. This is an example of skid. Let’s take a look at what is happening at the machine level.

Open the Disassembly window

From the menu, select: Window > Debugging > Disassembly.

Here we can see exactly how far the skid took us. The line we set the breakpoint on consists of two assembly instructions (un-optimized). When working with a hardware debugger, the instruction where the breakpoint is set must complete execution and the one instruction in the pipeline must also be executed completely so that the program can branch into the debug kernel and give you control from the IDE. Therefore, the program counter sits two instructions after the break, ready to execute the line it points to.

End the debug session

Click on the Finish Debugger Session button:

Enable software breakpoints

Go to the Dashboard tab. If it is already open, it may be at the top left along with the Projects tab, or the bottom left by the Navigator tab. If it is not open, select from the menu: Window > Dashboard. On the left side of this window, there is a sidebar with several icons. Click on the third one down to toggle software breakpoints on. After doing so, you should see them enabled under the Debug Resources section of the Dashboard.

Debug the project

Everything should work as it did in Step 6 until you hit the breakpoint. Before the code halts, you should see the following in the REAL ICE tab:
Setting software breakpoints…….
Setting software breakpoints complete.

Target halted due to Software Breakpoint in user code
You should also notice that the green arrow representing the program counter is sitting right on top of the red square representing the breakpoint. It looks as if there is no skid. To verify this, let’s take a look at the machine view of things.

Open the Disassembly window

From the menu, select: Window > Debugging > Disassembly.

Here we can see that there is no skid whatsoever. The program counter is sitting on the very first instruction of the assembly code that implements LATA = 0;.

Switch to the simulator

Debug the project

Clean up for the next exercise