STM32U5G9: External Loader Created but not Working

Question

Hi @stm32

I have a STM32U5G9 chip connected to a NOR_FLASH Memory MX25UM51245G using OctoSPI. I created an External Loader for the setup, but unable to read/write using the stm32 programmer. The custom driver I developed for the particular flash is proved to work with the same hardware setup, so i can confirm that the bridging between the working driver and the STM2Programmer is somewhat missing.

Steps I Followed to create the Loader are:

1) Created a CubeMx project for stm32U5 with OctoSPI enabled in my case.

2) Manually copied the loader files from the link https://github.com/STMicroelectronics/stm32-external-loader/tree/contrib/Loader_Files and also integrated my custom driver for the particular NOR_FLASH. The driver is tested and verified separately,So it works.

3) In the build configurations, pasted the command cmd.exe /C copy /Y "${BuildArtifactFileBaseName}.elf" "..\${BuildArtifactFileBaseName}.stldr" to create stldr.

After further debugging, i came to the conclusion that the functions Init, Read,Write in the Loader_Src.c are not being called. I had similar problems for the STM32G0 but defining the RAM start address as 0x20000004 and aligning the Vector table to 0x20000000 | 0x200 resolved the issue. The similar fix doesnot help me here.

I would appreciate anyone's help in this if someone already know the problem and how to resolve it. Also, i couldnot see any documentation regarding how the 4bytes for STM32Cubeprogrammer BL to be assigned or how to align the vector table for a particular STM32 chip series.

I am also attaching my linker.ld, Dev_Inf.c/.h files, startup and the Loader_Src.c file for clearer picture. Please note that the Init ,Read and Write functions are properly loaded in the RAM by investigating the Build Analyser in the STM32CubeIDE. I am also attaching a screenshot of that.

Thanks,

Renjith Gopan

Tesla DeLorean · Accepted Answer

I'll take a look.Typically for NOR_FLASH type the programmer expects to use Memory Mapped so the SWD/JTAG can inspect directly, and not use Read(). Whereas for SPI_FLASH the Read() and Write() methods are used.When using Write() STM32 Cube Programmer uses the remaining RAM, not used by the loader, to create a Ping-Pong Buffer, the SWD/JTAG writes into this buffer, and then calls Write(). These buffers can be 10's of KB. This is one of the reasons I prefer to make the loaders small and compact.

RenjithGopan · Answer

@Tesla DeLorean ,

Hello Tesla,

I could see you have created most of the external loaders and your solution for my previous problem with STM32G0 helped to resolve, have you ever had this issue before. It would be a great help if you have a work around or solution for my problem.

Thanks,

Renjith

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded