Firmware Handoff DeskINTEL HEX · READ-ONLY BYTE ADDRESSES

RELEASE REVIEW WORKSPACE

From HEX records
to a clear handoff.

Check two build artifacts, inspect their sparse addresses, and document exactly what changed.

Bytes, not device conclusions.

No device connection, firmware modification, execution or flashing. No signature verification or safe-to-flash assessment.

Start with two Intel HEX files, or explore the original demo.
REFERENCE BUILD

Baseline

No file selected

PROPOSED BUILD

Candidate

No file selected

Original bytes stay intact.

Files remain in this tab’s memory. No uploads, telemetry, URLs or persistent browser storage contain your firmware.

Per file: 1 MiB raw · 32,768 records · 262,144 mapped bytes

No analysis yet

Every byte has a source.

Your record checks, address map and handoff will appear here.
Unknown gaps stay unknown.

WORKING NOTES

Know what this desk checks.

Format & interpretation

Supported record types: 00 data, 01 EOF, 04 extended linear address and 05 start linear address. Types 02, 03, unknown types and 32-bit wrapping are unsupported and block the whole-file pass and diff.

Checks cover syntax, byte counts, checksums, type-specific length, zero address fields, EOF, content after EOF, duplicate bytes and conflicting entry records. Same-value duplicates warn; different-value overlaps block. A passing checksum is not proof of authenticity.

Maps, regions & hashes

All addresses are file byte addresses, not device word addresses. Intervals are [start, end-exclusive); the last included address is end − 1. Holes are unknown, never assumed 00 or FF.

Allowed and reserved regions are your assertions, not a verified chip memory map. Reserved ranges take precedence. Overlapping allowed/reserved rules are marked as conflicts. Missing allowed regions mean no allow-list constraint.

File SHA-256 covers the original raw bytes including line endings. Map SHA-256 covers sorted address/byte pairs only, excludes entry metadata, and is withheld for blocked files. Same map does not mean same file or same entry record.

Privacy, backups & offline use

Parsing, hashing and exporting run locally. No third-party fonts, CDN, analytics, paid API or firmware network requests. Hosting serves the public app; its request logs may include page requests, never imported content.

Manifest, range CSV and printable HTML omit firmware bytes. Full backup explicitly includes both original files in base64; keep it private. Original-file downloads reproduce imported bytes. This tab forgets the project when closed or reloaded; export a backup to resume.

Once loaded, this tab works offline. Fresh offline navigation is not supported. External source links only open when you follow them.

Limits & alternatives

Limits are enforced before full analysis: 1 MiB raw per file, 32,768 nonempty records, 262,144 unique mapped bytes, 64 regions, 3,000,000-byte restore file. Record and map tables are paged; diff examples show up to 100 bytes. Full exports include all range summaries.

Tested at the 262,144 mapped-byte ceiling with synthetic 255-byte data records. Timing and device details are in the source archive’s QA notes. Larger files are rejected, not silently truncated.

SRecord is a mature free alternative for file manipulation, comparison and summaries. Microchip’s post-build example describes HexMate processing. This desk’s smaller setup burden and readable handoff are a product hypothesis, not a proven market or paid-feature advantage.

Format reference: SRecord Intel HEX specification. This desk does not reproduce HexMate’s firmware editing or device-specific interpretation.