5.10.5. Using breakpoints in RealView Debugger

Breakpoints are specified locations where execution stops. A breakpoint is triggered either by:

Breakpoints enable you to suspend program execution when the program accesses specific memory locations, variables, or functions. You can define conditions that are tested or qualify the breakpoint to define when execution stops. This section describes:

Breakpoint types

RealView Debugger enables you to use different types of breakpoint when you are debugging your image. RealView Debugger enables you to set software or hardware breakpoints:

Software

These breakpoints are controlled by RealView Debugger directly. Because software breakpoints require that RealView Debugger change executable instructions, you can only set software breakpoints for code stored in RAM.

You can set many software breakpoints.

Hardware

These breakpoints are controlled by the EmbeddedICE® module of your hardware. The complexity and number of breakpoints you can set depends on the hardware support provided by your debug target.

Note

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, or as implemented by your simulator software (for example RVISS), 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.

Note

For RVISS, only the RealView Connection Broker interface supports hardware breakpoints.

Software and hardware breakpoints are classified depending on the qualifiers that you assign to the breakpoint:

Unconditional

A breakpoint is unconditional when no condition qualifier is assigned to the breakpoint. However, you can:

  • Assign one or more actions to an unconditional breakpoint. When the breakpoint is triggered, the specified action is performed. For more details, see the chapter that describes working with breakpoints in the RealView Debugger v1.8 User Guide.

  • Choose whether it is a software or hardware breakpoint, depending on the memory region (see Breakpoints and memory locations).

For an unconditional breakpoint, the program always stops if execution reaches a specified location.

Default breakpoints

You can set an unconditional breakpoint that has no actions assigned to it, 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 whether a software or hardware breakpoint is set (see Setting default breakpoints).

Conditional

A breakpoint is conditional when a condition qualifier is assigned to the breakpoint that tests for a specific condition. The conditions that must be satisfied can be defined based on data values or on counters.

The program stops if execution reaches a specified location and one or more of the predefined conditions are met (see Setting conditional breakpoints).

Breakpoints and memory locations

By default, RealView Debugger always sets a software breakpoint in RAM. If you attempt to set a software breakpoint at a Flash or ROM address, RealView Debugger sets a hardware breakpoint instead, and warns you that this has happened:

Warning: Failed to set Software Break - used Hardware Break instead (read-only memory?).

Halted System Debug and Running System Debug

RealView Debugger supports different debugging modes:

Halted System Debug

Halted System Debug (HSD) means that you can only debug a target when it is not running. This means that you must stop your debug target before carrying out any analysis of your system.

HSD is always available as part of the RealView Debugger base product.

Running System Debug

Running System Debug (RSD) means that you can debug a target when it is running. This means that you do not have to stop your debug target before carrying out any analysis of your system.

RSD is only available where supported by your debug target. You must also have one or more RealView Debugger RTOS extensions installed and are not provided as part of the base product.

Where RSD is supported, RealView Debugger enables you to switch seamlessly between RSD and HSD mode using Code window controls or CLI commands. For full details on using RTOS extensions and running in RSD mode, see the chapter that describes RTOS support in RealView Debugger v1.8 Extensions User Guide.

Copyright © 2002-2005 ARM Limited. All rights reserved.ARM DUI 0181G
Non-Confidential