EFC

Why Your ECU File Upload Got Rejected

Your tool said the read succeeded and our checker refused the file. Here is what a valid read actually looks like, why partial reads pass locally, and how to fix it.

10 min readFile service · ECU reading · Troubleshooting
By ECU Flash Cartel · ECU Flash Cartel · US-based · Texas operations

As of September 2026, a file upload gets rejected for one of six reasons, and five of them are about the read rather than the car: the dump is the wrong size, it came from the wrong region of the controller, the tool wrote a header into it, the signature is ambiguous between two masks, the module is signed rather than merely locked, or it is not the module you think it is. An instant file service is $100 for IMMO-OFF and $150 for a GPEC2 or GPEC2A unlock, and in every one of those six cases the correct outcome is a refusal before money changes hands, not a file that bricks a controller.

The thing worth understanding is that a file service does not look at your car. It looks at a binary. Everything it can know about the job, it has to read out of the bytes you handed it — which is why the read is the whole job, and why a rejection is almost always a comment on the read rather than on the vehicle.

What “a valid read” actually means

A valid read is a complete, unmodified copy of a specific memory region of a specific controller, produced by a tool operating in a mode that reads that region. Each of those four qualifiers fails independently, and each failure looks identical from the outside: a file on your desktop with a plausible name and a plausible size.

Complete.A 2 MB flash region read as 1 MB is not half a job, it is a different file. Patching tools work by locating structures at known offsets; if the tail of the region is missing, the structure the patch needs may simply not be present, and a tool that guesses where it would have been is a tool that will eventually write garbage into somebody's controller.

Unmodified.Several popular tools wrap the raw dump in a container — a proprietary header, a footer, a per-block record structure — and save that as the default output. The bytes inside are correct. The file is not the bytes. Most of these tools also offer a plain-binary export, and that is the one to send.

Of a specific region. The single most common confusion we see is EEPROM versus flash. Immobiliser data on a large family of controllers lives in a serial EEPROM chip that is physically separate from the flash the calibration lives in, and the two are read by different procedures. Our post on what EEPROM chips hold is the long version; the short version is that an IMMO-OFF request accompanied by a flash dump is asking us to edit a file that does not contain the thing being edited.

By a tool in the right mode. OBD, bench and boot are three different levels of access to the same controller, and they do not all reach the same regions. Our bench, boot and OBD read-methods guide sets out which one reaches what. A read taken over OBD when the job needed boot mode is not a worse read; it is a read of something else.

The six rejection reasons, and what each one means

RejectionWhat it usually isFix
Unexpected file sizePartial read, or a container header added by the toolRe-read to completion; export as raw binary
Wrong regionFlash sent for an EEPROM job, or the reverseRead the region the service actually edits
No recognised signatureDifferent ECU family than assumed, or a corrupt readPhotograph the label and re-identify before re-reading
Ambiguous signatureBytes match two masks at once — often a bad readRe-read; a clean dump resolves to one mask
Signed / protectedController verifies a cryptographic signature on bootNo file route exists — change the plan, not the tool
Out of coverageReal, readable, simply not a family we carryMail-in bench, or post it to the specialist network

The ambiguous-signature case is the interesting one

Most people expect a validator to be a size check and a magic number. The case that surprises them is the file that matches two definitions at once.

Our own GM VATS calculator carries a guard for exactly this. The older GM memcal masks are distinguished by patterns at fixed offsets, and a dump that is corrupt — or that is not really a memcal at all — can satisfy the test for more than one mask simultaneously. When that happens the correct answer is not to pick the more likely one. It is to refuse, because a coin flip that lands wrong produces a calibration the engine will not run on. During our own testing a file of random bytes was correctly rejected on precisely those grounds before any payment step ran.

“A validator that never says no is a validator that has never been tested. If your dump matches two masks, the useful information is that your dump is wrong — not that our matcher is fussy.” — File-service desk, ECU Flash Cartel

The same logic runs underneath every family in our coverage matrix, which lists 20 ECU variants with a separately tracked status for IMMO-OFF and for checksum work on each one. A family can be live for checksum repair and only in development for IMMO-OFF, and the matrix says so rather than rounding both up to “supported”.

Signed is not the same as locked

Two different obstacles get described with the same word, and the difference decides whether a file route exists at all.

Locked means the manufacturer has restricted read or write access through the diagnostic interface. The data is ordinary; the door is closed. That is the situation an unlock service addresses, and it is why a GPEC2 or GPEC2A read can be returned unlocked in seconds.

Signed means the controller checks a cryptographic signature over its own contents before it will run them. Editing a byte invalidates the signature, and producing a new valid signature requires a private key that exists inside the manufacturer and nowhere else. Simos PCR2.1 is the example we name most often, and our signed-bootloader post explains why that is a mathematical wall rather than a coverage gap someone will close next quarter.

A vendor who quotes you a price for a signed controller is either describing a different operation than the one you asked about, or selling you a file that will not boot. This is the single most useful question to ask before paying anybody: is this controller locked, or is it signed?

Before you read: identify, then photograph

Two minutes spent here removes most rejections.

Take a clear, square-on photograph of the controller label with the part numbers legible, and run it through our free identifier. Bosch, Siemens, Continental and Delphi all encode family and hardware revision into that label, and our guide to reading an ECU label walks through what each field means. Year, make and model alone are not enough: the same model year routinely shipped with two controller families depending on build date and market, which is why our unlock pages say to verify by label, part number, ECU family and read file rather than by vehicle.

