How to allow debugger to attach on STM32N6 when booting from FLASH

[AMurz.1]

Hi,

I've flashed an application in the STM32N6570-DK board using a FSBL and Appli projects. The application boots fine.

But when the application is running, I can't attach to it using the debugger and ST-Link.

I've tried to open the debug port of the STM32N6 by writing 0xB4 to the BSEC_AP_UNLOCK register, but it still fails.

The error I get is:

STMicroelectronics ST-LINK GDB server. Version 7.11.0
Copyright (c) 2025, STMicroelectronics. All rights reserved.

Starting server with the following options:
 Persistent Mode : Disabled
 Logging Level : 1
 Listen Port Number : 61234
 Status Refresh Delay : 15s
 Verbose Mode : Disabled
 SWD Debug : Enabled

Target unknown error 32

Error in initializing ST-LINK device.
Reason: Unknown. Please check power and cabling to target.

Using STM32CubeProgrammer, I get this error on Access Port 1 with Hot Plug mode:

But I've not configured anything: I've not blown any OTP fuse, nor changed any Option bytes. And I'm not using a secure bootloader, I have just the generated FSBL from STM32CubeMX which loads the application from flash to RAM using ExtMemManager.

I'm assuming the DEV_MODE is doing something to open the debug access before doing it's busy loop waiting for a debugger to attach. 

 

As a workaround, I can get the debugger to work if I do this:

• Switch to DEV_MODE
• Power-up the board
• Switch to FLASH boot mode without power-cycling
• Press the reset button

Then the application will start from flash and I can attach the debugger.

 

How to open the debug access from the application even without using DEV_MODE ?

 

[Imen.D]

Hello @AMurz.1 ,

Please try upgrade the ST-link firmware and use latest release of STM32CubeProgrammer.

[AMurz.1]

Hi,

Thanks for your reply.

I have tried with the latest versions of STM32CubeProgrammer and ST-Link firmware, but the error is the same:

- ST-Link Firmware version V3J16M8

- STM32CubeProgrammer v2.20.0

 

When trying to access the STM32N657 using STM32CubeProgrammer while having booted from FLASH, I get the same error:

This is the STM32CubeProgrammer logs:

 

I've also tried with the latest ST-Link firmware V3J16M9 from https://www.st.com/en/development-tools/stsw-link007.html, but this gives the same error:

All of these errors appears only when booting from FLASH instead of DEV_MODE, I'm using FLASH mode as I'm trying to attach the debugger to an already flashed program.

 

[Imen.D]

Hello @AMurz.1 ,

Check the configuration of the BOOT0 and BOOT1 pins.

Did you follow the instructions in the readme file and UM3249?

[AMurz.1]

Hi,

I'm using BOOT0 and BOOT1 to choose the boot mode between Flash mode and DEV mode; I'm following this article: STM32N6 boot ROM explained:

I'm trying to attach the debugger on the STM32N6570-DK board while it is booting in "Flash Boot".

Using "DEV Boot" with BOOT0=L and BOOT1=H, I can attach both the debugger and STM32CubeProgramer to the STM32N6. This is the documented way to debug the STM32N6 for development purpose (How to debug STM32N6 using STM32CubeIDE).

 

But here I'm trying to attach the debugger on the STM32N6570-DK board while it is booting in "Flash Boot" (BOOT0=L and BOOT1=L). This is where I get the errors I wrote in my previous posts with both ST-Link GDB Server (Target unknown error 32) or STM32CubeProgramer (Error: Cannot connect to access port 1!).

 

In STM32N6 boot ROM explained page, it is said:

2. Utilizing DEV boot mode The DEV boot mode can be utilized during the development phase to execute applications or the FSBL directly from RAM. This mode is executed only in the CLOSED_UNLOCKED life cycle. Additional information on the life cycle is mentioned later in this article. In this scenario, the boot ROM code protects its assets, reopens the debug secure and nonsecure, and then goes into an endless loop. As mentioned, the DEV boot mode is selected using the Boot1 pin.

I'm trying to do the same "reopens the debug secure and nonsecure" in my application, so I can attach a debugger even when booting with Flash Boot (BOOT0=L and BOOT1=L).

I guess this is what is missing from my application, so the debug secure/nonsecure is kept closed.

