User`s manual

3-8 Suite56 DSP Tools User’s Manual Motorola
Source-Level Debugging in C
3.2.2 About Software Breakpoints in a C Program
This section discusses software breakpoints in debugging a C program. For details about
hardware breakpoints, see the family reference manual (e.g., Motorola DSP56600 Family
Manual) and the device manual (e.g., Motorola DSP56602 User’s Manual), particularly
chapters about the OnCE module and programming practices, for your target device.
Section 4.3, "Finding Well Hidden Bugs," on page 4-7, also offers guidance about
hardware breakpoints.
Software breakpoints are used to specify that a particular action be taken whenever a
certain condition is met. In this way, software breakpoints are very similar to hardware
breakpoints. However, software breakpoints are more limited than hardware breakpoints
in that:
• software breakpoints can only be set on the first word of an instruction (they cannot
be set to detect the access of registers or data memory)
• software breakpoints must be set in RAM (they cannot be set in ROM)
Despite the above limitations, it is recommended that you use software breakpoints
instead of hardware breakpoints whenever possible. Why? Because, effectively only one
hardware breakpoint can be set at a time whereas a virtually unlimited number of software
breakpoints can be set.
Software breakpoints can have several different effects. How you set the breakpoint
depends in part on the effects that you want to achieve:
• A breakpoint causes execution of a program to halt and control of execution to
return to the user. This kind of breakpoint is known as a halt breakpoint.
• In addition to halting, a breakpoint can also increment a counter so you can see how
often a piece of code has been executed.
• In addition to halting, a breakpoint can also write to a Session window, so you can
see whether a piece of code has been executed.
• A breakpoint may also be set in the program data so that as specific memory
locations or registers are accessed, the break occurs. Section 4.3, "Finding Well
Hidden Bugs," on page 4-7, explains more about those breakpoints.
Regardless of how you set them, breakpoints are numbered, so that you can refer to them
as you watch them, disable them (i.e., turn them off), reenable them (i.e., turn them on
again), or direct execution to continue until it reaches a particular breakpoint. Moreover,
you can set more than one breakpoint at the same place to achieve more than one effect
(e.g., concurrently halt, increment a counter, write to the Session window, and execute a
user-defined routine).