Verification¶

After you change a ROM the ECU will still load it, but it may fail safety or emissions tests. Verification does two things: it proves your data landed in the right place, and it recalculates the checksum areas.

What is a checksum?¶

Many ECUs carry an integrity value over their code and data blocks, either inside the block or at its end. If that value does not change, the ECU assumes nothing was modified. Writing invalidates it; if you do not correct it, the ECU makes that decision for you (usually by entering a limp mode).

Verify and correct¶

Project ▸ Verify Checksum checks every block for the selected algorithm. Project ▸ Correct Checksum recomputes the blocks that fail.

Workflow:

Select your ECU type.
Run Verify; the failing blocks are listed.
Make your map edits first and run the checksum correction last — otherwise the checksum becomes invalid again.
Verify once more after correcting.

The checksum dialog¶

Project ▸ Verify/Correct Checksum opens a WinOLS-style table window:

Column	Meaning
`#`	Row number
`Algorithm`	Algorithm name
`From` / `To`	Covered address range
`Manually`	Manually added entry
`AutoCorr.`	Automatic correction enabled

Buttons: Search (re-detect on this ROM), Add… (manually add an algorithm from the installed list), Properties… (details of the selected entry), Delete (remove a manually added entry), Apply (recalculate checksums in memory) and Installed plugins… (installed checksum modules). Apply produces a single undo step, and — as the note at the bottom of the dialog says — checksums are recalculated automatically at export.

The Checksums panel and status bar¶

Project ▸ Checksums (or View ▸ Checksums) opens a persistent dock on the right (hidden by default). The panel auto-detects the active ROM and shows one row per checksum engine (native Specs first, then DLL algorithms):

Column	Meaning
`#`	Row number
`Algorithm / Engine`	Algorithm or engine name
`Family`	Matched ECU family
`From` / `To`	Covered address range
`Status`	`ok` / `mismatch` / `unknown`
`Correctable`	Whether this row may be corrected safely

Verify only computes; it never touches the ROM.
Correct & Apply rewrites only the correctable rows and commits them all as a single undo step.
Refresh re-runs detection; the panel refreshes itself (debounced) when the project changes or the ROM is edited.

A WinOLS-style live readout sits at the right of the status bar and updates after edits:

All CS ok — Checksum block N: okay — every block is valid,
CS mismatch — N issue(s) — a mismatch exists,
No checksum module — no engine for this family,
CS: unknown (no definition) — an engine exists but the family has no definition.

Automatic correction at export¶

With Project ▸ Correct checksums on export (checkable) enabled, every detected checksum block is corrected automatically when a ROM is exported — on the exported copy only; the project ROM is never modified. When it is off, the application asks whether to correct before writing.

Every ROM export is preceded by a preview dialog showing the file name, the size and the current checksum state — valid, invalid — will be corrected on export, invalid — you will be prompted to correct it or cannot be verified. If no algorithm is detected the correction is skipped and a status-bar warning is shown; the export is not blocked.

Family definitions and the "could not be verified" state¶

The final pre-export check also consults the optional ECU family checksum catalogue (data/ecukb/checksum_families.json), which maps an ECU family to a human-readable algorithm hint. The application distinguishes two cases:

Algorithm known but not detected — the catalogue has a hint for the family; the export proceeds and Correct Checksum… is suggested.
No family definition — there is no catalogue match; the checksum is flagged as could not be verified and the ROM is exported unchanged. You must verify the checksum yourself before flashing.

When the catalogue is absent this distinction cannot be made and the feature silently disappears; the export is still not blocked.

Built-in (native) checksum engine¶

The application ships a config-driven native checksum engine that needs no DLL. The family-to-algorithm mapping is read from data/ecukb/native_checksums.json (produced by tools/dataset/build_native_checksums.py). The engine supports additive (Sum8/16/32), XOR and CRC kinds (CCITT/IBM/IEEE plus custom parameters).

Native first, DLL as fallback: when a family has a native definition the native engine is tried first; with no definition the Windows module library is used.
Safe correction: the native engine writes only for Specs marked correctable whose blocks fall inside the ROM; for an unknown family verification returns known=false and no byte is changed.

Bosch MED17/EDC17 verification and correction are also embedded; no DLL is required. Every other family uses the Windows module library.

Checksum coverage¶

Family-to-algorithm knowledge has been enriched through WinOLS checksum modules, Ecus.txt/Modelle.txt, FTAG and web research. Current coverage: 152 families (checksum_families.json), 113 WinOLS families (winols_checksum_families.json) and 13 native algorithms (native_checksums.json). The coverage data is optional; without it the readout says "no definition" (see DATASET_SETUP.md for setup).

The 148-module Windows library¶

ChecksumDLL/ contains 148 32-bit modules. They run on 32-bit Windows and are invoked from the 64-bit application through the checksumhelper.exe helper process.

Required runtime

The modules depend on the Microsoft Visual C++ 2005 SP1 (x86) runtime. Without it they fail to load, and the application reports that explicitly.

The modules only work on Windows; on Linux and macOS only the built-in MED17/EDC17 path is available.

Why a separate process for loading a module?¶

checksumhelper.exe is a 32-bit helper. ROM data travels between the two processes through temporary files, which lets a 64-bit application run a 32-bit DLL without loading it into its own address space.

Version Overview (version comparison matrix)¶

View ▸ Version Overview… opens a matrix whose rows are maps and whose columns are versions: each cell shows how many bytes of that map changed in that version relative to the original. The version selector + note row at the top edits the comment (note) of each version. Project ▸ Save Version Snapshot… generates the note automatically — summarising how many maps and bytes changed in the form "N map(s), M byte(s) changed"; you can edit it freely afterwards.

Accept changes (transfer operations from another project)¶

Project ▸ Accept Changes from Project… transfers edits from another .mtrp project into the current one. Matching is done by value pattern, not by address, so operations are applied location-independently even when the source project's maps sit at different addresses.

Watermark (digital signature)¶

Project ▸ Sign ROM (Watermark)… embeds an invisible ownership signature into the ROM's largest empty (0x00/0xFF) region; it changes neither normal reading nor driving behaviour. Project ▸ Verify Watermark finds and verifies the signature, so you can later prove that a file came from your bench.

Processor detection¶

Miscellaneous ▸ Detect processor… scans the ROM for known signatures and reports a CPU-family estimate with a confidence percentage. It is a quick pre-check to confirm the ECU family before picking a checksum algorithm.

Always cross-check externally¶

Treat the application's result as one opinion among several:

the ECU vendor's own tool set,
the manufacturer's checksum/validation software,
dyno and emissions test results.

Even if the application reports success, wrong address matching makes the whole chain meaningless. The weakest link in verification is not the checksum — it is address matching.

A2L base address verification¶

Addresses in an A2L file are relative to a base address. With the wrong base, maps open in the wrong place and checksum verification will not notice. On the first run:

Compare an address you know with the A2L value.
Confirm the ROM holds meaningful data at that address.
Correct the base address list manually if necessary.

Save and reopen test¶

The simplest integrity test:

Save your changes.
Close the project.
Open the file again.
Run Verify and check the values in the maps you edited.