How EcuPrime checks a tuned file before delivery: donor match, segment check, delivery gate

A tuned ECU file differs from the original in a few thousand bytes out of several million. Producing those bytes is the visible part of the job. The part that decides whether a file should leave the software at all is less visible: what happens when your file is not exactly the file the solution was learned from. This article walks through the checks EcuPrime runs between upload and download, as the software stood on 9 October 2026, with the numbers we measured that day and the limits we know about.

Step 1: the unit is identified from the file

Nothing is applied on the strength of a file name or a form field alone. The software reads the upload and tries to recognise the ECU family from the content of the file, together with hardware and software identifiers where the file carries them. Reads that cannot serve as a base are recognised at this stage too: an almost empty partial read, an EEPROM dump or a full backup that contains more than the flash. In those cases you are told which file is needed instead of being offered operations. The read types are described in our guide to which ECU file to upload.

Identification also sets a hard limit for everything after it. If the unit cannot be recognised, no verification field is written into the file on a guess.

Step 2: donor match

Every solution in the library was learned from a real pair of files: an original read and the modified file made from it. We call the original half of that pair the donor. When you upload a file, the software looks for donors of the same ECU family and compares your file with the donor original, region by region.

Three outcomes are possible.

Your file matches a donor original exactly. The learned change can then be transferred byte for byte.

Your file is a variant: the same family, but a different software version, so maps sit at other positions or hold other stock values. The software can relocate a learned change when the surrounding data confirms the position. When the stock values in your file differ from the donor's, the change is not written. That is a known limit of the current engine, not a rare corner: a file from a software version we have not learned can come back with an operation refused.

No donor fits. The operation is then not offered as a card for your file. A missing card is the honest answer here; a card that looks available and fails later is the thing we are trying to remove.

The same comparison detects work that is already in the file. If an operation has already been applied to the read you uploaded, the card says so and it cannot be ordered a second time.

Step 3: segment check

A learned solution is stored as a list of segments. Each segment holds an address, the original bytes, the modified bytes and a short stretch of context before and after. This is what makes a check possible at write time.

Before a segment is written, the target region in your file is compared with the donor's original bytes. The segment is written only where they agree. A region that looks similar but is not the same map is skipped instead of overwritten. After writing, the output is measured again: how many of the segments of each selected operation actually landed in the file.

This rule costs coverage. It is the reason the variant limit above exists. We keep it because the alternative is writing tuned values on top of data the software does not understand.

Step 4: the delivery gate

The result of the segment check feeds a gate in front of the download. If one of the operations you selected could not be applied, or did not fully fit the file, the job is closed without delivery. The message names the operation, for example: "The selected operation did not fully fit this file ... To avoid giving you a half-processed file, the output was not delivered." Credits charged for that job are returned to your balance.

This gate is used, and we would rather show the figure than hide it. In the 30 days up to 9 October 2026, 12.6% of processing jobs on the platform, our own office jobs included, were closed at this gate instead of being delivered. Half of them were operations that did not fully fit, the other half operations that could not be applied at all. Each of those is a file a customer did not receive, and also a file that did not go into a vehicle half done.

What a delivered file does not tell you

A download is not a statement that everything about the file has been proven. Four limits are stated in the software itself.

Checksum is not part of delivery. The delivered file carries the solution bytes only, and the screen says that the checksum was not corrected. Correction is a separate step in its own tab, and units with modern signed verification need an external tool. The details are in how the checksum workflow runs.

Some results are labelled as preliminary output. When a result was built from a learned pattern instead of an exact donor, it may carry only part of the donor's segments. The gate decides whether the operation landed in your file, not whether every donor segment was carried over. Such a file is delivered with the label "Preliminary output — technical check before flashing", and that label means what it says.

DTC results carry their own warning. Where fault codes were cleared only in the code table, the result is marked "effectiveness not verified": the fault monitoring of the unit was not changed and the warning lamp may still come on.

No file check replaces a workshop check. Keep the original read, keep a full backup made with your tool, and test on the bench or in the vehicle. The software compares bytes; it does not drive the car.

How we check the checks

Gates can break silently, so they are measured against real work.

Every night, past deliveries are produced again with the current code and compared with the file that was delivered at the time, byte for byte. In the run of 9 October 2026, five past jobs were regenerated: four were identical, one differed, and that one was classified as improved because more of the selected operation was applied than in the original delivery. None was worse.

After the release of 9 October 2026 we also ran the offered cards against 40 real files. Of 157 operation cards the software offered, 155 produced a delivered file. The remaining two were stopped at the delivery gate by an independent check. Those two cards should not have been offered in the first place, and closing that gap is open work on our side.

We publish the second number for the same reason the gate exists: a card that fails after you click it is a defect, and the measurement is how we find it.

Where to go next

How the software is put together, from upload to download, is described on the chiptuning software page. To see what it recognises in your own read, create a free account and upload an original file from your tool.