What this Intel HEX workbench validates
Each non-empty record is checked for its colon, complete hexadecimal byte pairs, declared data length, 16-bit record offset, standard type 00–05 structure, and checksum. The checksum is valid only when the low byte of the sum of the length, address, type, data, and checksum bytes is zero. Bad records remain in the audit table but never contribute bytes to the memory map or any regenerated output.
The parser applies type 02 extended segment bases and type 04 extended linear bases to later data records, and reports type 03 and type 05 start addresses. The record fields and addressing behavior follow the Keil Intel HEX format reference and Microchip HEX file specification.
Merging, overlaps, and address gaps
All checksum-valid data bytes are placed at their resolved absolute addresses. Identical overlaps are reported because they may be intentional duplication; differing values at one address are conflicts and block all firmware regeneration. Gaps remain sparse in HEX output. They become bytes only when you explicitly request a flat binary and select FF or 00 fill.
A base shift is a literal signed addition to every output address. The workbench refuses underflow or addresses above 0xFFFFFFFF. A single supplied start address can be shifted and normalized to type 05; multiple or ambiguous entry points remain visible and are not guessed.
How split and regenerated output behave
The split boundary is absolute after the selected base shift. One download contains verified bytes below it and the other contains bytes at or above it. Each generated file uses ascending 16-byte type 00 data records, emits type 04 records when the upper 16 address bits change, recalculates every checksum, and ends with a type 01 EOF record. If either side contains no bytes, the split is rejected rather than creating a misleading empty firmware image.
Firmware safety boundary
A valid Intel HEX checksum proves only record-level arithmetic consistency. It does not prove authenticity, completeness, hardware compatibility, correct linker placement, executable vectors, fuse values, bootloader contracts, rollback safety, signatures, or safe programmer settings. Compare regenerated bytes with trusted release artifacts and the exact device memory map, then verify with the vendor toolchain and programmer before writing hardware.
Frequently asked questions
Why does one malformed record block regenerated output?
Silently dropping a known-bad record could create a clean-looking but incomplete firmware image. Fix or remove the record deliberately, analyze again, and confirm the resulting address map.
Does merge order choose which conflicting byte wins?
No. Conflicts block output. Choosing first-file or last-file precedence could hide a dangerous input error, so the source images must agree or be corrected first.
Why can the flat binary be much larger than the HEX files?
Intel HEX is sparse and records addresses. A raw binary has no address fields, so the tool must materialize every byte between the lowest and highest address. For safety, that span is capped at 32 MiB.
Are comments and vendor-specific record types preserved?
No. This conservative parser accepts standard records 00 through 05 only. Regenerated files contain normalized standard records, not source formatting or vendor extensions.