What the validator checks
Every non-empty line is checked for an S0–S9 type, complete hexadecimal byte pairs, the declared byte count, the address width required by that type, allowed data length, and the ones-complement checksum. S4 is reported as reserved rather than guessed. Valid S1, S2, and S3 payloads are placed at their absolute addresses to identify contiguous ranges, holes, identical overlaps, and conflicting overlaps.
The sequence review checks S5/S6 data-record counts, duplicate control records, control records in unusual positions, mixed data-address widths, and the conventional S1/S9, S2/S8, or S3/S7 termination pairing. An S7, S8, or S9 address is reported as an entry/start address; the tool does not prove that it is executable or valid for the target.
S-record fields and checksum
An S-record begins with S and a type digit. The next byte is the count of the address, data, and checksum bytes that follow it. S1 uses a 2-byte address, S2 uses 3 bytes, and S3 uses 4 bytes. S9, S8, and S7 use the corresponding 2-, 3-, and 4-byte start addresses. The checksum is chosen so the low eight bits of the sum of byte count, address, data, and checksum equal FF.
NXP’s archived Motorola documentation describes the record fields and creation method in Appendix A of the M68HC12A4EVB User’s Manual. The Renesas compiler documentation summarizes the address-width variants and checksum construction.
Binary export choices
Exporting a single contiguous region writes exactly its verified bytes. “All ranges” creates one flat span from the lowest through highest verified address and fills every address hole with the explicitly selected FF or 00 byte. It is capped at 32 MiB to avoid allocating a huge file for sparse addresses. Conflicting overlaps block every binary export; identical overlaps remain visible as a warning.
This follows the useful distinction documented by GNU objcopy: raw binary is effectively a memory dump beginning at the lowest load address and discards metadata. ToolQuill includes the address in the filename, but the raw bytes themselves still do not carry that address.
Safety and trust boundary
A valid checksum means the ASCII record was internally consistent; it does not make firmware authentic, compatible, complete, or safe. The tool does not verify signatures, hardware IDs, linker intent, vector tables, boot configuration, rollback protection, programmer voltage, erase ranges, or device security settings. Compare the image with a trusted release source and the exact hardware/programmer documentation before writing a device.
Frequently asked questions
Why are bad-checksum records excluded from the memory map?
Their payload integrity has not been established. Keeping them visible in the record table while excluding them from reconstruction prevents an apparently clean binary from silently incorporating known-bad data.
What is the difference between S19, S28, and S37?
Those names commonly indicate files centered on S1/16-bit, S2/24-bit, or S3/32-bit data addresses, respectively. The parser follows each line’s actual record type rather than trusting the filename extension.
Are gaps automatically filled when I analyze a file?
No. Gaps remain explicit in the report. A fill byte is applied only after you choose the all-ranges binary export; exporting one contiguous region never adds gap bytes.
Does this replace a linker, programmer, or disassembler?
No. It validates the transport records and reconstructs bytes by address. It does not interpret machine code, relocation, sections, symbols, or target-specific programming rules.