Issue with RW Data Initialization in External Memory Loader for STM32CubeProgrammer
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2025-06-20 12:32 AM - edited 2025-06-20 12:35 AM
Hello everyone,
We're currently working on an external memory loader project using Keil, targeting both the Keil FLM Downloader and STM32CubeProgrammer. (We convert the .axf output to .FLM or .STLDR accordingly.)
The flasher is designed to program an application into the external NOR Flash on the NUCLEO-H7S3L8 board using the XSPI interface.
Our work is based on the following reference project:
When we used the loader with the Keil FLM Downloader, everything works perfectly. The loader operates without issues.
However, when we switch to STM32CubeProgrammer, we encountered with RW is not being initialized properly.
We’ve ensured that the relevant RW data region in the scatter file have load and execution addresses set to AXI SRAM (0x24000000).
Despite this, it appears that CubeProgrammer copies the data from AXI SRAM to ITCM (0x00000000).
We believe, CubeProgrammer might be running a some kind of startup code and during that process, the initial values of RW variables are lost.
At this point, we dont know what exactly CubeProgrammer is doing during startup.
What's confusing is that we use the exact same codebase for the Keil FLM loader, and it runs flawlessly.
Any insights, suggestions, or clarification on how CubeProgrammer handles memory initialization and startup routines would be greatly appreciated.
Thank you in advance!
- Labels:
-
STM32CubeProgrammer
-
STM32H7 Series
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2025-06-20 4:33 AM
It loads whatever is described as BITS within the .ELF, dump with FROMELF
There's no Reset_Handler or main, so things must be initialized in Init() whether that means calling __main or ScatterLoad, or simply initializing at limited number of statics explicitly.
The H7 stuff typically loads to RAM at 0x24000004, the first 4 bytes being used by the tool to write a calling method to jump to the assorted entry point functions.
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2025-06-20 9:33 AM
Thanks for the quick response.
Yes, I noticed there are no ResetHandler or main functions. I’ve been handling zero-initialized data with memset, and I also experimented with using __scatterload and defining a custom entry point and main, but none of these helped me so far.
When we provide the AXF output from our Keil project as the STLDR to STM32CubeProgrammer, we still see uninitialized RW data.(ZI is zero initialized as we memset them)
Additionally, I noticed that the STLDR generated from Keil (MDK-ARM) version of the Template-XIP ExtMemLoader project (configured for CubeTarget) doesn't load its own application code (Template-XIP-Appli). I’m not sure if we’re missing something, but now I’m starting to suspect that using the AXF output from Keil as STLDR might not be valid.
Interestingly, when we build the CubeIDE version of the same project, which produces an ELF file, CubeProgrammer is able to load the application successfully.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2025-06-20 12:00 PM
I use GNU/GCC to build .STLDR, STM32 Cube Programmer makes some assumptions about the sections, and doesn't use R9 to point to the data portion in way IAR/KEIL do for position independent modes.
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2025-06-21 3:56 AM - edited 2025-06-21 3:56 AM
Hello everyone,
I’ve been trying to use the STM32H7RS‑CubeFW ExtMemLoader Keil project (with the STM32_EXTMEMLOADER_STM32CUBETARGET target) via the CubeProgrammer CLI, but so far I haven’t been able to make it work in two very specific cases:
Download with --download
I point CubeProgrammer at the ELF produced by the H7RS CubeFW‑template “Appli” project and run:
Stm32_Programmer_CLI.exe --connect port=swd mode=UR --download app.elf -el IDE_KEIL_EXTMEMLOADER_STM32CUBETARGET.stldr -rst
Instead of loading the segments, I immediately get:
Mass‑erase with --erase all
When I execute
Stm32_Programmer_CLI.exe --connect port=swd mode=UR --erase all -el IDE_KEIL_EXTMEMLOADER_STM32CUBETARGET.stldr -rst
Curiously, both of these commands work flawlessly if I switch to:
the ExtMemLoader project generated by STM32CubeIDE, or
the Keil project built with STM32_EXTMEMLOADER_MDKARMTARGET.
I’ve verified that my ELF path is correct and that the device is correctly detected, but I still hit these two blockers when using STM32_EXTMEMLOADER_STM32CUBETARGET.
Has anyone else seen these exact errors? Are there any special linker flags, post‑build steps or options I’m missing that would allow the external memory loader to download and erase correctly?
Thanks in advance for any guidance you can provide!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2025-06-21 9:20 AM
Perhaps generate and attach a Verbose (3) Log?
>>the Keil project built with STM32_EXTMEMLOADER_MDKARMTARGET
So the .FLM ? That works, but the KEIL generated .STLDR does NOT
Up vote any posts that you find helpful, it shows what's working..
