cancel
Showing results for 
Search instead for 
Did you mean: 

Why this difference? ELF vs. binary image

Pavel A.
Evangelist III

Using CubeIDE 1.1 with its default toolchain.

How can be explained the following mismatch between the ELF file loaded to the MCU via debugger and binary file created with objcopy?

(arm-none-eabi-objcopy -O binary foo.elf foo.bin )

I've read the image back from the MCU with CubeProgrammer and compare against the .bin file.

There are two areas of mismatches:

* 8 bytes filler between interrupt vectors and .text. These bytes are skipped by the loader, and remain FFs. But in the binary file replaced with 00. OK.

* Another area consists of multiple 1-byte diffs. All these bytes are loaded as 5C but converted to binary as 2F:

> fc /b read-out.bin foo.bin

Comparing files read-out.bin and foo.bin

........................

0000AD10: 5C 2F

0000AD14: 5C 2F

0000AD18: 5C 2F

0000AD22: 5C 2F

0000AD2D: 5C 2F

0000AD3D: 5C 2F

0000AD45: 5C 2F

0000AD5A: 5C 2F

0000AD5E: 5C 2F

0000AD78: 5C 2F

0000AD7C: 5C 2F

0000AD80: 5C 2F

........

0000B339: 5C 2F

0000B34E: 5C 2F

0000B352: 5C 2F

In the map file these bytes fall in .rodata section of C functions:

.rodata        0x000000000802acc8       0x46 Core/Src/main.o
 *fill*         0x000000000802ad0e        0x2 
 .rodata        0x000000000802ad10       0x66 Drivers/STM32H7xx_HAL_Driver/stm32h7xx_hal_cortex.o
 *fill*         0x000000000802ad76        0x2 
 .rodata        0x000000000802ad78       0x63 Drivers/STM32H7xx_HAL_Driver/stm32h7xx_hal_crc.o
 *fill*         0x000000000802addb        0x1 
 .rodata        0x000000000802addc       0x66 Drivers/STM32H7xx_HAL_Driver/stm32h7xx_hal_crc_ex.o

Why are these bytes different?

-- pa

2 REPLIES 2

One or more of the tools are broken.

The .ELF contains additional metadata not handled the same by those tools.

What should the data be? 0x5C or 0x2F? What does it relate to in use?

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

Stupid me again :(

These bytes are straight slash / vs. backslash \ in filenames (__FILE__) in debug prints.

It appears that in Windows, sometimes file paths are compiled with straight slashes and sometimes with back slashes, or Eclipse passes the filenames so to the compiler. I still don't understand why - and most important, how comes that the binary file is different? Or am I running stale executables?

but this is already a relief. At least, nothing evil.

-- pa