| |||
| Home > Setting Breakpoints > Setting a simple breakpoint > Effects of setting a breakpoint | |||
Setting a breakpoint updates the Break/Tracepoints view, if it is visible, and the Output view shows the CLI command used to set the breakpoint:
If you set a breakpoint in a source file tab, the command has the following format:
binstr \MODULE\#line_number:char_pos
For example, binstr \DHRY_1\#158:3.
If you set a breakpoint in the Disassembly tab, the command has the following format:
binstr address
For example, binstr 0x000084D0.
The type of breakpoint set, either software or hardware, is determined by the memory type:
Setting breakpoints in source-level view inserts a software instruction breakpoint by default. This is set using a BREAKINSTRUCTION command. RealView Debugger attempts to set a software breakpoint if the code is in RAM.
If your code is in ROM or Flash, RealView Debugger sets a hardware breakpoint if one is available. This is set using a BREAKEXECUTION command. An error message is displayed if no such breakpoint is available.
If you attempt to set a software breakpoint at an
address that you know is in RAM, and RealView Debugger unexpectedly
sets a hardware breakpoint or fails, then check the Memory
Map tab to see if memory mapping is enabled. If memory
mapping is enabled, make sure the memory area of interest is defined
as RAM. RealView Debugger always sets a hardware breakpoint in a
memory area that is marked as Default Mapping.
In some instances, RealView Debugger fails to set a software
breakpoint. This situation can arise when memory mapping is disabled,
because RealView Debugger attempts to treat all memory as RAM by
default. You can use the failover qualifier with
the BREAKINSTRUCTION command to force the software
breakpoint to be converted to a hardware breakpoint.
the following in the RealView Debugger Command Line Reference Guide:
Alphabetical command reference for details of the BREAKEXECUTION and BREAKINSTRUCTION commands.