7.2.2 Intel HEX file Specification

Hexmate reads and processes HEX files, in particular, those files conforming to the Hexadecimal Object File Format developed by Intel®. Other forms of HEX files and other file formats cannot be processed by Hexmate. The information in this section describes the HEX file specification, as interpreted by Hexmate when processing input files.

Intel HEX files store binary program data using ASCII characters. One character is used to store each nibble of the binary data, so for example the byte value 0xFE would be stored in a HEX file as the ASCII byte 0x46 (representing the most significant nibble of the value, F) followed by 0x45 (E). If you view a HEX file with a text editor, it will show these two bytes as the characters FE, since it assumes the data is ASCII and maps it accordingly for display. Upper case hexadecimal letters are typically used in HEX files, but Hexmate will accept either case.

A HEX file consists of a number of records, with at most one record per line.

Once a Record Mark has been encountered in a line, it and all the following characters on that line are assumed to be part of a record. The record will be checked for syntactical correctness and any errors will be reported, but with one exception: Should a record following a comment be malformed, then the whole line will be treated as a comment and no errors will be reported.

The Data Length field follows the Record Mark and is a one-byte (two ASCII character) value indicating the length of the Data/Argument field in the record. This specification is required, since the length of the Data/Argument field is not fixed, and it can vary from one record to the next.

A two-byte (four character) Address Offset field follows. If a record is one that contains program data, the value in this field (and potentially information contained in other records) indicates the address at which to start programming the data in the device; otherwise, it is not used and contains the character sequence 0000. The correct Address Offset must be specified with each record that holds data; the location for data cannot “flow on” from any previous record in the file. The mandatory inclusion of an address with each record allows records to be placed in the file in any order, subject to some limitations, described later.

Note that the Address Offset field, as its name implies, specifies an address offset, not an absolute address. The base address to which the offset applies is specified by special record types, discussed later in this section; however Hexmate assumes that this base address is 0 if no such special records have been previously encountered in the file.

A multi-purpose, variable-length Data/Argument field follows the Record Type field for most record types. This field is used to store the data to be programmed for type 0 records, store a base address for type 2 and 4 records, and store a start address for type 3 and 5 records. This field is not present for type 1 records. For type 0 Data Records, the length of the Data/Argument field is permitted to range from 1 to 255 bytes (2 to 510 characters), and this length can vary from one Data Record to the next. The bytes of data in this field assume consecutive addresses, indexed from the first byte, which has the Address Offset specified in the record.

A Checksum field makes up the last byte (2 characters) in the record for all record types and this value is used by Hexmate to minimize the chance of corrupted data being programmed. Record checksums are calculated as an 8-bit two's compliment of the summation of each byte (in its binary form) in that record, starting from the Record Length byte to the last byte in the Data/Argument Field.

:04000000FEEFFFF020

;configured for basic mode
:04000000FDEF0FF011
:0C1FF400B88100EF00F00001FAEF0FF0E0
:00000001FF

:0401FC00E040FEFFE2