Understanding Hex file formating :(

[rodrigoruiz1230]

Hi community :)  today for you I'm Shirley

Im using a STM32F411RE, a SIM7600G and a external eeprom 24LC1025.

The SIM7600G will make requests to a web server where HEX files will be stored for the MCU firmware update. However, I noticed that initially, it sends 16 bytes of data, but at some point, it starts sending 8-byte data packets.

Would there be any issue if I adjust this behavior by concatenating the data packets in groups of 16 so that I can receive them packet by packet through the SIM7600G? Then, after performing a checksum verification, I would write the data to the external memory, after that i would enter Bootloader mode and write the data to the Flash mem.

Here's an example, in the highlighted line says that 8 bytes should be writen in address 08004190h and after that of the next 16 bytes, another 8 bytes should be writen in the same address, the leftover are stored in the next address.

[KnarfB]

Intel HEX - Wikipedia

> 8 bytes should be writen in address 08004190h

correct

> next 10 bytes,

10h = 16

> another 8 bytes should be writen in the same address

no, the address (offset) part is 4198h which perfectly fits next.

hth

KnarfB

[rodrigoruiz1230]

Alright, I understand what you're saying, thanks for your response @KnarfB .

Could you explain if it is possible to concatenate the data packets in groups of 16.

[KnarfB]

I don't see a reason why that happened, but it seems to be legal. Don't know the details of all the components and software involved. Sorry, but I cannot help here.

KnarfB

[Tesla DeLorean · Accepted solution]

Yes, you can generally concatenate, or 0xFF fill voids.

.HEX files can be non-linear and sparse.

On the STM32 side you might only need 4-byte alignment for the FLASH words, some models need 8

From the Linker side the discontinuities may relate to section boundaries, ie first portion is the vector table, and latter part is the rest of the code. Looking at the .MAP file might be indicative of what the linker is creating. You could perhaps also use OBJDUMP to inspect the construction of the .ELF