STM32H573 Custom Loader OSPI using Dual MX25L12833F

[JHedges]

Hello,

We are developing a STLDR to be used with STM32CubeProgrammer and are having what is seemingly random issues when programming hardware.

We have already written the XSPI interface which works when executed in FLASH using test calls, but as soon as the interface is placed into the STLDR framework and used with STM32CubeProgrammer we are seeing failures of either the Init or SectorErase functions.

Sometimes it will work after a full board reset, but not always.

We have tried linking the loader at the undocumented 0x20003004 RAM address but this seemingly does not fix the issue.

We have tried using our standard development IDE (not ST) which has been successful in the past, but also following the STM32Cube tutorial and repository here, replacing the QSPI calls with XSPI:

https://wiki.st.com/stm32mcu/wiki/Getting_started_with_External_memory_Manager_and_External_memory_loader

https://github.com/STMicroelectronics/stm32-external-loader

The hardware is a custom board using the H573II with dual MX25L12833F on the XSPI bus.

The common failures we are seeing is:

1. Init() returns 0
2. Init() timeout
3. EraseSector() fails and R1 contains the memory mapped address

We have tried using the internal flash to trace the failures, however the loader can fail before reaching XSPI initialisation in some cases.

Any help or suggestions are greatly welcomed.

[KDJEM.1]

Hello @JHedges ;

I recommend you to look at MOOC - External QSPI loader how to - YouTube may help you to check your project.

Thank you.

Kaouthar

[JHedges · Accepted solution]

Hello @KDJEM.1 

Thank you for taking the time to respond.

We have since been in touch with ST direclty through our supplier and they have confirmed the following two issues:

• The project was larger than the allocated 64K SRAM in the CubeProgrammer database, this was fixed by enabling Os.
• There was a bug in CubeProgrammer v2.18 (and possibly earlier) where there was a incorrect load address used for the STM32H5 which is mentioned on some forums but not documented. This fixed in v2.22 onwards of the programmer.

Correcting these two points, the loader now functions as expected.

Jack

[KDJEM.1]

Hello @JHedges ,

Thank you for coming back to the community and for sharing the solution.

Thank you.

Kaouthar