Why is my program affected when inserting a hardware breakpoint?

When I start debugging my program and insert a hardware breakpoint while the system is running, this causes a CPU halt that affects the behavior of the program. Why is my program affected and how to work around this?

The debug toolchain used by netX Studio CDT includes the GNU Debugger (GDB) which is responsible for most of the tasks required for debugging - stopping, continuing, inserting/removing breakpoints, etc. When a breakpoint is inserted in netX Studio, for example by double-clicking in front of a line of source code, this is translated into the correct GDB command for adding a breakpoint. GDB will only accept such a command when the program is not running. If the program is running, netX Studio will first send a command to interrupt the program (halt the CPU), insert the breakpoint and then resume the program immediately. This temporary halt of the CPU is not obvious and may not be observed in the GUI, but may affect the behavior of the running program.

How to insert breakpoints unobtrusively?

The easiest way to insert breakpoints unobtrusively, i.e. to avoid the temporary CPU halt, is to insert the breakpoints before you start debugging (before the program is started). What will happen is that the CPU will be reset and halted at the beginning of the program (the first instruction), then the breakpoints will be inserted and the program resumed. Because the breakpoints are already inserted when the program is started, they will not affect its behavior until they are hit.

The netX 90 CoreSight debug and  trace infrastructure supports memory access without halting the CPU. Why is the temporary CPU halt required to insert a hardware breakpoint on the netX 90?

The temporary CPU halt is not required to insert a hardware breakpoint on the netX 90, it is rather a limitation of the GNU Debugger (GDB). An advanced user may go around this limitation by going around GDB and send the lower-level breakpoint commands directly to OpenOCD.