Intel HEX Parser

The shape of a record

An Intel HEX file is a list of records, one per line, in a format that has barely changed since the 1970s:

:LLAAAATT[DD…]CC

The checksum is the two's complement of the sum of every preceding byte, which means a correct record sums to zero modulo 256 including the checksum. That property makes verification trivial and is why a single flipped bit anywhere in a line is always caught.

How 16 bits address 32-bit flash

The address field is two bytes, so a data record can only reach 64 KiB on its own. Extended address records close the gap by setting a base that later data records are placed on top of:

• Type 04, extended linear address. Its two data bytes become the upper sixteen bits of a 32-bit address. A record of 0800 sets the base to 0x08000000, which is where STM32 flash lives — hence the pattern at the top of almost every STM32 hex file.
• Type 02, extended segment address. The older scheme, from 8086 segmentation. Its value is multiplied by sixteen rather than by 65536, so it reaches 1 MiB rather than 4 GiB.

A base stays in effect until another extended record replaces it, which is why a file that reaches across a 64 KiB boundary repeats the record. Reading the address field without applying the active base is the most common way to misread one of these files, and it is exactly the mistake that makes a bootloader appear to sit at address zero.

What the region view is for

The individual records rarely matter. What matters is which addresses the file actually programs, and that is only visible once every record is resolved and the contiguous stretches are merged.

Two things worth checking every time. Gaps are addresses the file does not touch, which a programmer leaves holding whatever was there — fine when intended, and a sign of a missing image when not.Overlaps are addresses written twice, which almost always means two builds have been concatenated by accident; the surviving value then depends on the programmer rather than on anything in the file.

Reading a failure

A programmer that rejects a file usually says very little about why. The failures are few and each has a distinct signature:

• Bad checksum. One line was edited by hand or corrupted in transfer. The tool above shows both the stored and the expected value, and the difference often identifies which byte changed.
• Byte count disagrees with the data. A line was truncated, usually by a mail client or a copy that clipped at a column boundary.
• No end-of-file record. The file was cut short. Anything after the last valid record is missing, and a programmer may still write the part it did receive.
• Records after the end-of-file record. Two files concatenated. The second image is almost certainly being ignored.

Related formats

Motorola S-record encodes the same information with a different record layout and a checksum that is a one's complement rather than a two's complement. ELF carries far more — symbols, sections, debug information — and is what a linker produces before objcopy reduces it to one of these flat formats.

To check an image against a published checksum once you have extracted it, theCRC calculator covers the standard polynomials, and thehex converter handles individual values pulled out of a record.