STM32N647: OpenOCD halt/debug fails with UNDEFINED while CubeIDE works

[songshuaisong]

Dear ST Support Team,

I am reporting a debug issue on STM32N647 where debugging works correctly in STM32CubeIDE, but fails when using OpenOCD (ST fork) with ST-LINK.

Summary
On STM32N647 (Cortex-M55, TrustZone), OpenOCD is able to connect to the target and enumerate the core, but any attempt to halt/pause/step the CPU results in an UNDEFINED debug reason. The same hardware, firmware, and debug authentication state work correctly when debugging with STM32CubeIDE using ST-LINK.

Hardware

• MCU: STM32N647X0HxQ
• Debug probe: ST-LINK (V2J46S7)
• Target voltage: ~3.3 V

Software / Tools

• STM32CubeIDE: Debug works normally (halt/step/breakpoints OK)
• ST-LINK Server: API v3, FW 2.1.1
• OpenOCD: 0.12.0+dev-00623-g0ba753ca7 (STMicroelectronics fork)
• VS Code + cortex-debug 1.12.1

Project / Boot Mode

• Boot mode: Internal SRAM boot
• Program under debug: FSBL
• Debug mode: load and run
• Debug Authentication: OPEN (confirmed, since CubeIDE debugging works)

OpenOCD Behavior

OpenOCD connects successfully:

• SWD/DAP connection OK
• Cortex-M55 detected
• Registers and memory can be read

However, when GDB connects or when “Pause” is issued:

halted due to undefined
undefined debug reason 8 (UNDEFINED)

VS Code / cortex-debug then reports:

Received readMemory request while busy (SCB fault registers)
Returning dummy thread-id / stack frame to workaround pause button not working

Halt, step, and breakpoints never work. Changing reset configuration, SWD speed, or OpenOCD options does not change the behavior.

Questions

• Is OpenOCD (ST fork) officially expected to support full halt/step debugging on STM32N647?
• Is there a known limitation or missing Secure Debug / TrustZone handling in OpenOCD for STM32N6?
• Is there a recommended OpenOCD configuration, patch, or restriction note for STM32N647?

I can provide full OpenOCD logs, CubeIDE screenshots, and configuration files if needed.