2019-11-27 05:28 PM
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
2019-11-27 05:55 PM
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?
2019-11-27 06:36 PM
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