How can you accidentally "lock yourself out" of debugging, and how do you avoid/recover?

A few ways, all involving the firmware or chip configuration cutting off the debug access the probe needs. The most direct is reconfiguring the SWD/JTAG pins as application GPIO (or selecting JTAG-disabled modes), once your firmware does that at startup, the debugger loses the lines and can't halt the running core. Similarly, entering certain low-power/sleep modes can gate the debug clock so the probe can't communicate while the core is asleep. And deliberately, enabling readout protection (RDP), a security feature that prevents reading flash/RAM over the debug port, blocks debugging entirely; at higher protection levels it can disable the debug interface, which is intended for production to protect IP and secrets but is painful if set during development. The classic recovery for the "firmware disables debug immediately" case is connect-under-reset: the probe asserts reset, attaches while the core is held in reset (before the offending startup code runs), and halts it, letting you reflash benign firmware. For readout protection, you typically must perform a full mass-erase to drop the protection level (which wipes the flash, by design), and the highest RDP levels may be irreversible, permanently preventing debug, so you must be very deliberate before setting them. Avoidance: don't repurpose the debug pins (or do it conditionally so a debug build keeps them), keep a recovery path (a boot pin or a delay before disabling debug), and never set the strongest readout protection until production and only when you're certain. The throughline is that debug access is something the chip can be configured to revoke, so you protect that access during development and only lock it down intentionally for shipping.