Products > Embedded Computing

Computing CRC-16 from .hex file

(1/3) > >>

fearless:
Context: After bootloading a .hex file into our microcontroller, I want to use a CRC to verify that the program memory was properly written.  Therefore, I need to compute the CRC on the host computer prior to downloading the .hex file into the microcontroller.

The goal: given a program on the host computer that takes as inputs:
* a well-defined CRC algorithm (the actual choice of CRC is not important for this question)
* a .hex file that contains binary data to be loaded into the microcontroller, with possibly discontinuous address segments
* a starting address and number of bytes over which to run the CRC algo
... compute the CRC for that memory range.

The question: Are there any techniques or utilities that will help me compute the CRC over that address range from the .hex file?

I initially thought this would be easy: just decode each data byte in the .hex file, if it is within the address range, pass it to the CRC algo.

But then I realized that .hex files can have discontinuous sections, and since the CRC algorithms are sensitive to the order in which bytes are fed to them, out-of-order sections would spoil the computation.

The best idea I've come up with is to allocate an array on the host computer, parse the .hex file and write only those bytes within the target address range into the array.  After the entire .hex file is read, then run the CRC algo other the array. 

How would you handle this?

ataradov:
"Unpacking" the whole file (or just the regions of interest) is the only reliable way. You will also need to synchronize the way you will be filling gaps in your programming algorithm  (likely just keep erased state 0xff).

But the best thing you can do is normalize the HEX file and make sure that it is linear and contiguous.  You can also add CRC in the binary itself at that point, so you don't have to transfer it separately from the file.

This is one of the reasons why I will never use HEX files for anything. They are annoying to parse securely and don't have a standard way to deal with gaps and out of order addresses. They also don't add anything useful, we are not in the 80s anymore and not transferring the files on paper printouts.

Ian.M:
Microchip Technology have a 'Swiss Army Knife' command line utility for manipulating IntelHEX hex files.  It can do CRC16 and insert the result into the hex file. See https://developerhelp.microchip.com/xwiki/bin/view/software-tools/xc8/crc-checksum/
It can also normalise hex files.
The Hexmate utility is bundled with their XC8 compiler (and IIRC also with the MPLAB X IDE).

ataradov:
Hexmate is not that universal. It has not received many updates and fails on some files generated by XC32, for example. I don't know if it will handle well arbitrary chopped up files with many sections.

And it is hard to use if your file includes sections that are not a part of the main program space (like what is described in the original post).

S. Petrukhin:

--- Quote from: ataradov on February 12, 2024, 01:09:26 am --- one of the reasons why I will never use HEX files for anything

--- End quote ---
I've never studied hex/bin in detail, but I'm wondering now - can a firmware image with address gaps be saved in bin?

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod