cancel
Showing results for 
Search instead for 
Did you mean: 

How to write plain intel hex to flash?

gfxfloro
Senior

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!

1 ACCEPTED SOLUTION

Accepted Solutions

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

View solution in original post

21 REPLIES 21

Tell the programmer that it's a binary file?

It's an odd request - if you explain what you're actually trying to achieve, people might be able to give better suggestions...

Treat it as a binary file.

One way to do this is to convert it into C source, using utilities e.g. https://www.segger.com/free-utilities/bin2c/ and then use it accordingly.

JW

gfxfloro
Senior

I would like to simulate transferring a hex file to another uC via SPI or I2C. For this I have set up 2 Nucleos. One which sends the hex file and one to receive. The master in this case needs to have the data in intel hex format.

"transferring a hex file to another uC"

This is (probably) a bad idea.

This means that you are going to have to write an Intel Hex parser in the receiving uC - which is a non-trivial exercise with lots of pitfalls and traps for the unwary.

Why not just transmit the binary?

gfxfloro
Senior

So this is an attempt at IAP. The hex file would be a new firmware.

I figured with the hex info I'd have the destination addresses built into the file and only need to copy accordingly.

I am not familiar with the format of a binary, how would this be possible with a binary?

@Community member​ "One way to do this is to convert it into C source"

I don't think that should be necessary?

As far as the programmer is concerned, a "binary" file is just a sequence of arbitrary bytes - it does not interpret the values, just dumps them verbatim into the target?

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

char hex_file[] = {
":10010000214601360121470136007EFE09D2190140\n"
":100110002146017E17C20001FF5F16002148011928\n"
":10012000194E79234623965778239EDA3F01B2CAA7\n"
":100130003F0156702B5E712B722B732146013421C7\n"
":00000001FF\n"
};

I guess this could work for my test setup, although the addresses have to be known beforehand, while in a hex they are provided as well with the data that should be written.

Edit: also with a binary I don't have the checksum. Admittedly it isn't absolutely failsafe, but a simple and quick way to detect errors

As noted above, a binary is just a verbatim stream of raw bytes; it doesn't really have a "format" at all - the 1st byte in the file just goes into the 1st byte of the target memory range, next byte in the file just goes into the next byte of the target memory, etc, etc...

Of course, this means that you need to separately define where within the Target memory this should start.

That would be handled by your bootloader.

"the addresses have to be known beforehand"

either known, or advised separately somehow.

Your bootloader would handle that - either it always loads to the same location, or it has some way to know where to put the data.

"with a binary I don't have the checksum"

That's another thing that a bootloader should manage.

Sounds like you should study some of the well-known bootloaders - you risk reinventing the wheel here!