cancel
Showing results for 
Search instead for 
Did you mean: 

External Loader with STM32CubeProgrammer

kb24
Senior

I created an external loader, I tried it with STM32CubeProgrammer. Most of the time its not working, rarely it can read the data and erase. When it happens I am trying to program the memory and it can program ~400 KB then it fails. Then I used ST-Link Utility and it can program 9 MB of data without any problem, also it can read and erase. It is always working well but same .stldr file is not working in STM32CubeProgrammer. I will use it for TouchGFX so I need STM32CubeProgrammer to work well. How can I solve this? Thank you.

By the way I asked another question about external loader, after being sure it will work with STM32CubeProgrammer I will share my driver code for MX25L12835F and STM32H7A3RITX under that question so anyone who needs those drivers can download from there.

1 ACCEPTED SOLUTION

Accepted Solutions
kb24
Senior

There were two different Loader_Src.c files of ST on GitHub. I thought those were same and I used first one. In that file there are many HAL_OSPI_Abort functions. Instead of using that function I must use HAL_OSPI_DeInit then HAL_OSPI_Init. This way it is working with STM32CubeProgrammer. There are source files in https://community.st.com/s/question/0D53W00000pRYKlSAO/custom-external-loader-can-pass-the-test-but-doesnt-work-with-stm32cubeprogrammer

View solution in original post

2 REPLIES 2

ST has similar but different code bases for the ST-LINK Utilities and STM32 Cube Programmer.

I have lodged several complaints/bug-reports against these, and especially with H7 support in the .ELF loader and the calling of the wrong Init() address. ie flips into using 0x20000000 address space when loading into the 0x24000000 one.

The Keil implementation that the loader interface was lifted from is a lot more reliable.

The Init() function has undocumented call parameters, and ST's incessant switching between direct and mapped modes is highly problematic, causing a lot of instability.

My recommendation would be to use the SPI_FLASH model, stay in direct mode, quit resetting the RCC/QSPI on each entry, stay in direct mode, implement the Read() function, and avoid the HAL..

Watch also for the expectation for R9 to reflect the base of the statics for address independent .ELF DLL's, which the loader fails to honor, but several supplied .STLDR expect. A loader should not need interrupts, a vector table, or HAL_Delay() dependent on a SysTick (watch also timeouts and infinite loops the HAL drags in)

#HugeFusterCluck

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
kb24
Senior

There were two different Loader_Src.c files of ST on GitHub. I thought those were same and I used first one. In that file there are many HAL_OSPI_Abort functions. Instead of using that function I must use HAL_OSPI_DeInit then HAL_OSPI_Init. This way it is working with STM32CubeProgrammer. There are source files in https://community.st.com/s/question/0D53W00000pRYKlSAO/custom-external-loader-can-pass-the-test-but-doesnt-work-with-stm32cubeprogrammer