STM32CubeMX generates incorrect code for the OCTOSPI interface for STM32H725. The generated code does not populate the Req2AckTime field of the OSPIM_CfgTypeDef structure, but HAL_OSPIM_Config() validates this value and throws an assertion error.

[Andrew Sterian]

See attached configuration in STM32CubeMX. Generated code is only:

  sOspiManagerCfg.ClkPort = 1;
  sOspiManagerCfg.NCSPort = 1;
  sOspiManagerCfg.IOLowPort = HAL_OSPIM_IOPORT_1_LOW;
 
// NOTE: MISSING ASSIGNMENT TO sOspiManagerCfg.Req2AckTime
 
  if (HAL_OSPIM_Config(&hospi1, &sOspiManagerCfg, HAL_OSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)
  {
    Error_Handler();
  }

[Semer CHERNI]

Hello @Andrew Sterian​ 

First let me thank you for having reported.

In fact I wasn't able to reproduce any building issue from my side when starting a project based on STM32H725AE MCU and using the latest version of STM32CubeMX / STM32CubeIDE: the build and the debugging has finished without any errors.

Could you please add more details about how did you proceed or attach your .ioc file to be able to further investigate from my side.

Your feedback will be very helpful to track the root cause of the issue.

Semer.

[Tesla DeLorean]

This, and a lot of the sub-fields are frequently missing from the OCTOSPI initialization code in the examples.

What are the expectations with Req2AckTime, on say OSPI FLASH?

Is the structure cleared in the subroutine local/auto usage?

Did you check the assert()'s ?

What version of the tools fixed the code generation issue, this would be helpful information, rather than just chasing the latest version mantra. Would certainly help understanding the regression issues across multiple STM32 platforms.

[Andrew Sterian]

Hello Semer,

Thank you for your reply. Your code will build without any errors, and no errors will be reported at runtime unless you compile with the "Enable Full Assert" option checked in STM32CubeMX (Project Manager-->Code Generator-->HAL Settings-->Enable Full Assert)

Can you inspect the contents of your MX_OCTOSPI1_Init() function and report on whether an assignment to sOspiManagerCfg.Req2AckTime is performed? For example, I had to add this line manually:

sOspiManagerCfg.Req2AckTime = 1

Can you then check the implementation of HAL_OSPIM_Config() and verify that an assertion check is made on proper assignment to Req2AckTime. For example, in the latest HAL (1.11.0) I see:

HAL_StatusTypeDef HAL_OSPIM_Config(OSPI_HandleTypeDef *hospi, OSPIM_CfgTypeDef *cfg, uint32_t Timeout)

{

......

 assert_param(IS_OSPIM_REQ2ACKTIME(cfg->Req2AckTime));

......

}

I hope you can see that with the assert_param() statement as shown above, and failure to initialize Req2AckTime in MX_OCTOSPI1_Init() that an assertion failure will be triggered.

[Tesla DeLorean · Accepted solution]

I'd read the initial post and understood this.. and I just code walked it, and yeah, that'd break for sure..

https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_ospi.c#L2487

https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Drivers/STM32H7xx_HAL_Driver/Inc/stm32h7xx_hal_ospi.h#L1054

Zero would fail

[Tesla DeLorean]

Consider what (0 - 1U) computes to

https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_ospi.c#L2606

Consider further QuadSPI usage on OSPIM

OSPIM_Cfg_Struct.DQSPort = 0 will assert

OSPIM_Cfg_Struct.IOHighPort = 0 will assert

[NRedd.2]

@Tesla DeLorean Totally agree.

I had this issue when I configured for QSPI mode on H723. 

Wrong parameters value: file /home/Project/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_ospi.c
on line 2487.

I am using CubeMX 6.9.2 with HAL 1.11.1