STM32 Cube H7 HAL_OSPIM_Config() corrupts previous port configuration on the second call ?

[YTagu.1]

We are using STM32Cube_FW_H7 latest version and faced the similar problem happened on STM32Cube_FW_L4 which is discussed here. We use two Octo SPI with one running in Octo memory mapped mode and one running in Quad SPI direct mode.

Firstly, we configured the Octo mode IO ports with HAL_OSPIM_Config and then configured the Quad SPI. If we configure Octo only, the Octo memory mapped mode works well. However, If we configure Quad SPI as well, the first Octo configuration got corrupted.

Does someone face the same problem? I suspect that the similar bug exists in Cube_FW_H7 like the one in STM32Cube_FW_L4.

[ChahinezC]

Hello @YTagu.1​,

Are you using the STM32CubeMX for the generation of your project?

Chahinez.

[YTagu.1]

Hi @ChahinezC​ ,

Yes, We're using STM32CubeMX for the generation of our project.

YTagu.1

[ChahinezC]

Hello @YTagu.1​,

Can you please specify which ST device you're using and whether you are using the same port or different ones?

Chahinez.

[YTagu.1]

Hi @ChahinezC​ ,

Our ST Device is STM32H7A3LIH6Q. We are using different ports, that is, we don't use multiplexed mode.

[ChahinezC]

Hello @YTagu.1​,

Can you please state the versions you have used? (The STM32CubeMX and the H7 cube FW versions).

Can you also share with us your .ioc file? It helps us reproduce the issue.

Thank you.

Chahinez.

[YTagu.1]

Hi @ChahinezC​ 

Here are the versions:

• STM32CubeMX: 6.4.0
• STM32Cube FW_H7 v1.9.0​

Yes, we can share the .ioc file with you. However, it would be better if we can share the .ioc file privately. Could you give me your e-mail address to share the file? Or, do you have any other way to share the file privately?

We really appreciate your effort to reproduce the problem.

Best regards,

Yoshitaka

[ChahinezC]

Hi @YTagu.1​,

You can share with me your .ioc file and IAR project by private message.

Can you also provide me with the following details:

Please describe the problem you are facing in details so I can reproduce it.

"the first Octo configuration got corrupted" --> How did you exactly see the corruption?

• did you face any compilation errors?
• did the configuration you set in STM32CubeMX get changed?
• did the first configuration got changed, overwritten or removed (if so please share with me the before and the after)

Chahinez.

[YTagu.1]

Hi @ChahinezC​ 

Thanks for suggesting the way to share the file. As I don't use IAR workbench, I only sent you my .ioc file via a private message. Please check your inbox.

We are using external SRAM memory with OctoSPI memory mapped mode. The HyperBus protocol is used. This peripheral is assigned to OctoSPI1. We also use external Flash memory with QuadSPI. This peripheral is assigned to OctoSPI2.

• We configure the OctoSPI1 and OctoSPI2 on STM32CubeMX at the same time.
• The CubeMX32 generates initialization function (MX_OCTOSPIx_Init) for both OctoSPI1 and OctoSPI2. We do not face any compilation errors in the generated code.
• If we call the MX_OCTOSPI1_Init first and then MX_OCTOSPI2_Init, the MCU halts on the first access to the external RAM. The MCU does not jump to any fault handler. It just stop immediately after the access to the external RAM.
• If we call the MX_OCTOSPI1_Init only and commend out the call of MX_OCTOSPI2_Init, then the external RAM works. We can read and write data to the external RAM with memory mapped mode correctly.

"the first Octo configuration got corrupted" does not mean the corruption of the configuration in CubeMX. It means the corruption of configurations in the registers which were made by HAL_OSPIM_Config function.

To be honest, the statement that "HAL_OSPIM_Config() corrupts previous port configuration on the second call" is just an assumption. As the reference manual states "two OCTOSPI works separately", we assume the problem is happening on the common parts of two OCTOSPI - that is, IO configuration, which is made by HAL_OSPIM_Config.

To state our situation more accurately, "Call of MX_OCTOSPI2_Init corrupts the configuration made by MX_OCTOSPI1_Init".

Best regards,

Yoshitaka

[YTagu.1]

Hi, @ChahinezC​ 

Any updates on this topic?

Best regards,

Yoshitaka