STM32H7 QSPI/OSPI critical code-gen bugs (CubeIDE 1.6.1)

[Wolfgang Pupp]

Codegeneration for QSPI/OCTOSPI currently fails to enable a required clock and also passes an invalid value in the initialization struct.

This is important to fix because especially the clock-issue was very hard to identify (and avoiding such init-pitfalls is IMO the core reason for the whole Cube-stuff to EXIST).

The generated function HAL_OSPI_MspInit should call:

__HAL_RCC_OCTOSPIM_CLK_ENABLE()

but it never does.

In MX_OCTOSPI2_Init, there should be a line like:

sOspiManagerCfg.Req2AckTime = 1;

because this value is asserted to be non-zero in HAL_OSPIM_Config.

Current workaround:

Manually fix both in the user-section of MX_OCTOSPI2_Init:

 /* USER CODE BEGIN OCTOSPI2_Init 1 */

 __HAL_RCC_OCTOSPIM_CLK_ENABLE();

 sOspiManagerCfg.Req2AckTime = 1;

 /* USER CODE END OCTOSPI2_Init 1 */

How to reproduce:

Attempt to use OCTOSPI2 peripheral (USE_FULL_ASSERT required for the invalid-Req2AckTime-check).

I can provide a fairly minimal *.ioc file if needed.

Versions:

CubeIDE 1.6.1, using STMCube_FW_H7 v1.9.0

I would gladly submit a pull-request or somesuch for issues like these to expedite the process but not sure if this is possible/helpful/where this should happen (any info on this would be appreciated).

[Amel NASRI]

Hi @Wolfgang Pupp​ ,

If there is an issue in generated code, it is on STM32CubeMX side (embedded in STM32CubeIDE).

Our STM32CubeMX experts @Khouloud ZEMMELI​ or @Khouloud OTHMAN​  will have a look to check deeply the reported issue and take relevant actions.

They will keep you informed in this thread.

Unfortunately Github pull-requests are currently supported only for STM32Cube firmware package, and not STM32CubeMX or STM32CubeIDE.

So, correct location to report such issues is the community, as you did (topics or tags are very important in such case).

-Amel

[Khouloud ZEMMELI]

Hello @Wolfgang Pupp​ ,

Thank you for raising the problem,

Could you please provide your ioc file? It will be helpful to reproduce the issue.

Thanks, Khouloud

[Wolfgang Pupp]

Attached file should work!

This is for a STM32H723 Nucleo Evalboard.

I suspect that __HAL_RCC_OCTOSPIM_CLK_ENABLE is optional under *some *circumstances ("default" data line mapping), but not in general, which might be how this issue avoided detection until now.

From the reference manual, it is not clear to me whether OCTOSPIM_CLK is only required for non-default signal mappings.

I also think that the OCTOSPIM_CLK is only required during initialization (i.e. during the HAL_OSPIM_Config call).

If I disable it immediately afterwards, all my QSPI communication still keeps working fine.

The reference manual also implies that the OCTOSPIM configuration should happen while the OCTOSPI peripheral itself is enabled, so maybe the order should also be switched? ("The I/O matrix must be configured when the OCTOSPIs are disabled, to avoid unexpected transactions on the bus.")

Right now, generated code looks like this (but I think HAL_OSPIM_Config should be called first:(

  if (HAL_OSPI_Init(&hospi2) != HAL_OK)
  {
    Error_Handler();
  }
  [...]
  if (HAL_OSPIM_Config(&hospi2, &sOspiManagerCfg, HAL_OSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)
  {
    Error_Handler();
  }

This ordering did not lead to any observable issues in my case though (yet).

[Khouloud ZEMMELI · Accepted solution]

Hello @Wolfgang Pupp​ ,

You're right, the __HAL_RCC_OCTOSPIM_CLK_ENABLE() was missed, this issue will be fixed.

For the second one, the "sOspiManagerCfg.Req2AckTime = 1;" should only be generated when a Multiplexed mode is used, otherwise, it will not be called in the code.

Thanks for raising the issue to our attention and for your contribution 🙂

Khouloud