Flashing ELF with STM32CubeProgrammer Flashes Garbage Before Image

[Jon Enz]

STM32CubeProgrammer v2.15

I'm having the same issue identified in the following post in the latest (as of now) version of STM32CubeProgrammer: https://community.st.com/t5/stm32cubeprogrammer-mcus/flashing-elf-with-stm32cubeprogrammer-flashes-garbage-before/td-p/154225

Can that discussion be re-opened or an update provided here?

[Tesla DeLorean]

I don't think it's actually closed to new input, but probably helps to start a new thread

@Houda GHABRI  @Nawres GHARBI  @STOne-32 

Not actually garbage, but .ELF header data, not sure if it keys on extension, case, or magic patterns..

[Jon Enz]

It was marked as solved so I just wanted to make sure there was an "open" thread.

[Pavel A.]

@Jon Enz Which toolchain produced your .elf file?

[Pavel A.]

 [removed]

[Aziz BRIGUI]

Hello @Jon Enz ,  

 

For now, I can't reproduce the issue you're seeing with .elf files generated by CubeIDE or EWARM. When relocating an application for an STM32L476 for example, there is a segment in the beginning of the flash, however, this segment has nothing to do with .ELF overhead. I suspect it has to do with jumping to the main application, since removing it will prevent the relocated app from running properly.

As for this thread : https://community.st.com/t5/stm32cubeprogrammer-mcus/flashing-elf-with-stm32cubeprogrammer-flashes-garbage-before/td-p/154225. What I noticed when opening the attachment by @Rami Rosenbaum(using multiple elf parsers/viewers) is that the elf extension overhead is indeed pointed to by a load type segment in the program/segment headers.

 

That's the part interpreted by CubeProgrammer (and several other tools), and usually that's not the case in elf files, here's an example elf compiled with EWARM (with a relocated app).

So as stated by @Pavel A. & @Tesla DeLorean ,we need to know the toolchain you're using in order to investigate further. Attaching the .ELF file could also be helpful.

 

Thanks in advance,

Aziz

[Jon Enz]

The toolchain used to generate the file was ARM GNU 10-2020-q4-major. I can confirm that loading the .hex file shows the data starting at the correct location.

Unfortunately I cannot share the project files directly, but I was able to create a reduced project that produces the same result. The .elf and .hex files are in the build directory of the attached file. You can re-run the build using the following commands.

Configure:

cmake -B build -DCMAKE_TOOLCHAIN_FILE=toolchain-embedded-arm.cmake -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE:STRING=Debug

Build:

cmake --build build --target ELF-TEST.elf