STM32H5 external loader

[AMend.7]

Hi,

 I need the project used to generate the external loader: MX25LM51245G_STM32H573I-DK.stldr. My custom board uses a STM32H563VIT6 and the same octo-spi flash from Macronix used in the STM32H573I-DK board. But with different gpios connections. So this project would be of great help to develop the external flash loader for my board.

Ari

[Tesla DeLorean]

Could probably get something close via  https://github.com/STMicroelectronics/stm32-external-loader/tree/main/STM32L5x_boards/MX25LM51245G_STM32L562E-DK

With a pin list I could probably patch the current one, or port one of the H7/U5 variants I have working.

[KDJEM.1]

Hi @AMend.7 ,

Besides, the reply shared by @Tesla DeLorean, thanks to STM32CubeProgrammer software description you can create your own external loader.

For that, please follow the steps shared in UM2237 and precisely 2.3.3 Developing customized loaders for external memory section.

I hope this help you!

Kaouthar

[Tesla DeLorean]

I think having some XSPI examples for the H5 would seem like a more pressing need.

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

Ported some of my Winbond Quad examples over to H5, building at least, but not something I can test in the near term.

I think the manual falls short of the overall complexity and difficulty in constructing and testing external loaders. And they could have be designed with a lot better thought to allow for pin level configurability.

[AMend.7]

Kaouthar,

 Could you check internally if the project used to generate the external loader file for the STM32H573I-DK board exists? Or could you at least let me know when this project will be available on github? What complicates things a little is that I can't use the MX25LM51245G driver from other boards that use this memory because the STM32H5 is the only STM32 that uses an interface called XSPI instead of OSPI. 

Thanks,

Ari

[Tesla DeLorean]

Ari, I think the internal ones are built from entirely different forks. I'd like to see some more of the coders present and participating in the forum, so we can get a better solution hammered out.

The migration from OCTO to XSPI was a bit annoying, a lot of fields in the initialization and command structures changed names, and some where the capitalization changed.

The source files bundled with STM32 Cube Programmer are very limited and stale, and don't address any of the modern parts. This current approach really needs to change, especially as the part variants continue to grow, and most customers aren't building exact copies of ST boards, and have to make different pin choices based on routing or package sizes.

What I'd like to see is a table or script driven pin method, that users can edit. This at the very least would make porting to different pin configurations less of a head-ache for 90% of users.

Which pins are you using? I did start creating lists last night  https://github.com/cturvey/stm32extldr/blob/main/h563_octo_pins.txt

[Tesla DeLorean]

; MX25LM51245G_STM32H573I-DK-RevB.stldr
;
; PG6  AF10 NCS
; PB2  AF10 DQS
; PF10 AF9  CLK
; PB1  AF6  OCTOSPI1 IO0
; PD12 AF9  OCTOSPI1 IO1
; PC2  AF9  OCTOSPI1 IO2
; PD13 AF9  OCTOSPI1 IO3
; PH2  AF9  OCTOSPI1 IO4
; PH3  AF9  OCTOSPI1 IO5
; PG9  AF9  OCTOSPI1 IO6
; PC0  AF10 OCTOSPI1 IO7

; MX25LM51245G_STM32H573I-DK.stldr
;
; PG6  AF10 NCS
; PB2  AF10 DQS
; PF10 AF9  CLK
; PD11 AF9  OCTOSPI1 IO0  ** RevB PB1:AF6
; PD12 AF9  OCTOSPI1 IO1
; PC2  AF9  OCTOSPI1 IO2
; PD13 AF9  OCTOSPI1 IO3
; PH2  AF9  OCTOSPI1 IO4
; PH3  AF9  OCTOSPI1 IO5
; PG9  AF9  OCTOSPI1 IO6
; PC0  AF10 OCTOSPI1 IO7

[AMend.7]

Hi,

I'm using these pins:

PC2 ------> OCTOSPI1_IO2
PA3 ------> OCTOSPI1_CLK
PB2 ------> OCTOSPI1_DQS
PE7 ------> OCTOSPI1_IO4
PE8 ------> OCTOSPI1_IO5
PE9 ------> OCTOSPI1_IO6
PE10 ------> OCTOSPI1_IO7
PE11 ------> OCTOSPI1_NCS
PD11 ------> OCTOSPI1_IO0
PD12 ------> OCTOSPI1_IO1
PD13 ------> OCTOSPI1_IO3

I agree that ST should create a system with configurable pins or at least generate .stldr files for various gpio options. And also make the project used for all boards available. 

I also think it would be useful if the flash driver used in the external loader projects were used in the STM32Cube OCTOSPI examples, so it would be easy to change and test the driver for other memories.

[KDJEM.1]

Hi @AMend.7 ,

Unfortunately, there is no MX25LM51245G_STM32H573I-DK external loader project for the moment!  

Your request is reported internally.

Internal ticket number: 164707 (This is an internal tracking number and is not accessible or usable by customers).

Kaouthar

[AMend.7]

Ok. Thanks, Kaouthar.

Since the flash loader file MX25LM51245G_STM32H573I-DK.stldr is present in the STM32CubeProgrammer, I thought ST had the project that was used to generate this file.

But I think ST should try to provide better support in the development of an external flash loader for the STM32CubeProgrammer, as most of the questions in this forum are about this subject.

ST could leave the code that was used to generate the flash loader for a given development board as an example in the STM32Cube examples folder for that board. And also make the flash memory driver simpler and more portable.