8.2.3.12 Ck Hexmate Option

The usage of this option is:

-ck=start-end@dest[+offset][wWidth][tCode[.Base]][gAlgorithm][pPolynomial][rRevWidth][sSkipWidth[.SkipBytes]][oXORvalue]

where:

• start and end specify the inclusive hexadecimal address range over which the hash will be calculated. The interpretation of these addresses are based on the addressing value (see 8.2.3.10 Addressing Hexmate Option). If these addresses are not a multiple of the data width for checksum and Fletcher algorithms, the value zero will be padded into the relevant input word locations that are missing.
• dest is the hexadecimal address where the hash result will be stored. The interpretation of this address is based on the addressing value (see 8.2.3.10 Addressing Hexmate Option). This address cannot be within the range of addresses over which the hash is calculated.
• offset is an optional initial hexadecimal value to be used in the hash calculations. It is not used with SHA algorithms.
• Width is optional and specifies the decimal width of the result. It is specified in bytes for most algorithms, but in bits for SHA algorithms. See the Hexmate Hash Algorithm Selection table below for allowable widths. If a positive width is requested, the result will be stored in big-endian byte order. A negative width will cause the result to be stored in little-endian byte order. If the width is left unspecified, the result will be 2 bytes wide and stored in little-endian byte order. This width argument is not required with any Fletcher algorithm, as they have fixed widths, but it may be used to alter the default endianism of the result.
• Code is an optional hexadecimal code sequence that will trail each byte in the result. Use this feature if you need each byte of the hash result to be embedded within an instruction or if the hash value has to be padded to allow the device to read it at runtime. For example, t34 will embed each byte of the result in a retlw instruction (bit sequence 0x34xx) on Mid-range PIC devices. If the code sequence specifies multiple bytes, these are stored in big-endian order after the hash bytes, for example tAABB will append 0xAA immediately after the hash byte and 0xBB at the following address. The trailing code specification t0000 will store two 0x00 bytes after each byte of the hash. The code sequence argument can be optionally followed by .Base, where Base is the number of bytes of hash to be output before the trailing code sequence is appended. A specification of t11.2, for example, will output the byte 0x11 after each two bytes of the hash result.
• Algorithm is a decimal integer to select which Hexmate hash algorithm to use to calculate the result. A list of selectable algorithms is provided in the table below. If unspecified, the default algorithm used is 8-bit checksum addition (algorithm 1).
• Polynomial is a hexadecimal value which is the polynomial to be used if you have selected a CRC algorithm.
• RevWidth is an optional reverse word width. If this is non-zero, then bytes within each word are read in reverse order when calculating a hash value. Words are aligned to the addresses in the HEX file. At present, the width must be 0 or 2. A zero width disables the reverse-byte feature, as if the r suboption was not present. This suboption is intended for situations when Hexmate is being used to match a CRC produced by a PIC hardware CRC module that uses the Scanner module to stream data to it. This feature will work with all hash types, but has no effect when using any checksum algorithm (algorithms -4 thru 4).
• SkipWidth is an optional skip word width. If this is non-zero, then the byte at the highest address within each word is skipped for the purposes of calculating a hash value. Words are aligned to the addresses in the HEX file. At present, the width must be 0 (which disables the skip feature, as if the s suboption was not present) or greater than 1. This skip width argument can be optionally followed by .SkipBytes, where SkipBytes is a number representing the number of bytes to skip in each word, for example s4.2 will skip the two bytes at the highest addresses in each 4-byte word. In hash calculations, to avoid processing the 'phantom' 0x00 bytes added to HEX files for PIC24 and 24-bit instruction set dsPIC devices, use s4.
• XORvalue is a hexadecimal value that will be XORed with the hash result before it is stored.

A typical example of the use of this option to calculate a checksum is:

-ck=0-1FFF@2FFE+2100w-2g2

Note that the reverse and skip features use words that are aligned to the addresses in the HEX file, not to the starting byte of data in the sequence being processed. In other words, the positions of the words are not affected by the start and end addresses specified in the -ck option. Consider this option:

-ck=0-5@100w2g5p1021s2

which specifies that when calculating the hash value, every second byte be skipped (s2) over HEX addresses 0 through 5. If it is acting on the HEX record (data underlined):

:1000000064002500030A750076007700780064001C

the hash will be calculated from the (hexadecimal) bytes 0x64, 0x25, and 0x03 (the two 0x00 bytes are skipped). Processing the same HEX record with an option that uses a different start and end address range (1 through 6):

-ck=1-6@100w2g5p1021s2

If a non-zero skipWidth has been specified for algorithms that process 16 or 32 bits of data per iteration of the hash algorithm, then the skipped bytes are padded with 0 bytes. For example if the HEX record was (data underlined):

:0400000012345678E8

then employing a 16-bit additive checksum (algorithm 2) over this data would normally add 0x3412 and 0x7856. If a skipWidth of 2 was requested, the algorithm would add 0x0012 and 0x0056, since every second byte in the input was skipped. However, if the CRC (algorithm 5), which processes the input sequence one byte per iteration, had instead been selected, the bytes 0x12 and 0x56 will be processed by the CRC algorithm.