STM32N6570-DK fails to boot after reset when XSPI1 is initialized (LR Mode)

[nima2]

Hi, 

I am working on the STM32N6570-DK board using the Load & Run boot mode.

• XSPI2 is used to interface the external flash (boot device).
• XSPI1 is used to interface an external PSRAM.
• The FSBL is loaded by BootROM and runs from internal SRAM.
• The FSBL initializes both XSPI2 (for reading the application image) and XSPI1 (for PSRAM).
• The FSBL copies the application into internal RAM, deinitializes the peripherals, and jumps to the application.

Everything works correctly after a power-on sequence (disconnecting and reconnecting board power).

However, after any system reset, either by:

• pressing the reset button on the board, or
• calling NVIC_SystemReset() in firmware

the device does not boot up again and it seems that the FSBL never starts.

If the FSBL only initializes XSPI2 (and does not touch XSPI1 at all), the board boots correctly after both power-on and any kind of system reset. I am using STM32Cube FW_N6 V1.2.0 and STM32CubeMx v 6.15.0.

[nima2]

I am now certain the issue is tied to XSPI1 usage. In STM32Cube, if I configure only the external flash on XSPI2, everything works fine, even after software reset. But when I switch to SWAPPED mode and use XSPI1 for the flash (without adding RAM in the configuration), the system fails to boot after a software reset.

It seems that BootROM itself relies on XSPI1, so if the application initializes XSPI1, BootROM cannot re-access it after reset.

Does ST know about this limitation? Is there any workaround or fix available?

[pdemeter]

Hi,

I experienced exactly the same issue. The Load and Run application started correctly and was using the XSPI1 and XSPI2 peripherals, but after an external NRST reset the boot ROM execution got stuck, and only a power cycle could recover the device.

According to revision 3 of the STM32N6 errata (section 2.2.23) if the RCC_CCIPR6, RCC_CCIPR7, RCC_CCIPR8, or RCC_CCIPR13 registers are modified, a boot ROM execution failure can occur after reset.

In our application, this was exactly the root cause, because the XSPI peripherals were configured to use the IC3 and IC4 clock sources. As a workaround, we reconfigured the clocks so that both XSPI peripherals are driven from HCLK, and then set the exact peripheral frequency using the corresponding PRESCALER registers.

Unfortunately, in STM32CubeMX it is not entirely clear which peripheral clock bus the HCLK clock source actually refers to.

I hope this helps,

Peter

[nima2]

Hi Peter,

Thank you for sharing your workaround!

Did you need to make any additional changes beyond switching the XSPI clock source to HCLK since it does not work for me?

My situation:

• IC3/IC4 at ~100-200 MHz: memories initialize successfully
• HCLK at 100 MHz or 200 MHz: initialization fails (NOR=-3 PSRAM=-3)
• Clock configuration is verified correct via logs

Since HCLK maxes out at 200 MHz and our NOR/PSRAM support 200 MHz, prescaler=0 should work. However, memories fail to initialize with HCLK regardless of frequency.

did you adjust anything else like XSPI timing parameters (sample shifting, free-running clock, DHQC), any registers beyond the RCC clock mux?

I suspect HCLK has different timing characteristics that require additional configuration.

Any insights would be appreciated!

Best regards