The breakpoint registers are accessed via JTAG/SWD using your j-link/FET/whatever.
Quite often, when you're debugging embedded systems, you run out of "hardware" breakpoints and have to resort to software-style breakpoints described in the article.
The situation is kinda OK when you don't often change breakpoints and your CPU has an instruction register writable by the debug probe via JTAG/SWD/etc. Upon stepping or continuing from a breakpoint, the debugger will write the actual instruction at the breakpoint into the instruction register and tell the CPU "run again, but don't load the instruction from memory as I have already loaded it into your instruction register.".
Another option is to emulate the effects of the instruction in the debugger and write the results back into registers/RAM/I/O. This is not always possible.
If you don't have the options above, your flash will wear down quickly, as stepping away or continuing from a breakpoint entails writing the actual instruction back, stepping, then writing the breakpoint again.
> And these software breakpoints are written into flash.
The GP is referring to the eight FPB hardware breakpoints, which do not need to be written to flash. Most Cortex-M have an additional four hardware breakpoints from the DWT. You can get a lot done with 12 breakpoints before you need to start writing things to flash.
More generally, as long as the debug interface allows you to run with interrupts disabled and has at least one HWBP, you can single-step without writing SWBP to memory.
1. Have a NOR flash part rated for 10,000 or fewer cycles. 2. Have no facility for remapping bad sectors. 3. Have no wear-leveling mechanism.
All of this is reasonable for a product that will only be flashed once during manufacturing (and there are a lot of those products) or a product that will receive a firmware update a single-digit number of times in its lifetime.
In contrast to an SSD, where:
1. NAND flash is used, with 100,000 to 1,000,000 write cycles 2. The drive can transparently remap bad sectors, so flash can start to fail before anybody notices. 3. The drive performs automatic wear leveling - if you try to write a single sector a million times, the drive will do something closer to writing a million sectors once.
Damn, where can you get that kind of flash chips with even 100k cycles endurance? I'd like to place a large order. 64 Gbit chip, please.
1000-3000 P/E cycles is typical endurance for MLC NAND flash, not 100-1000k. SLC chips would fare better, but larger ones are too expensive for typical applications.
One question though: why is NAND flash so much more resilient?
For AVR specifically, have a look at e.g. https://github.com/raimue/avarice/blob/master/src/jtagbp.cc (just random find on github, likely not the official repository).
This is, by the way, also possible on a typical PC (as in "personal computer" not program counter), also x86/64 has debug registers.
http://www.codeproject.com/Articles/28071/Toggle-hardware-da...
...and very likely also on ARM, m68k, MIPS, Sparc, PPC, ... I just didn't look it up.