Then take a backup read before you do anything else, and keep it somewhere that is not the laptop you are working on. Our return-to-stock and backups post makes the case at length; the compressed version is that the original read is the only artefact that can put the controller back exactly as it was, and it costs nothing to keep.

Sanity checks you can run before uploading

Four of them, none needing anything beyond a hex editor and a minute, and between them they catch the large majority of the rejections we issue.

Check the size against the expected map.Each controller family has a known flash size, and a dump that is half, or an odd number of kilobytes, or a suspiciously round number the family does not use, is a partial read wearing a complete read's filename. This is the single most common defect we see, and it is visible before you upload.

Look for long runs of FF or 00.Open the file and scroll. Unwritten flash reads as FF, and a genuine dump has FF regions in the places the map says are empty — not across areas that should hold calibration data. A dump whose second half is entirely FF is a read that stopped.

Read it twice and compare.Two reads of a healthy module are byte-identical. If they are not, the difference is the answer: a flaky connection, a marginal supply, or a tool that is losing bytes under load. Comparing two dumps takes seconds and turns “it might be a bad read” into a fact.

Confirm the tool reported success.Several tools will write out whatever they managed to collect after an aborted read. The file exists, so it feels like a result. Scroll back through the tool's own log and confirm it says the operation completed, not that it was cancelled or timed out.

Power deserves its own line here. A bench read pulls the module through a voltage range it never sees in the car, and a supply that sags mid-read produces exactly the silently-truncated file described above. A stable bench supply is not a nicety; it is the difference between a dump you can act on and one that wastes a day.

When the rejection is ours

It happens. A family that is genuinely covered can be misrouted, and a file that is genuinely complete can trip a check it should not have. The way to resolve that quickly is to send the controller label photograph alongside the dump and say which service you expected it to route to.

What makes this fast to settle is that the label is authoritative in a way the order form is not. A form is what somebody typed; the label is what the part is. When the two disagree, the label wins, and the disagreement itself usually explains the rejection.

What to send with the file

Every instant order asks for the same context, and supplying it properly is what turns a rejection into a completed job:

The vehicle year, make, model and engine. The VIN. A photograph of the controller label. The tool used and the mode it read in. And, where relevant, what has already been attempted — a controller that has already had a failed write is a different job from a virgin read, and saying so up front saves everyone a round trip. If a write has already failed partway, stop and read our interrupted-flash recovery post before attempting anything else; the recovery route depends on how far the write got.

When the answer is genuinely no file route

Some jobs never had one. A controller that will not power up cannot be read at all, and no amount of tooling changes that. A family outside our matrix is outside it today whatever the car is worth. And a signed controller stays signed.

In all three cases the routes that remain are physical or procedural rather than digital. Mail-in bench work at $250 puts the module in front of someone with direct access to the silicon. An OE programming session on one of the eight platforms on our flash pagedoes the job through the manufacturer's own application, which never needed your dump in the first place. And if neither fits, posting the job to the specialist network is free and reaches operators with tooling we do not hold.

Standards, and the legal line

The pass-thru interface that lets a generic device in your hand talk to a controller is defined by SAE J2534, and where a secure-access credential is involved the registry is administered by NASTF. Neither of those is a licence to bypass a protection mechanism; both are the legitimate route around the problem that protection mechanisms were built to stop being solved illegitimately.

We do not provide emissions defeat, delete files, or services intended to bypass emissions laws. Our services exist for tuning preparation, diagnostics, repair, motorsport, and off-road use where legally permitted. Customer is responsible for confirming legal use in their location and application.

Section 203(a)(3) of the federal Clean Air Act applies to what is written into a controller regardless of whether the write came from a file service or a session, which is why the position above is a policy rather than a disclaimer.

The short version

Read completely, export raw, read the region the service edits, and identify the controller from its label before you touch it. Do that and a $100 IMMO-OFF or a $150 unlock comes back in seconds. Skip it and the rejection is doing its job: it is the cheapest possible failure, and the only one that happens before anything gets written to a controller.

Frequently asked

My tool said the read completed. Why was the file rejected?
A read tool reports that its own process finished, not that the resulting file is complete or internally consistent. Partial reads, padded regions and reads taken from a controller that was not fully awake all terminate cleanly and produce a file the tool considers successful.
What is the most common cause?
A short or padded file. Long runs of identical filler bytes where real data should be usually mean the read stopped early or the tool substituted padding for a region it could not access.
Does file size alone tell me whether the read is good?
Size is the first check, not the last. A file can be exactly the right length and still contain padded regions. We check both length and content.
Can you repair a bad read instead of asking for another one?
Sometimes, and only when what is missing is recoverable. A checksum that no longer matches otherwise valid contents is repairable. A region that was never read is not, because there is nothing to repair.
Should I re-read on the bench if OBD failed?
Often, yes. Several controllers restrict what is readable over the diagnostic connector and expose everything only in boot or bench mode. Our read-methods guide covers which is which.
What should I send along with the file?
The VIN, the hardware number from the controller label, which tool and mode produced the read, and anything already attempted. Those four facts prevent nearly every avoidable round trip.
Does a rejected upload cost me anything?
No. A file that does not pass validation is not processed and not billed.

Ready to put this into practice?

Book a remote ECU programming session in minutes — or drop a dump on the free identifier first to see whether we cover your variant.