arm-none-eabi-objcopy generates different hex files

[Constantin]

Hi,

I have a makefile generating an elf and then a hex and bin file for a nrf52 project. Now I builded up a zip file for bootloading. Which works as well.

Now in our CI System we checked if we could generate the hex file back from the bin file. This yielded a hex file of the same size but diffent  data. Therefore I tried a simple example. Just directly after building without creating and signing the zip I try to revert the bin to hex. But it still is not the same file. So here are the scripts:

arm-none-eabi-objcopy -O ihex firmware.elf firmware.hex
arm-none-eabi-objcopy -O binary firmware.elf firmware.bin

And then back I do:

arm-none-eabi-objcopy  -I binary -O ihex firmware.bin firmware.hex

The size is the same but the binaries are diffent if I check with a hex editor. And I can definitely not flash it. I do not understand why arm-none-eabi-objcopy is not reversible.

Any hints what I am doing wrong.

C.W.

[Jørgen Holmefjord]

Hi,

Can you elaborate on which parts of the hex-files are different between the commands? .bin files does not contain any information about memory offsets, in comparison to ihex format. If your application is based on nRF5 SDK examples and using a softdevice, the application is typically offset to make room for the softdevice in start of flash. If you don't tell objcopy about the offset, it will likely just place code at the start of the bin file, and then the placement information is lost when converting from bin to ihex.

I tested your commands on my end, and the only difference I can see is that the first line (offset) is removed, and the checksums are different.

Best regards,
Jørgen

[Constantin]

Okay I see. How do I tell objcpy about the offset?

[Sigurd]

Hi!
Try 

--change-start or 

--change-addresses