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
