CRC Checksum Algorithms in Hexmate

Checksums can be used to verify that code programmed into a device is a valid copy of the original image. This page shows you how to use Hexmate to calculate a checksum over a range of addresses in a HEX file and have that value verified in an MPLAB® XC8 project. The examples given will work on any PIC18 device.

A checksum is a small value calculated from and used to represent all the values in a block of data. If that data block is copied, a checksum recalculated from the new block can be compared to the original checksum. Agreement between the two checksums provides some sort of guarantee that the copy is valid. There are many checksum algorithms. More complex algorithms provide a more robust verification but might use too many resources when used in an embedded environment.

Hexmate can be used to calculate the checksum of data stored in a HEX file built by the compiler. This checksum can be embedded into that HEX file and burned into the target device along with the program image. At runtime, the target device can run a similar checksum algorithm over the same data in program memory. If the embedded checksum and the checksum calculated at runtime are the same, the program can assume that it has a valid program image to execute.

Hexmate implements several checksum algorithms, such as simple summation algorithms, the versatile Fletcher algorithms, or the more robust Cyclic Redundancy Check (CRC) algorithms. Hexmate options can be specified from the MPLAB X IDE, so you do not need to run this utility explicitly.

Hexmate can be used on any Intel HEX file produced by any MPLAB XC Compiler; however, not all Microchip PIC® devices can read the entire width of their program memory via a C language pointer or array, so to perform checksum verifications on these devices you might also need to implement a routine (which might need to be written in assembly) to read a block of flash memory to obtain the data over which to calculate the checksum. Other PIC devices have no means at all to read the entire width of their program memory.

Non-reflected CRC Example

In this example, the code in our project must first ensure that the program memory range from 0 to 0xFF inclusive is verified before proceeding. To do this, a 16-bit checksum will be calculated at compile time and stored in the HEX file at locations corresponding to the device addresses 0x100 and 0x101.

We will use a CRC algorithm with the following parameters to calculate the checksum. Note this algorithm is sometimes misidentified as CRC-CCITT.

Algorithm Type CRC
Checksum width 16 bits
Polynomial 0x1021
Initial value 0xFFFF
Data/result reflection False

Specify the Checksum Command when Building

The MPLAB XC8 command to generate the required checksum is:


Algorithm #5 will select the non-reflected CRC algorithm. The width is specified as 2 bytes (16-bits) and is negative (-) to format the result with a little-endian byte order, which is the order used by the compiler to store multi-byte C objects. The offset specifies the initial value, here, 0xFFFF. The “0-FF” string specifies the (HEX) address range over which to calculate the checksum; the “@100” indicates the (HEX) address where to store the checksum in the device.

To use this command in MPLAB X IDE, copy all the arguments to the right of the “=“ into the Checksum field found in XC8 Linker > Additional options, as shown.


Verifying the Checksum at Runtime

To help us verify the checksum result, we will first create placeholder objects and typedefs to make the code easier to modify.

The typedefs relate to the width of data that we read (8 bits) and the width of the checksum result (16 bits). Typically data is read as bytes, but you should adjust the resultType to match the algorithm you are using, e.g., unsigned char for 8-bit algorithms, unsigned int for 16-bit algorithms, etc.

The checksumData object will be used to represent the block of data over which we will calculate the checksum; the hexmateChecksum object will represent the checksum result that Hexmate will embed into the HEX file, and which will be programmed into the device.

Since both these objects are extern, they do not consume any memory; and since they are defined as const, they will represent program memory addresses.

Here is a code that can implement a non-reflected CRC algorithm.

It is passed a pointer to the first datum, the number of data to process, and the initial value.

Add this routine to your project and call it as soon as possible after main() executes. Compare the value obtained from this routine with that produced by Hexmate. That might look something like this:

Reflected CRC Example

The crc() function shown in the previous example works on the most significant bit first, i.e., the data bits are considered big-endian. Some CRC algorithms work on the least significant bits first, and you may need to reflect the bit positions of the data to match your algorithm of choice.

The reflected version of the above algorithm can be implemented in several ways. The first is to apply the same polynomial to a reflected copy of the data. The calculated result also needs to be reflected to ensure the correct bit order. The other implementation is to reflect the polynomial and apply that to the original data.

For the next example, we will implement a code that performs a different version of the 16-bit CRC algorithm. Specifically, this algorithm will have the following parameters (see the application note AN752). Note the difference in the reflection specification.

Algorithm Type CRC (MCRF4XX)
Checksum width 16 bits
Polynomial 0x1021
Initial value 0xFFFF
Data/result reflection True

The MPLAB XC8 command to generate the required checksum is:


Algorithm #-5 (note the negative sign) selects the reflected CRC algorithm. The width is specified as 2 bytes (16-bits) and is negative (-) to format the result with little-endian byte order. Note, this is the byte order, not the bit order within each byte as dictated by the algorithm. The other arguments are identical to those in the first example.

Here is a code that can implement a reflected CRC algorithm. A function to reflect bits with a specified data size is also provided.

You can achieve the same checksum using the following code:

Note that in this code the data and results are not reflected, but the polynomial is. The polynomial reflection was made at runtime using the reflect() function, but this can be precalculated. Note also that the direction of the shifts is reversed since it operates in a reverse bit direction.

You could call either of these routines in the same way as we did in the first example.

When implementing a CRC checksum, you need the specifications that have been provided for these two examples, viz.: the checksum width, the polynomial, the initial value, and whether the data and result are reflected. Some algorithms, for example, the CRC-32, require an XOR of the final checksum with a value. This XOR cannot be performed by Hexmate, but you may explicitly XOR the Hexmate checksum. For such algorithms, you will also need to know the value to use for the final XOR.

© 2024 Microchip Technology, Inc.
Notice: ARM and Cortex are the registered trademarks of ARM Limited in the EU and other countries.
Information contained on this site regarding device applications and the like is provided only for your convenience and may be superseded by updates. It is your responsibility to ensure that your application meets with your specifications. MICROCHIP MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WHETHER EXPRESS OR IMPLIED, WRITTEN OR ORAL, STATUTORY OR OTHERWISE, RELATED TO THE INFORMATION, INCLUDING BUT NOT LIMITED TO ITS CONDITION, QUALITY, PERFORMANCE, MERCHANTABILITY OR FITNESS FOR PURPOSE. Microchip disclaims all liability arising from this information and its use. Use of Microchip devices in life support and/or safety applications is entirely at the buyer's risk, and the buyer agrees to defend, indemnify and hold harmless Microchip from any and all damages, claims, suits, or expenses resulting from such use. No licenses are conveyed, implicitly or otherwise, under any Microchip intellectual property rights.