I've tried to open the debug port of the STM32N6 from my application by writing 0xB4 to the BSEC_AP_UNLOCK register, but it still fails with the same errors in both ST-Link GDB Server and STM32CubeProgrammer.

/* Write 0xB4 to BSEC_AP_UNLOCK register from FSBL startup code */
 ldr r0, = 0x56009E90
 mov r1, #0xB4
 str r1, [r0]

 

[AMurz.1]

Hi,

I've found what I was missing. I though setting BSEC_AP_UNLOCK was the only needed thing to do, but there is also BSEC_DBGCR.

 

To open the debug access when booting from FLASH, there are 2 registers which needs to be written:

• Open the debug access port to the Cortex-M55 by writing 0xB4 to BSEC_AP_UNLOCK
• Enable the non-secure/secure debug by writing 0xB451B400 to BSEC_DBGCR

Note: these values are the values in these registers when booting in "DEV Boot" mode.

Relevant chapters from the STM32N6x7 Reference Manual:

• Chapter "78.6.1 BSEC control over debug"
• Chapter "4.5.18 BSEC debug control register (BSEC_DBGCR)"
• Chapter "4.5.19 BSEC AP unlock (BSEC_AP_UNLOCK)"

 

Here is the code in my FSBL startup code (startup_stm32n657x0hxq_fsbl.s) that allows me to attach the debugger even when booting from "FLASH Boot" mode instead of "DEV Boot" mode:

 

/* Allow debugging when booting from FLASH, according to the STM32N6 Reference Manual:
 * - Chapter "78.6.1 BSEC control over debug"
 * - Chapter "4.5.18 BSEC debug control register (BSEC_DBGCR)"
 * - Chapter "4.5.19 BSEC AP unlock (BSEC_AP_UNLOCK)"
 *
 * When using a stock STM32N6570-DK board, the STM32N6 is in BSEC-Closed mode.
 * Which means we need to manually open the debug access to allow debugging even when booting from FLASH.
 * Note: when booting in DEV Boot mode, the Boot ROM already takes care of opening the debug access.
 *
 * When the Boot ROM bootloader starts the FSBL, the HDPL level is 1 (0x51 in BSEC_HDPLSR register).
 * Setting AUTH_HDPL to 0x51 means Level 1 and so AUTH_HDPL <= HDPLSR.
 * In that case (AUTH_HDPL <= HDPLSR):
 * - UNLOCK value is used for debug nonsecure (where 0xB4 means debug is open)
 * - (UNLOCK & AUTH_SEC) value is used for debug secure (where 0xB4 means debug is open)
 *
 * So setting both UNLOCK and AUTH_SEC to 0xB4 and AUTH_HDPL to 0x51 will open the debug access for both secure and nonsecure.
 * 
 * If nothing in the FSBL or later change the HDPL (which should not be the case except with special code doing this)
 * then the HDPL level is 1 through the whole application execution, and the debug access will be kept open.
 * 
 * So, to allow debugging, we need to:
 * - Open the debug access port to the Cortex-M55 by writing 0xB4 to BSEC_AP_UNLOCK
 * - Enable the non-secure/secure debug by writing 0xB451B400 to BSEC_DBGCR
 *
 * Note: these values are taken from the values in these registers when booting in DEV mode.
 */
/* Open the debug access port to the Cortex-M55 by writing 0xB4 to BSEC_AP_UNLOCK */
 ldr r0, = 0x56009E90
 mov r1, #0xB4
 str r1, [r0]

/* Enable the non-secure/secure debug by writing 0xB451B400 to BSEC_DBGCR */
 ldr r0, = 0x56009E8C
 ldr r1, = 0xB451B400
 str r1, [r0]

Note: BSEC clock in RCC is already enabled at reset, so I don't think it is needed to be set manually (see RCC_APB4HENR). If the application disable this clock, maybe then it is safer to enable it before writing to BSEC registers.

 

Sorry for the trouble, I didn't know at first what information in the reference manual was relevant for the STM32N6570-DK board (whether the BSEC is in open or closed mode, and what needs to be set to make the debug access really effectively working).

 

Maybe the Boot ROM is also doing some more setup to open the debug access, in which case I'm interested to know, to complete the answer.