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]

Ultimately I did get the OCTO part (MX25LM) working for Ari, as I recall.

I do have my own H5 QSPI External Loaders working too now, for the MX25L and W25Q series, and can build to order. This for the MX25L64 but just needs a recompile with pin details for an MX25L512

https://github.com/cturvey/stm32extldr/tree/main/h5_mx25l6433f

This is my H5 Linker Script for a build using HAL and GNU/GCC + MAKE, ie not Cube and without interrupt non-sense.

https://github.com/cturvey/stm32extldr/blob/main/ExternalLoader_H5.ld

[Tesla DeLorean]

For the NUCLEO-H563ZI

PE2, need to Make SB70, Open SB64

PB2:AF9 CLK

PG6:AF10 NCS

PD11:AF9 D0

PD12:AF9 D1

PE2:AF9 D2

PD13:AF9 D3

Tentative Build   https://github.com/cturvey/stm32extldr/tree/main/h5_mx25l51245g

[ABasi.2]

thank you!

today  i will try to use your linker file!

i only have two  questions if you want to answer:

RAM_INFO (r) : ORIGIN = 0, LENGTH = 1K /* 200-byte StorageInfo */
RAM_PROG (xrw) : ORIGIN = 0x20003004, LENGTH = 256K-12292 /* 0x20003004 for H5 ?? */

1) why the origin is at 0x20003004?

2) in the Loader_src.c file i have to change the address of VTOR.

if i understand well the line SCB->VTOR = 0x20000000 | 0x200; should be modified in SCB->VTOR = 0x20003004;

am i correct?

thank you!

[ABasi.2]

Thank you for your message!

i have a functioning driver for the memory, tested with the code attached (equal to the suggested code from the ST mooc) so i think the HW is correct, i think my problem is in the linker file or the Loader_Src.c file

thank you!

[ABasi.2]

hello Tesla Delorean

i have tried your loader and work fine! but i 'm trying to learn to make one.

then i have tried to modify my project with your linker file but it doesn't work

just use your linker is not possible, it don't compile , Cube code need  _estack , _min_heap_Size and _min_Stack size declaration that your linker don't have

i think you are using it without cube generated code

unfortunately at this day  i'm not able to modify the linker file ST provide

thank you for your file but i think the real problem is ST have to provide a working example/linker file for H5 device

best regards

[Tesla DeLorean]

The 0x20003004 vs 0x20000004 basis is discussed earlier in the thread. ST uses it for their H5 loaders, and despite asking no explanation was forthcoming. It does however work for other H5 loaders.

You can modify your own Linker Script to change the address.

The VTOR would need to be on a 512-byte boundary, so H5 case would be 0x20003200 rather than 0x20000200

I am not using Cube to build my code

[ABasi.2]

thank you for your kind message

i have tried, i have modified the linker and the loader_Src.c file

unfortunately is not working, i will continue to try

i attache anyway the files to this message, maybe are useful for other people

the only modification that i made in the linker.ld file downloadable from ST is:

RAM (xrw) : ORIGIN = 0x20003004, LENGTH = 256K-12292

thank you

[Tesla DeLorean]

If your board has an available UART / serial connection, you can use that or LEDs to indicate code execution and telemetry.

The other way to debug from application space would be to construct a test harness that calls and tests the entry points and functionality.

From STM32 Cube Programmer you can generate logs with verbose level of 3, to understand what's happening there.

The NORFLASH expects the Init() to put the device into Memory Mapped mode so data can be read directly via the MCU at 0x90000000. Perhaps dump section of memory to the serial port before leaving Init()

[ABasi.2]

thank you for your advice!

i will try the UART method (UART3 is connected to the st link on board)

but if the problem is in the linker i think maybe  the init function is not called from the cube programmer

best reguards

[Tesla DeLorean]

Well you should be able to mark the entry points. See how I used KEEP() to ensure the linker pulled them in and didn't do dead code elimination.

You could presumably use objcopy or objdump to confirm the exports on the .STLDR (ELF DLL)

I don't think STM32 Cube Programmer would load the External Loader if it couldn't find the StorageInfo or Init exported functions?

The memory read will occur after an Init(), you can see this occurring via the logging data at verbose level 3

If it calls Init() you can chirp on a UART or turn on a LED.

Chances are it's calling and simply not succeeding, or not memory mapping the external memory device properly.