STM32N657X0-Q BSEC Secured State - Cannot boot FSBL with unsigned binary

[AndreapavesiIsb]

Hi ST Support Team,

I'm developing a simple FSBL application (LED control) on a NUCLEO-N657X0-Q board to understand the boot management flow with FSBL and application separation.

What I've done:

1. Successfully tested the application running directly from RAM via debugger
2. Compiled the FSBL for external XSPI flash (linker configured for execution from AXISRAM2 at 0x34180400)
3. Signed the binary using STM32_SigningTool_CLI with header v2.3, -nk flag (no keys), -of 0x00000000, and correct load address/entry point
4. Programmed the signed binary to external flash at 0x70000000 using STM32CubeProgrammer with the appropriate external loader
5. Configured BOOT0=LOW, BOOT1=LOW for boot from XSPI flash

The problem: The Boot ROM does not load the FSBL into RAM. When I read AXISRAM2 (0x34180000) after reset, it contains all zeros, indicating the Boot ROM is rejecting or not attempting to load the FSBL.

What I discovered: In STM32CubeProgrammer → OTP MPU tab, I see:

• BSEC State: Secured
• Global State: 0x00000001

Additionally, from the BSEC registers:

• BSEC_SR.NVSTATE = 0xD (Secured lifecycle state)
• BSEC_HDPLSR.HDPL = 0x51

My questions:

1. Is the board locked permanently? The board was brand new from the distributor. I did not intentionally configure it to Secured state during my development.
2. Can I revert to Open/Development state to allow unsigned FSBL binaries for development purposes? Or is this an irreversible OTP configuration?
3. Is there a development bypass mode or debug authentication procedure that would allow me to boot unsigned FSBL while in Secured state?
4. Could the problem be elsewhere? The signed binary header appears valid when checked with STM32_SigningTool_CLI -dump, and the vector table in flash is correct (Stack Pointer = 0x34200000, Reset Handler = 0x34181B1D).

I need to understand if:

• The BSEC Secured state is the root cause preventing boot
• There's a way to transition back to a development-friendly state
• I should use signed binaries with real keys even for development

Any guidance would be greatly appreciated. Thank you!

Board information:

• NUCLEO-N657X0-Q
• Device: STM32N657
• Revision: Rev B
• ST-Link FW: V3J16M8
• STM32CubeProgrammer: v2.21.0

[RomainR. · Accepted solution]

Hello @AndreapavesiIsb 

When using STM32CubeProgrammer v2.21.0, can you try to sign your binary with [--align] option as explained in this post:

https://community.st.com/t5/stm32cubeprogrammer-mcus/signingtool-for-stm32n6-in-stm32cubeprogrammer-v2-21-0/td-p/859154

Best regards,

Romain,

[AndreapavesiIsb]

Hi,
Thank you for the guidance and the reference to the forum topic. I managed to resolve the issue!
Root cause:
I was explicitly specifying the load address (-la 0x34180400) and entry point (-ep 0x34181B1C) parameters in the signing command. 
Solution:
Following the exact command from the forum topic, I removed the -la and -ep parameters and let the STM32_SigningTool_CLI extract them automatically from the binary. The tool now sets the load address to 0xFFFFFFFF (auto), and the Boot ROM accepts and loads the FSBL correctly.
Working command:
STM32_SigningTool_CLI.exe -bin Project.bin -nk -of 0x80000000 -t fsbl -hv 2.3 -align -o Project-signed.bin
The FSBL now boots successfully from external flash with BOOT0=LOW, BOOT1=LOW.
Thank you again for your support!
Best regards

Andrea