cancel
Showing results for 
Search instead for 
Did you mean: 

Flashing ELF with stm32cubeprogrammer flashes garbage before image

Rami Rosenbaum
Associate II

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:

0693W000007BZ8UQAW.jpg 

1 ACCEPTED SOLUTION

Accepted Solutions
Houda GHABRI
ST Employee

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

View solution in original post

14 REPLIES 14
Houda GHABRI
ST Employee

Hi @Community member​ ,

Sorry for the delay.

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

Houda

Rami Rosenbaum
Associate II

Can't delete this...

Within the ZIP.

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

Thanks.

Houda GHABRI
ST Employee

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.

0693W000007Cc9QQAS.pngCan you please regenerate the elf file and check the start address in CubeProgrammer GUI?

Houda

Pavel A.
Evangelist III

@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:

0693W000007CcgCQAS.png 

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

The hex file parses correctly:

0693W000007CchKQAS.png 

-- pa

 (tested on ver. 2.6.0)

This is exactly my point.

Thanks for your time.

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...

@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.

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

Hi,

I thought about that, so I set the FLASH start address back to 0x08000000.

The ELF file starts with 0x75, 0x45, 0x4C, 0x46 (.ELF), like any ELF-file, but this time STM32CubeProgrammer knows to parse the ELF correctly and displays the data at address 0x08000000.

It is not being loaded as a BIN-file.