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

[Southbranch]

Hi!

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?

[waclawek.jan]

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.

JW

[KDJEM.1]

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.

Kaouthar

[Southbranch]

Yes, Debug -Og has been tested,

It does works but with same poor performance as standard Debug

[Tesla DeLorean]

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   https://community.st.com/t5/stm32cubeprogrammer-mcus/cubepogrammer-error-on-stm32u545/m-p/601928

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.