[TickleSteve]

yeah, processors such as the ARM cortex-M series have built in debug features such as ~8 breakpoint registers that trigger a change in processor state when they match a code or data access address.

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.

[sigill]

Yes. And these software breakpoints are written into flash. This is why they're very slow - and why they wear down your flash.

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.

[repiret]

>> processors such as the ARM cortex-M series have built in debug features such as ~8 breakpoint registers

> 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.

[3chelon]

Is "wearing down the flash" really still an issue? Hard drives these days are flash-based - surely the read/write cycles modern flash memory can withstand are high enough to manage a few breakpoints?

[repiret]

Yes. In an embedded environment, its not uncommon to:

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.

[vardump]

> NAND flash is used, with 100,000 to 1,000,000 write cycles

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.

[3chelon]

Thanks for that - I feel much more knowledgeable about flash memory now. I'd never even heard of NOR flash (although I understand what a NOR gate is).

One question though: why is NAND flash so much more resilient?