How to write plain intel hex to flash?

[gfxfloro]

Hi,

I would like to copy the exact contents of a hex file to the flash memory of my f446 nucleo, complete with byte count, address info ....

Is there any way to do this? Using ST-Link I can only find options to actually flash the hex file or manually alter single hex addresses.

Thanks!

[gfxfloro]

Any pointers on where to look? (preferably on STM32 architecture)

[waclawek.jan]

>Of course, if the Hex needs to be part of a bigger application, it can easily be included as something like

That would require stringification per line. Doable manually, but I assumed this is to be part of an automated translation process.

But maybe there is some appropriate tool for this. And it's trivial to write one; I just pointed out an existing tool.

I don't intend to discuss the merits of this whole thing, it's highly context dependent.

JW

[Andrew Neil]

Recent:

https://community.st.com/s/question/0D53W00001bHRzLSAW/is-there-any-official-example-code-for-device-firmware-update-over-usart-for-stm32-mcu

[gfxfloro]

Thanks for the link

So it seems implementing the Application Note is the preferred way here. I figured by transferring just the hex file I could avoid having to implement the protocol overhead.

[Andrew Neil]

you'd still need some sort of protocol to transfer the file.

Then, having transferred the file, you'd also need to implement decoding the Intel Hex format - which, again, is a non-trivial exercise with lots of pitfalls and traps for the unwary.

[waclawek.jan · Accepted solution]

Concocted a simple utility for this. Convert your eo.hex file into eo_sample.hex by running

stringify.exe eo.hex eo_sample.hex

Usage is then

const char * eo_sample_hex = 
  #include "eo_sample.hex"
;

JW

[gfxfloro]

out of curiosity could you give me some examples of these pitfalls?

to me it looks to be quite straight forward, having the number of bytes defined, the address and the data with a checksum. not having done this before it seems all the info is there to write all necessary data to flash

[Andrew Neil]

the commonest one is to assume that the records will be in order - this is not guaranteed, and there certainly are tools that produce out-of-order records

[Tesla DeLorean]

The data may be sparse, and not aligned suitably for the MCU's flash line widths.

The Intel/Motorola HEX files are also quite inefficient, typically consuming around 2.5x the data they actually describe.

Hex data in this form can readily be regenerated from binary blobs.

More efficient binary packaging, ie object file format, can be seen in the .DFU format which includes address and size information, as well as a CRC to check integrity.

Firmware images can also be signed with checksums, CRC, HASH or cryptographically (elliptic curve)

[Tesla DeLorean]

We do seem to have gotten to a generation of developers who don't really understand file content and data representation in memory.

May be there's some books on Linkers, Loaders, Assembler and Compilers..