Skip to content

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:

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

Built-in algorithms

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

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.

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:

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

Save and reopen test

The simplest integrity test:

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