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:

 

[Pavel A.]

No, not a naming issue. 3rd party elf parsers understand the elf file sent by the OP and show that .text starts at VA 08001000, .data at 20000000 and other usual sections.

-- pa

[Houda GHABRI · Accepted solution]

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

[Tesla DeLorean]

@Pavel A.​ "naming issues" relate to a whole class of application level failures, including upper/lower case, spaces or control characters in name or path, non-English characters, paths too long, etc.

There's some logic failure here, and my post is there to serve as a flagging to a SW QA person about the type of thing I'd go looking for, and the sort of regression testing I'd do.

The goal here is to get something substantially more bullet-proof than what's been delivered to date.

[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