STM32N657-DK: BootROM hangs after reset if XSPI1 has been initialized (power cycle required)

[Franzi.Edo]

Hello,
I am experiencing what appears to be a BootROM or silicon issue on the STM32N657-DK.

Hardware

• STM32N657-DK Discovery board
• Boot from the on-board XSPI Flash
• External APSRAM connected to XSPI1

Problem description
The system works perfectly after a power-on reset.

The FSBL starts correctly, the application runs, XSPI1 is initialized, and the APSRAM is fully functional. There are no communication errors with the memory.
However, after XSPI1 has been initialized once, any subsequent reset causes the board to become completely unresponsive.

The problem occurs with:

• pressing the NRST button,
• calling NVIC_SystemReset(),
• or resetting through the debugger.

After such a reset:

• the CPU never reaches the FSBL,
• the debugger cannot stop in the reset handler,
• it appears that the BootROM itself never starts the boot process.

The only way to recover the board is to completely remove the power supply and power it up again. A simple reset is never sufficient.

Additional observations

• If XSPI1 is never initialized, the board can be reset indefinitely without any issue.
• The problem only appears after XSPI1 has been configured and used.
• The APSRAM itself operates correctly while the application is running.
• Therefore, this does not appear to be an APSRAM communication problem.

Related information
I found a discussion on the ST Community that describes almost exactly the same behavior:

• first boot after power-on works,
• after XSPI1 initialization, any reset prevents the BootROM from starting,
• only a complete power cycle restores normal operation.

The discussion also mentions Errata ES0620, section 2.2.23, concerning modifications of RCC clock selection registers (CCIPR6/7/8/13), which may prevent the BootROM from booting correctly after a reset.

Questions
Is this a known BootROM limitation or silicon issue?
Is there an official workaround besides avoiding modifications of the XSPI kernel clock selection?
Is this issue fixed in a newer silicon revision or BootROM version?

Any information would be greatly appreciated.

Thank you.

  Edo

[KDJEM.1]

Hello ​@Franzi.Edo ;

 

The erratum 2.2.22 Boot ROM execution failure after system reset due to wrong clocking of peripherals in the ES0620 is a silicon issue in Rev Z and Rev B.

The only granted workaround is shared in the erratasheet is 

 

Currently, there is no silicon Revision that fixes the issue. 

 

Thank you for your contribution in STCommunity.

Kaouthar

[Franzi.Edo]

Hi Kaouthar,

Unfortunately, the proposed solution alone was not sufficient in my case.

After several days of investigation, I finally found a workaround that completely solves the issue. The system now behaves correctly after both power-on and NRST, even when the application uses XSPI1 + APSRAM.

The solution requires two separate modifications.

1. Apply the NRST workaround in the FSBL

The FSBL must implement the workaround described in the STM32N6 errata:

• store a magic value in AXISRAM1
• configure SYSCFG->CM55RSTCR.CORE_RESET_TYPE
• perform one software reset
• continue booting after the second pass

The code below is what I finally used:

/* USER CODE BEGIN 0 */

#include "main.h"

#define NRST_MAGIC_ADDRESS    (0x34001004UL)
#define NRST_MAGIC_VALUE      (0x11223344UL)

static void Apply_NRST_Workaround(void) {
    volatile uint32_t * const magic = (volatile uint32_t *)NRST_MAGIC_ADDRESS;

    __HAL_RCC_SYSCFG_CLK_ENABLE();
    __DSB();

    /* First pass */

    if (*magic != NRST_MAGIC_VALUE) {
        *magic = NRST_MAGIC_VALUE;
        __DSB();

        SET_BIT(SYSCFG->CM55RSTCR, SYSCFG_CM55RSTCR_CORE_RESET_TYPE);
        (void)SYSCFG->CM55RSTCR;

        __DSB();
        __ISB();

        /* Software reset */
        NVIC_SystemReset();

        while (1) { __NOP(); }
    }

    /* Second pass */

    SET_BIT(SYSCFG->CM55RSTCR, SYSCFG_CM55RSTCR_CORE_RESET_TYPE);
    (void)SYSCFG->CM55RSTCR;

    __DSB();
    __ISB();
}

/* USER CODE END 0 */

Then call

Apply_NRST_Workaround();

at the very beginning of main(), before HAL_Init().

This part alone, however, was not sufficient in my case.

2. Keep RCC->CCIPR6.XSPI1SEL at its reset value

The second issue was inside the application.

If the application uses XSPI1 (for example with APSRAM), do not modify the XSPI1SEL field in RCC->CCIPR6.

Leave both bits at their reset value:

XSPI1SEL = 0

which means the XSPI1 kernel clock is sourced from HCLK5.

Instead of changing the clock source, simply adjust the XSPI clock divider to obtain the required operating frequency.

Once I stopped modifying XSPI1SEL, the problem completely disappeared.

Now the system behaves correctly:

• Power-on boot ✔️
• Hardware NRST ✔️
• BootROM → FSBL ✔️
• Application using XSPI1 + APSRAM ✔️

I don't know whether this behavior is related to the silicon errata concerning the clock selector, but on my STM32N6570-DK this was the missing piece.

I hope this helps anyone facing the same issue.