Skip to main content
Associate
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.

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

MOBEJ
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

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
DanheAuthorBest answer
Associate
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