2022-06-09 01:08 AM
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!
Solved! Go to Solution.
2022-06-09 04:19 AM
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
2022-06-09 01:58 AM
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...
2022-06-09 02:01 AM
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
2022-06-09 02:01 AM
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.
2022-06-09 02:06 AM
"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?
2022-06-09 02:09 AM
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?
2022-06-09 02:12 AM
@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"
};
2022-06-09 02:17 AM
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
2022-06-09 02:39 AM
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.
2022-06-09 02:43 AM
"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!