STM32N6, Application HardFaults when using XIP + XSPIM in Multiplex mode after FSBL handoff

[nima2]

Hi, 

I am using an STM32N6570-DK running in XIP mode with XSPIM configured in multiplex mode.

Setup:

• XSPIM in multiplex mode

• XSPI1 / XSPI2 → Port 2 → external flash

• XSPI3 → Port 1 → PSRAM

• XSPI2 memory-mapped at 0x70000000

• FSBL configures external flash and jumps to the application at 0x70100400
  (VTOR = 0x70100400, MSP = 0x34200000, PC = 0x7010BA01)

Everything works correctly in direct XSPIM mode, but in multiplex mode the application HardFaults or hangs immediately after the FSBL jump.

The faults occur during early HAL initialization (e.g., in HAL_MspInit() or MX_GPIO_Init()), specifically when executing functions such as:

• HAL_PWREx_EnableVddIO3();
• __HAL_RCC_GPIOO_CLK_ENABLE();
• HAL_RCCEx_PeriphCLKConfig();

If I comment out these lines, the application runs, but then I face issues whenever adding new peripherals (like UART).

It seems that reinitializing power domains or clocks related to XSPI pins while executing from external flash triggers a crash. I am using STM32Cube FW_N6 V1.2.0 and STM32CubeMx v 6.15.0.

Is there an official or recommended method to prevent the application from reinitializing hardware already configured by the FSBL (such as XSPI, XSPIM, VddIO2/3, or related GPIOs/clocks) when running in XIP multiplex mode?

[Khaled_DHIF]

Hello @nima2 ,

The HardFaults and hangs in XIP multiplex mode occur because the application attempts to reinitialize hardware resources (XSPI interfaces, power domains, GPIO clocks) that have already been configured by the FSBL. Since the application executes directly from external flash, reconfiguring these resources disrupts flash access and leads to faults. Have you ensured that the XSPIM interface is configured exclusively in the FSBL project within STM32CubeMX? Please share your .ioc file so I can review your configuration and provide precise guidance.

Kind regards, 

DHIF Khaled

[Theodore-henry6]

Hi,

In XIP multiplex mode, reinitializing XSPI, clocks, or VddIO already set up by the FSBL can cause HardFaults. The recommended approach is to skip hardware already initialized by FSBL and only configure peripherals not handled yet. You can use flags or check registers to detect this.

[nima2]

Hi, thanks for your response.

Yes, the XSPIM interface is fully configured in the FSBL project, and application does not reconfigure XSPI or XSPIM manually.
However, even when the XSPIM peripherals are not touched in the application, the issue occurs if HAL_Init() or peripheral initialization (e.g. HAL_MspInit() or MX_GPIO_Init()) runs functions like:

HAL_PWREx_EnableVddIO2();
HAL_PWREx_EnableVddIO3();
__HAL_RCC_GPIOx_CLK_ENABLE();
HAL_RCCEx_PeriphCLKConfig();

These seem to indirectly affect I/O banks or clocks related to the flash interface, leading to a HardFault as the code is executing from external flash.

Please find my .ioc file attached