· ReadyStack
Worked example
Real numbers from this tool, line by line.
Eleven lines of a merged Intel HEX image came back with ten findings, six of them errors — and the build system that produced it had already called the image done. That is the whole problem an embedded firmware engineer has with .hex and .srec files: they are the one artefact in the build that nobody re-reads, because re-reading them by hand is arithmetic over thousands of records.
Here is what it found, verbatim. Line 3 ends in 0x2A; the recomputed two's-complement checksum is 0x28 — a constant was hand-patched and the checksum left behind. Line 4 declares a byte count of 16 and carries 15 data bytes. Line 5 is <<<<<<< HEAD, a merge marker inside a firmware image. Line 6 writes address 0x00000010, which line 2 already wrote, so which byte reaches the flash depends on the load order of the tool. Line 9 names an entry point of 0x00000800 that no record ever writes, so the device jumps into unprogrammed flash. Line 11 is a data record sitting after :00000001FF, which no conforming loader will read — the classic way to ship a fix that never reaches the device.
None of that is exotic. Every one of those defects is what a merge, a last-minute patch, a script-generated image or a file mailed to a contract manufacturer leaves behind. The programmer at the flashing station is where you normally find out, and by then the boards are on the bench.
The extension runs 17 checks. It recomputes the two's-complement checksum of every Intel HEX record and the 0xFF-minus-sum checksum of every Motorola S-record from the record's own bytes; it compares every byte-count field with the data present; it validates record types, S-record count bytes and terminators; and it maps every absolute address the image writes, honouring type 02 and type 04 extended-address records, so it can report overlaps, unwritten gaps, data past 0xFFFF with no extended-address record in effect, blocks that straddle a flash page, and an entry point outside the image. Findings land in the Problems panel at their line.
The seventeenth check is new this month and it is not about the bench at all. An S-record image can carry an S0 header record naming the module (char[20]), its version and its revision. The format makes S0 optional and plenty of toolchains emit it blank — harmless while the image is on your desk, expensive once it is in an archive, because nothing ties the file back to the release it belongs to. Under the EU Cyber Resilience Act, Article 13(12), a manufacturer keeps the technical documentation at the disposal of market surveillance authorities for 10 years after the product is placed on the market or for the support period, whichever is longer, and the reporting obligations have been in force since 11 September 2026. An unidentifiable image is a record you cannot produce.
Auditing one image is free and complete: all 17 checks, no key, nothing truncated, no watermark and no counter, either in VS Code or in the browser, where the same rules run on your machine and the image is never uploaded. The licence buys a different job, not more checks: sweeping every matching image in the build folder in one pass and writing a dated Markdown audit report you keep as release evidence.
Freelance embedded software engineers average $104 an hour and firmware consultants $105, on crowdsourced rates collected through June 2026. One hour of one of them re-reading one image costs more than the licence, which is $29 once, per person or CI seat.
15 seconds — what it actually does
Questions people ask
What does the Intel HEX & S-record Image Audit actually do?
It reads a .hex, .ihex, .s19, .s28, .s37, .srec or .mot file and runs 17 checks over it. It recomputes every Intel HEX and S-record checksum from the record's own bytes, compares every byte-count field with the data present, and maps every absolute address the image writes to find overlaps, gaps, page-straddling blocks and a stray entry point.
Who is the Intel HEX & S-record Image Audit for?
Embedded firmware and release engineers who produce or receive .hex and S-record images: anyone who merges a bootloader with an application image, hand-patches a constant at the last minute, regenerates an image from a script, or mails one to a contract manufacturer. Also for whoever now archives each shipped image as a dated record for an EU market.
Why is srec_cat or objcopy not enough?
They read these formats and will tell you a file is malformed, but they generally stop at the first record they cannot parse and hand you a parse error, not a list. They do not name every bad record, overlap, gap and page-straddling block at its line, and they leave you no dated report to archive.
What is free and what needs a licence?
Auditing one image is free and complete: all 17 checks, no key, nothing truncated, no watermark, no trial counter, in the editor or in the browser. The licence covers a different job — sweeping every image in the build folder in one pass and writing a dated Markdown report you keep.
What would reviewing an image by hand cost instead?
Freelance embedded software engineers average $104 an hour and firmware consultants $105, on crowdsourced rates collected through June 2026. Reading one merged image record by record is an hour of that, and it is an hour nobody budgets, which is why the image ships unread. The licence is $29 once.
Why not just ask ChatGPT or another AI chat?
A general AI chat answers from training data with a cutoff date, cannot read your repository and names no rule version. Intel HEX & S-record Image Audit checks the file you open against 17 rules from a rule set dated 2026-09-21, and points at the exact line. For a filing, an audit or a client you need that dated result on your own files.
Ask about this tool
One question, answered by the person who built it. Your email only if you want the answer sent.