Why STM32CubeIDE and STM32CubProgrammer generated different hex files size

[Ganesh-K-Grg]

STM32CubeIDE generates the hex file from elf file using below command.

arm-none-eabi-objcopy -O ihex ${ProjName}.elf ${ProjName}.hex

But when i use the STM32CubeProgrammer, it generates the hex file which is smaller than that of STM32CubeIDE hex generate file.

I wonder what arguments are used in "arm-none-eabi-objcopy" to match the hex file that generated by STM32CubeProgrammer.

[Andrew Neil]

How much smaller?

Did you compare the 2 Hex files - what was/were the difference(s).

Note that there are many different ways to represent the same binary using Intel Hex format - this is why it's generally  best not to try to build an embedded Hex reader!

PS:

Another example of why not to try to build an embedded Intel Hex reader:

https://community.st.com/t5/stm32-mcus-embedded-software/stm32-xmodem-protocol-hex-file-parsing/td-p/734917 

#IntelHex

[Ganesh-K-Grg]

Hi Andrew,

From STM32CubeIDE hex is 325KB and from STM32CubeProgrammer is 277KB. Yeah I compare it and most of the data were different.

One of the different I notice is that the "gap fill" is zero from STM32CubeProgrammer but from STM32CubeIDE is 0xFF. 

The reason i asked is that the hex file that generated from STM32CubeIDE did not run properly but OK from STM32CubeProgrammer generated hex file.

So i am curious about the reason behind it. From my understanding is no matter we generated from STM32CubeIDE or STM32CubeProgrammer, it should be OK but not.

[Andrew Neil]

I guess the 'gap fill' could make a difference - especially if you're not doing a full chip erase before programming?