Flashing ELF with stm32cubeprogrammer flashes garbage before image

[Rami Rosenbaum]

Hi,

I'm working on the STM32L476-Discovery board, Win10 host.

I created a simple application, which works.

Now I changed the start of the address to 0x08001000:

MEMORY
{
 FLASH (rx) : ORIGIN = 0x08001000, LENGTH = 1024K
 RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 96K
}

I erase the board (validating 0x08000000 is 0xFF, 0xFF...).

Now I flash my ELF:

STM32_Programmer_CLI.exe -c port=SWD -d .\build\TestAppMin.elf

Looking at address 0x08001000 - the application data is correct.

But, looking at address 0x08000000 I don't have 0xFF anymore... I have the beginning of the ELF file - see image:

 

[Houda GHABRI]

Hi @Community member​ ,

Sorry for the delay.

Can you please send me your ELF file to reproduce the issue?

Houda

[Rami Rosenbaum]

Within the ZIP.

Simply open it in the STM32CubeProgrammer GUI app' - it is visible, addresses 0x08000000-0x08000FFF.

Thanks.

[Rami Rosenbaum]

Can't delete this...

[Houda GHABRI]

Hi @Community member​ ,

The elf file you sent is starting from address 0x8000000 so it is normal to have such result (data in address 0x8000000).

It seems that address is not modified in your efl file to 0x08001000.

Can you please regenerate the elf file and check the start address in CubeProgrammer GUI?

Houda

[Rami Rosenbaum]

Hi,

Thanks for the reply.

Reading the ELF via arm-none-eabi-readelf shows that .text starts from 0x08001000.

Also running arm-none-eabi-objcopy.exe -O ihex .\TestAppMin\build-0x08001000\TestAppMin.elf .\TestAppMin.hex gave a starting address of 0x08001000.

According to what do you say that the starting address is 0x08000000?

If I change the linker-script back to 0x08000000, loading the ELF matches the HEX-file...

[Pavel A.]

@Community member​ There's something strange. The elf file should be converted to binary before writing to flash - but in your case it isn't.

Instead of "ELF" signature at 0x08000000 you should see the vectors at your start address 08001000.

When CubeProgrammer opens an elf file, debug messages in the log window should confirm that it correctly parsed the file,

detected code and data sections addresses.

For your file, I see this:

 

So it looks like CubeProgrammer failed to find the text section.

The hex file parses correctly:

 

-- pa

 (tested on ver. 2.6.0)

[Rami Rosenbaum]

This is exactly my point.

Thanks for your time.

[Tesla DeLorean]

@Houda GHABRI​ @Nawres GHARBI​ @Imen DAHMEN​ 

STM32 Cube Programmer not parsing .ELF, loading as if .BIN so including headers, et al

Check if .elf/.ELF naming issue or something basic at file selection/processing code.

[Houda GHABRI]

Hi @Community member​ ,@Pavel A.​ ,@Community member​ ,

You are right !!

STM32CubeProgrammer doesn't parse ELF file correctly.

I parse your file with ELF parser , it is well constructed and the .txt section starts at address 0x08001000.

Issue is raised to Development team and they are working to fix it as soon as possible.

I will come back to confirm the date of the fix.

Houda

[CSchäfer]

I had the same problem.

The update to STM32CubeProgrammer version 2.10 did not fix the problem.

Instead it introduced another problem that on Windows the STM32_Programmer_CLI must have the .exe file extension written with it to work properly.

However, the problem could be solved by switching from the elf or bin file to the hex file.

The elf file does contain addresses, but the file header is also written out, which seems to be a bug.

Using the bin file also works, but you have to specify the address to write the data to.

Since I want to be able to change the memory allocation in the linker script, I switched from the bin file to the hex file.

[Tesla DeLorean]

Still a problem / issue in 2024, can we get some critical eyes on the situation. Thanks    

https://community.st.com/t5/stm32cubeprogrammer-mcus/flashing-elf-with-stm32cubeprogrammer-flashes-garbage-before/td-p/640835

@STOne-32