Checksum procedures must match the ECU's exact software, memory layout, file format and programming path. This guide sets out a way to establish the evidence and validate the result; it does not assign undocumented offsets or algorithms to an ECU family.
Identify the file before calculating
- Record manufacturer, ECU hardware and software numbers, calibration ID, read tool and mode, file length and whether it contains a full flash, a calibration slice, EEPROM or a vendor container. Preserve the original and record a cryptographic file hash.
- Determine address mapping, gaps, padding, byte swapping, headers, compression or encryption from documentation for that exact format. A byte offset in a file is not necessarily the CPU address. Do not assume a partial file begins at address zero in ECU memory.
- Use the appropriate tool to check the original. A failure can mean an unsupported variant or layout, incomplete read, wrong parameters, an already modified file or corruption. Do not treat it as permission to repair blindly.
For an unwrapped contiguous slice only, file offset = ECU or full-image address minus the slice's base address. Example: a slice beginning at 0x70000 maps full-image address 0x70020 to slice offset 0x20. Containers, gaps and rearranged blocks need their own mapping. The MS43 reference records this example for its documented calibration range.
Build a check inventory
For each block document source evidence, start and end, data width and byte order, algorithm and parameters, expected stored field, whether included, excluded or substituted, and which checks contain that field. Record any duplicate or inverted value and check-table metadata. A region table in the image is evidence only after its interpretation is validated. If a partial file omits required bytes, a full-image check cannot be verified from it alone.
Compare a known original with documented reference behaviour and, where available, another independently produced result. A match on one image is useful but not conclusive: different algorithms or ranges can coincide. Test representative known-good images and controlled edits to copies; record which checks respond. A single changed byte outside a region might not affect that region's check, while a compensating change might mask a change. Only make ECU-specific claims once coverage and algorithm are supported by evidence.
Plan correction order
Map dependencies: if a checksum field sits inside a second protected region, updating the first changes the second's input. Finish calibration and metadata edits first, calculate inner blocks, then enclosing checks, subject to the format's actual rules. A format may have separate application, calibration, boot, compatibility or signature checks. Avoid assuming that correcting one check repairs the others.
EVC describes a compatibility-test structure linking program and calibration blocks on EDC16/17, and notes variant differences. EVC FAQ. Verify what the specific module and writer actually handle; automatic correction in one tool may occur on export or during programming and may differ by protocol. EVC WinOLS software information.
Documented examples and scope
- Bosch ME7: the ME7 workflow distinguishes checking from correction and records the source's ME7Check and ME7Sum tools. Confirm exact image support and writer behaviour.
- Siemens MS43: the MS43 page records CRC16 and additive monitoring checks, with monitoring corrected before enclosing CRCs, citing the MS4X reference. This is not a generic rule for all Siemens/Continental ECUs.
- Siemens MSS54/MSS54HP: the MSS54 page records a specific partial extraction and stored-check offsets. The project's checksum helper documentation supports 32 KiB MSS54 and 64 KiB MSS54HP partials, not full 512 KiB files. Verify actual ordering and tool version. The helper's compensation concept must not be transferred to a different file format without proof.
Verify and keep a record
- Preserve original, edited and corrected files separately. Record hashes, tool and module versions, exact options and reports.
- Check the original and corrected files with a supported independent implementation where possible. Compare the edited and corrected files at byte level and explain all changed fields. Recheck after any later edit.
- Establish supported power, interface, programming and recovery arrangements for the exact ECU. A partial calibration read is not necessarily a recovery backup. Follow the writer's handling of checksums, avoiding assumptions about double correction.
- After programming, follow the supported verification process, check diagnostic status and confirm the intended identification. Where supported, read back and compare the applicable region, accounting for documented writer transformations. A checksum pass does not validate calibration values or vehicle behaviour.
When a check fails
First verify correct file and complete range, mapping, block order, field treatment, sum width and byte order. For CRCs verify polynomial representation, initial state, reflection and final XOR. Check for multiple layers, duplicated values, compatibility metadata and corrections that were applied in the wrong order. A correct check can coexist with a failed signature or incompatible program/calibration. Do not force a candidate value into an unknown field.
Sources are linked alongside claims. This is a source-scoped editorial workflow, not a report of hardware testing; checked 10 November 2026. See principles and correction for worked arithmetic.