|Non-Confidential||PDF version||ARM 100963_0200_00_en|
|Home > Using the CADI Interface Methods from a Debugger > Execution control > Breakpoints|
Breakpoints are an essential part of any debug mechanism. CADI offers several types of breakpoints that target different areas and levels of debugging. Each breakpoint can be individually configured to modify its behavior.
CADI provides predefined breakpoint types.
The breakpoint types supported by a target component are stored in a vector that contains
the features for the target (
CADITargetFeatures_t). CADI provides
comparison values to identify supported predefined types. These are named
CADI_TARGET_FEATURE_BPT_TypeExtension. To determine support,
perform a simple bitwise AND operation on the target features and the comparison
Do not confuse these enum data types:
CADI_BPT_TypeExtensionrepresents an index of the breakpoint type.
CADI_TARGET_FEATURE_BPT_TypeExtensionrepresents a breakpoint type vector for comparison with the CADI target features.
For both enum data types,
one of these:
CADIBptRequest_t owns several fields specific to certain breakpoint types. These fields are ignored for other types.
This sections gives an overview of the respective associations between fields in
CADIBptRequest_t and the various breakpoint types.
Table 3-1 Properties for each breakpoint by trigger type
||Program||Memory||Register||Instruction Step||Program Range||Exception|
If a field is not supported for the required breakpoint type,
its value must be left to the initial value assigned by the standard
CADI provides the dedicated data structure
CADIBptRequest_t that is used to set a breakpoint requested by the caller. It holds a description of the breakpoint and specifies its details.
These details include:
A breakpoint can be defined as enabled or as disabled and the state can be changed by a corresponding method call. Breakpoints can be configured to continue execution after being hit.
A breakpoint can be declared as temporary. Temporary breakpoints
can be easily cleared by calling
a special breakpoint ID (
This removes all of the breakpoints that have the temporary field
has set in
It is not required to set every field of the corresponding data structure for a breakpoint.
Properties that are not required for a certain breakpoint type are ignored by the target.
For example, the
triggerType field of
only used for setting a register breakpoint or a memory breakpoint.
Configuring conditional breakpoints requires special planning. There are two options, either:
Using formal conditions requires that the corresponding data
object owned by
CADIBptRequest_t is set. This
member, of type
the condition operator and a value to apply the operator to. The
format of this value is described by the operator, for example whether
it is a signed or unsigned value, and by the bitwidth specified
in the condition data type. The bitwidth includes the sign bit.
To set a new breakpoint, call
CADIBptSet(). It receives a breakpoint description of type
CADIBptRequest_t. On return, the caller receives a breakpoint ID of type
CADIBptNumber_t to use in subsequent breakpoint management calls.
After creating a new breakpoint/watchpoint with
the breakpoint/watchpoint is enabled/disabled depending on the value
of the Enabled field.
CADIBptConfigure() to change the
enable state for a breakpoint. Call
clear a breakpoint. After clearing a breakpoint, the corresponding
breakpoint number must not be referred to.
is reserved for clearing temporary breakpoints.
To read out descriptions of currently set breakpoints either:
CADIBptRead() to request
the description of a single breakpoint.
The breakpoint number must be available to identify the required breakpoint.
CADIBptGetList() to request
a list of breakpoints set in the target.
The method can be used, for example, to read out all breakpoint information of an existent simulation the caller is connected to. No specific knowledge about the target is required.
CADIBptGetList() method call scheme is that used by CADI accesses from
a debugger. To create a buffer with an appropriate size, either:
Use the number of supported breakpoints specified
in the target features (
Depending on the target implementation, this number might be very large.
An important use case for
breakpoint synchronization of several connected callers. This debugger
can regularly update the breakpoint list and show breakpoints that
have been set from another tool.
Yes only if