I use AVR Studio 4, JTAGIce MkII-CN, gcc for debugging. It works generally OK but sometimes happens after some unspecific interruption (reset, power cycle, etc.) that AVR Studio breakpoint remains transformed into BREAK instruction and it causes the program always breaks at this instruction and cannot go over any way (visible in Disassembler window).
I cannot investigate where the instruction is written because it survives even reboot of MCU, AVR Studio and JTAGICE debugger, the BREAK still persist there. Only reflashing MCU helps and I can go on.
Does on-chip-debugging-engine modifies flash and remembers original instruction? I'm not sure if it works beyond debugging because BREAK is probably ignored and missing original instruction is hardly detectable.
Note: I'm not sure just now what was result of reading flash and verifying against original.
Best Answer
Yes and no. Some AVR controllers have a limited number (3?) of "hardware" breakpoints which can be set dynamically at runtime and will not live beyond the end of the debugging session (reset, power down, ...).
However, if/when you have set more breakpoints than are available via these "hardware" ones, or if you have a controller without any of those, the debugger software will indeed replace the instructions where your breakpoint is set with "BREAK" instructions and will restore them later. No wonder that a sudden interruption of the debugging session will leave the controller somewhat unusable until you re-flash it, overwriting the artificially introduced "BREAK"s.
This mechanism is also mentioned in the AVR docs, where they state that this type of debugging may pose additional stress on the flash memory: Each time one such breakpoint is set or removed or hit, a part of the flash will be re-programmed in the background by the debugger software.
See also here, for example.