Showing results for 
Search instead for 
Did you mean: 

External loader in release-build is not parsing at start-up in CubeProgrammer

Senior II


The DEBUG build version of my custom loader is working but is slow, so I tried RELEASE build instead to hopefully get a smaller bin-file with a faster and more efficient execution.

However, CubeProgrammer fails at startup with a “loading-file-error-message” and in the list of loaders my loader have blank fields of memory size, page size etc (failed to parse…)

What are the reasons for this?

Any compiler settings that should be changed?


I'm not sure objcopy would be much useful in this case; I'd look at readelf or objdump rather.

Nonetheless, the question is, what to look for exactly. I don't use CubeProgrammer nor 'H5, so can't judge.


Hi @Southbranch ,

The DEBUG build version of my custom loader is working but is slow.

Could you please try to use DEBUG with optimization level "Optimize for Debug (-Og)" as mentioned in this discussion.

Thank you.



To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Senior II

Yes, Debug -Og has been tested,

It does works but with same poor performance as standard Debug

What to look for.. well in the offending case it looked like the sections described in the .ELF had memory address overlap, the code, data and bss described areas backed by physical data, or virtual lengths, and then the StorageInfo, which is not physically read or used by the loader code is parked within the file at some location that's common to the aforementioned code,data,bss. I should perhaps make a short app to demonstrate as it was hard to track


Sorry it was U5, but resulted in loader not being pulled into RAM, not that the fields in the "EL" pane were empty. I've seen that in other situations, but usually when the StorageInfo structure wasn't 200 bytes, or mapped poorly


Also the loaders I'm building don't kitchen sink the CubeMX nonsense, Interrupts, Vector Tables, startup / main.

Optimization might be an issue of moving data from memory to registers, although not sure why this would break StorageInfo.

Other considerations for "slowness", use of millisecond delays, or broken timeout loops.

The ST-LINK/V2 implementation is relatively slow due to 12 Mbps USB, the ST-LINK/V3 is orders of magnitude more efficient. Would avoid writing 64MB - 256MB via ST-LINK/V2's, you'll be there for 10's of minutes.

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