8.2.1 Software Breakpoints

The debugWIRE OCD is drastically scaled down when compared to the Atmel megaAVR (JTAG) OCD. This means that it does not have any program counter breakpoint comparators available to the user for debugging purposes. One such comparator does exist for purposes of run-to-cursor and single-step operations, but user breakpoints are not supported in the hardware.

Instead, the debugger must make use of the Atmel AVR BREAK instruction. This instruction can be placed in FLASH, and when loaded for execution it will cause the AVR CPU to enter stopped mode. To support breakpoints during debugging, the debugger must insert a BREAK instruction into FLASH at the point at which the users requests a breakpoint. The original instruction must be cached for later replacement. When single stepping over a BREAK instruction, the debugger has to execute the original cached instruction in order to preserve program behavior. In extreme cases, the BREAK has to be removed from FLASH and replaced later. All these scenarios can cause apparent delays when single stepping from breakpoints, which will be exacerbated when the target clock frequency is very low.

It is thus recommended to observe the following guidelines, where possible:

• Always run the target at as high frequency as possible during debugging. The debugWIRE physical interface is clocked from the target clock.
• Try to minimize on the number of breakpoint additions and removals, as each one require a FLASH page to be replaced on the target
• Try to add or remove a small number of breakpoints at a time, to minimize the number of FLASH page write operations
• If possible, avoid placing breakpoints on double-word instructions