| Copyright © 2005, 2006 ARM Limited. All rights reserved. | ARM DUI 0281C |
| Non-Confidential | |
 PDF version | |
| Home > Working with Breakpoints > Breakpoints in RealView Debugger > Breakpoint types |
| |||
| Home > Working with Breakpoints > Breakpoints in RealView Debugger > Breakpoint types | |||
RealView Debugger enables you to use different types of breakpoint when you are debugging your image, described in:
The type of breakpoint you can set depends on the:
memory map, if enabled
qualifiers assigned to the breakpoint
hardware support provided by your target processor
target vehicle used to maintain the connection.
RealView Debugger uses breakpoints to temporarily halt execution as you step through your application. For more details about stepping through code, see Using execution controls.
RealView Debugger enables you to set software or hardware breakpoints, depending on the target and the chosen memory location (see Breakpoints and memory map locations):
These breakpoints are controlled by RealView Debugger directly. When you set a software breakpoint RealView Debugger modifies the executable instructions held in RAM. Therefore, you can only set software breakpoints for code stored in RAM.
You can set as many software breakpoints as you require.
If you enable a Memory Management Unit (MMU) that is configured to set the region of memory containing a breakpoint to read-only, then the breakpoint cannot be removed. In this case, you must make sure you clear the breakpoints before enabling the MMU.
Hardware breakpoints use advanced hardware support on your target processor, or as implemented by your simulator software. The complexity and number of breakpoints you can set depends on:
hardware support provided by your target processor
target vehicle used to maintain the connection.
Hardware breakpoints are controlled by the EmbeddedICE® module of your target, which can be physical hardware or a software model.
RealView Debugger reserves one breakpoint unit for internal use and so this might not be available to you. You are warned if you try to set a hardware breakpoint when the limit is reached.
All ARM® architecture-based processors provide basic hardware breakpoint support. This enables you to test address-specific data values.
Where advanced hardware support is available on your target processor, you can set more complex hardware breakpoints. These breakpoints might be data-dependent or take advantage of range functionality. For example, some processors enable you to chain two breakpoints together, so that the break triggers only when the conditions of both breakpoints are met.
Check your hardware characteristics, and your vendor-supplied documentation, to determine the level of support available for hardware breakpoints. Also, see Viewing your hardware breakpoint support.
Software and hardware breakpoints are classified depending on the qualifiers that you assign to the breakpoint:
A breakpoint is unconditional when no condition qualifier is assigned to the breakpoint.
You can set an unconditional breakpoint that has no condition qualifiers and no actions assigned, and without explicitly choosing whether it is a software or hardware breakpoint. This is called a default breakpoint, and either RealView Debugger or your target hardware determines what kind of breakpoint is set. For a default breakpoint, the program always stops if execution reaches a specified location (see Setting default breakpoints).
You can assign one or more actions to an unconditional breakpoint. When the breakpoint is triggered, the specified action is performed (see Setting unconditional breakpoints explicitly).
A breakpoint is conditional when a condition qualifier is assigned to the breakpoint. The conditions that must be satisfied can be defined based on data values, the result of a macro, or on counters. See Controlling the behavior of breakpoints for details on how the order of conditional qualifiers affects the behavior of a breakpoint.
The program stops if execution reaches a specified location and one or more of the predefined conditions are met (see Setting conditional breakpoints).
Although hardware breakpoints can have conditions controlled in hardware, they are not conditional in RealView Debugger. Only breakpoints that have condition qualifiers assigned are identified as conditional by RealView Debugger.
A default breakpoint is set by RealView Debugger when you do not explicitly choose a specific type of breakpoint. For example, a default breakpoint is set when you double-click in the margin of the Dsm tab or a source code tab of the File Editor pane.
A default breakpoint does not have any condition qualifiers or actions, and so is always an unconditional breakpoint. However, the chosen memory location where you set the breakpoint determines whether it is a software or hardware breakpoint (see Breakpoints and memory map locations).
The command used by RealView Debugger to set a default breakpoint depends on the type:
To set a default
software breakpoint, RealView Debugger uses the BREAKINSTRUCTION command.
For example, to set a default breakpoint at the RAM address 0x00008008, RealView Debugger issues
the command:
binstr (I A)0x00008008
To set a default hardware breakpoint, RealView Debugger uses
the BREAKEXECUTION command. For example, if you
set a default breakpoint at the Integrator™/AP
Flash address 0x24000008, RealView Debugger issues the command:
bexec (I A)0x24000008
In some instances, RealView Debugger might attempt to set a software
breakpoint, but your target hardware might set a hardware breakpoint
instead. In this case, the breakpoint information in the Break/Tracepoints
pane might show Exec in the breakpoint title,
but the bi command (BREAKINSTRUCTION)
for the command used to set the breakpoint.
If you attempt to set a default breakpoint in a data or literals area of code within the Dsm tab, the breakpoint is set and RealView Debugger issues the warning:
Warning: Breakpoint being set in data/literals of
code.
For more details about these commands, see the RealView Developer Kit v2.2 Command Line Reference.
For detailed instructions on setting default breakpoints, see Setting default breakpoints.
Default breakpoints are not added to the breakpoint history (see Setting breakpoints from saved lists).
When a breakpoint triggers and program execution stops, RealView Debugger records this by displaying messages that identify the type and location of the breakpoint, for example:
Stopped at 0x00008498 due to SW Instruction Breakpoint
Stopped at 0x00008498: DHRY_1\main Line 153
If you specify that execution is to continue after the breakpoint is triggered, then these messages are not displayed.
If you want program execution to continue when a breakpoint is triggered, and still be informed when this occurs, then:
Assign a macro to the breakpoint that outputs appropriate messages and returns a value of zero (True).
Assign the continue command qualifier
to the breakpoint.
See Controlling the behavior of breakpoints for more details.
| Copyright © 2005, 2006 ARM Limited. All rights reserved. | ARM DUI 0281C |
| Non-Confidential | |
| PDF version | |
| Home > Working with Breakpoints > Breakpoints in RealView Debugger > Breakpoint types |