Skip to main content
Explorer
September 2, 2025
Solved

STM32H7S3H6 Application Crashes During XSPI1 Initialization

  • September 2, 2025
  • 2 replies
  • 258 views

 

I’m encountering an issue with XSPI1 in my application. I boot the application via XSPI2 in an LRUN configuration, and this part works perfectly. However, within the application, I need to use XSPI1 to write data to a different flash.

During MX_XSPI1_Init(), the code crashes at this line:

if (HAL_XSPIM_Config(&hxspi1, &sXspiManagerCfg, HAL_XSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)
{
Error_Handler();
}

I traced the crash to the exact line:

IOM_cfg[0].IOPort = pCfg->IOPort;

The initialization code for XSPI1 was generated using CubeMX. Interestingly, if I initialize XSPI1 in the boot project, everything works fine.

I’ve already spent a week trying to solve this issue, but so far nothing has worked.

I would really appreciate  suggestions to help solve my problem.

    This topic has been closed for replies.
    Best answer by Danhe

    I’ve solved the problem. It seems there’s currently an issue in the HAL driver provided by STMicroelectronics, specifically in the HAL_XSPIM_Config function. I found a similar case reported by another user and based my solution on their approach. However, small adjustments are required depending on which XSPI instance you are using and the type of memory involved. The reason why the code crashes is also described in the forum entry.


    Link to the forum entry: https://community.st.com/t5/stm32-mcus-embedded-software/title-nucleo-h7s3l8-hardfault-timeout-when-using-xspi2-in-xip/m-p/832658 

     

    2 replies

    ST Employee
    September 2, 2025

    Hello @Danhe , 

    You can use the XPI example available on our GitHub repository, which can help you with your testing. Please find the example at the following link:

    https://github.com/STMicroelectronics/STM32CubeH7RS/tree/main/Projects/NUCLEO-H7S3L8/Examples/XSPI

     

    Br

    DanheAuthorAnswer
    Explorer
    September 3, 2025

    I’ve solved the problem. It seems there’s currently an issue in the HAL driver provided by STMicroelectronics, specifically in the HAL_XSPIM_Config function. I found a similar case reported by another user and based my solution on their approach. However, small adjustments are required depending on which XSPI instance you are using and the type of memory involved. The reason why the code crashes is also described in the forum entry.


    Link to the forum entry: https://community.st.com/t5/stm32-mcus-embedded-software/title-nucleo-h7s3l8-hardfault-timeout-when-using-xspi2-in-xip/m-p/832658