Skip to main content
Visitor II
November 12, 2025
Question

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

  • November 12, 2025
  • 2 replies
  • 315 views

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?

    This topic has been closed for replies.

    2 replies

    ST Employee
    November 20, 2025

    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

    nima2Author
    Visitor II
    November 24, 2025

    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

    Visitor II
    November 20, 2025

    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.