cortex-m-debuglisted

# Cortex-M Debug ## Overview Use this skill to debug ARM Cortex-M firmware systematically. Start by identifying the exact MCU, board state, debug probe, toolchain, and failure phase, then choose the safest inspection path before changing flash, option bytes, clocks, or startup code. ## When To Use Use this skill when: - The target is a Cortex-M MCU, such as Cortex-M0/M0+/M3/M4/M7/M23/M33/M55/M85. - The user mentions SWD, JTAG, J-Link, ST-Link, CMSIS-DAP, OpenOCD, pyOCD, GDB, or vendor IDE debug. - Firmware does not boot, cannot be flashed, stops in `Reset_Handler`, hits HardFault, or has no UART/log output. - The task involves vector tables, startup files, linker scripts, clocks, reset behavior, or fault registers. Do not use this skill when: - The target is Cortex-R (use `cortex-r5-debug`), embedded Linux, RISC-V, AVR, ESP8266, ESP32 Xtensa, or another non-Cortex-M architecture. - The user only needs application-level C code review with no target-specific debug context. - The request is to modify production firmware or security configuration before collecting baseline evidence. ## First Questions Ask for the minimum context needed: - MCU part number and board name. - Core family if known, such as Cortex-M0+, M4F, M7, or M33. - Current symptom: cannot connect, cannot flash, no boot, crash, hang, wrong peripheral behavior, or no logs. - Debug probe: J-Link, ST-Link, CMSIS-DAP, DAPLink, ULINK, or onboard probe. - Debug transport: SWD or JTAG. - Toolchain and workflow: