What's the difference between software and hardware breakpoints, and why does it matter on embedded?

A software breakpoint works by the debugger temporarily overwriting the instruction at the target address with a special trap instruction (BKPT on ARM); when execution reaches it, the core traps and halts, and to continue the debugger restores the original instruction, single-steps, and re-inserts the trap. This requires the code memory to be writable, and you can have effectively unlimited software breakpoints since they're just memory edits. A hardware breakpoint instead uses dedicated comparators in the chip's debug unit that continuously compare the program counter against a configured address and halt the core on a match, with no modification to the code, but there are only a small fixed number of these comparators (for example around six on a typical Cortex-M). This matters enormously on embedded because firmware normally executes from flash, and flash can't be casually rewritten instruction-by-instruction the way RAM can, so software breakpoints generally don't work for flash-resident code, you must use hardware breakpoints. The practical consequence is that you're limited to a handful of breakpoints at once, and once they're exhausted GDB reports it can't insert another ("no hardware breakpoint slots"), which surprises people used to unlimited breakpoints on a desktop where code runs from writable RAM and software breakpoints are plentiful. So on a flash-based MCU you ration the few hardware breakpoints; code copied to and run from RAM could use software breakpoints.