I'm debugging an STM32N647 on a custom board and running into a strange issue: the target silently drops the debug connection every time a breakpoint is hit or a single-step lands inside HAL_Delay(). Environment - MCU: STM32N647X0HXQ (Cortex-M55) - Debugger: ST-Link V2 - Debug mode: LRUN (code in AXI SRAM 0x34000000, running with XSPI/Flash boot) - Toolchain: VSCode + Cortex-Debug + ST-Link GDB Server - SWD freq: tried 400 kHz / 1 MHz / 4 MHz — same result - D-Cache: disabled (SCB_DisableDCache()) - Optimization: -O0 Symptoms 1. Download & run works fine — the firmware executes normally. 2. Setting a breakpoint → when the breakpoint hits, VSCode shows "Target disconnected" / "Lost debug connection". 3. Single-stepping into HAL_Delay() causes the same disconnect. 4. Reset via ST-Link sometimes recovers, sometimes requires power cycle. What I've checked / tried - Power supply is stable (measured with scope). - BOOT0/BOOT1 jumpers are correct for LRUN mode. - Tried lowering SWD frequency — no improvement. - Disabled D-Cache — no change. - Tried with and without `SystemIsolation_Config()` — same issue. - ST-Link firmware is up to date. Questions 1. Is there any known errata for STM32N6 where breakpoints or halting debug cause a hard lockup or debug domain reset? 2. Could the NPU / GPU clock domains be interfering with debug domain when the core halts? 3. Any special debug-related registers or options bytes on N6 that need to be configured to keep the debug connection alive during halt? 4. Has anyone successfully used VSCode + Cortex-Debug with STM32N6, or is STM32CubeIDE / STM32CubeDebug the only stable option? Any pointers would be greatly appreciated! Thanks.
