Depending on implementation options, most ARM processors provide dedicated hardware to enter debug state when a predetermined event occurs.
Most recent ARM processors provide hardware for trapping exceptions. When enabled, the effect is similar to placing a breakpoint on the selected vector table entry. This is called vector catch. However:
Some ARM processors, such as ARM7, do not provide vector catch hardware. For these processors, debug hardware simulates vector catch using instruction breakpoints.
For Cortex-M3, this is equivalent to putting a breakpoint at the target of the vector. Cortex-M3 has a restricted set of vector catches available.
If the exception vectors are in ROM, debug hardware must use hardware breakpoints to simulate vector catch. This reduces the number of resources available for other purposes, if the processor does not have vector catch support.
When the debug hardware simulates vector catch on earlier ARM processors that do not have vector catch support, it uses a software breakpoint when the vector table is located in RAM.
You must take care when debugging through a system reset. Some hardware targets alter the memory map after reset, so the location of in physical memory containing software breakpoint might not be in the correct reset position. The following warning is output to the your debugger console if debug hardware simulates reset vector catch using an instruction breakpoint:
Warning: A software breakpoint is being used to simulate reset vector catch. This may fail to be hit if the memory is remapped when a reset occurs.
The exact behavior of the ARM vector catch hardware depends on the processor. ARM9 processors enter debug state only when the specified exception occurs. Other processors, such as ARM11 or older processors that use a breakpoint, enter debug state whenever the instruction at the exception vector is executed, regardless of whether the exception occurs or not.
See also
PDF version