Why ECU file sizes differ between tools and read methods
"My read is 2 MB, the original is 4 MB" is one of the most common questions. File size depends on what was read and how it was saved; here is what really tells you whether two files match.
Contents
Two reads of the same ECU type do not always have the same size. One tool saves a 2 MB file, another 4 MB; an OBD read is a few hundred kilobytes while a bench read of the same unit is several megabytes. That alone does not mean either file is wrong. File size depends on which memory was read and how the tool saved it — and both vary.
What memory an ECU has
An engine ECU stores its data in more than one place:
- Program flash — the main memory holding program code and calibration. In current ECUs it is inside the microcontroller; older units used separate flash chips on the board. Sizes range from a few hundred kilobytes in older units to several megabytes today — Bosch EDC17 units, for example, have 1.5 to 4 MB depending on the processor.
- EEPROM or data flash — a small memory for data that changes during the vehicle's life: adaptation values, counters, immobiliser and coding data. It is specific to one unit. Some ECUs have a separate EEPROM chip, others emulate it in a data-flash area of the processor.
- RAM — working memory. It is not part of any file.
An "ECU file" may therefore be the program flash, a part of it, the EEPROM, or several of these saved separately or merged together.
Reason 1: full read or calibration only
Many OBD procedures read or write only the area the manufacturer's own flashing process touches — often just the calibration. A bench or boot-mode read usually captures the whole flash. The calibration-only file is naturally smaller.
Some tools save such a partial read as a short file containing only that area; others place it inside a full-size image and fill the rest with FF or 00, so that addresses match the real memory. Both files hold the same calibration, yet one is many times larger than the other.
Reason 2: separate files or one merged file
When a tool reads several memories — internal flash, external flash, EEPROM — it may save them as separate files or join them into one. A merged file is larger than the flash alone, and the order in which the parts are joined is the tool's own choice.
Reason 3: address layout and padding
A processor sees its memory at particular addresses, often with gaps between blocks. One tool saves an image starting at address zero with the gaps filled; another saves only the used blocks, one after the other; a third saves the blocks in a different order. The content of each block is identical, but sizes and offsets differ, and a map definition made for one layout will point to the wrong places in another.
Reason 4: tool containers
Some tools do not save a plain binary at all, but their own container: a file with a header, sometimes compressed or encrypted, sometimes tied to the tool that read it. The raw binary inside has to be exported with that tool's own software before other programs can use it, and a binary from elsewhere may have to be imported back into that format before the tool will write it. Container files have sizes that have little to do with the ECU's memory.
Reason 5: byte order
Memory can be read as single bytes or as 16-bit words. If a 16-bit memory is read with the bytes of each word in the opposite order, the file has the same size but every pair of bytes is swapped. Compared with a correctly ordered file, it looks completely different — even though it holds the same data. WinOLS and most hex editors can swap byte pairs, which settles the question quickly.
Reason 6: a different software version
The opposite trap: two files with exactly the same size are not necessarily the same software. A different software version of the same ECU type usually has the same memory size and an entirely different content. Equal size proves nothing.
What to compare instead of size
| Check | What it tells you |
|---|---|
| SW number / calibration ID in both files | Whether they are the same software version — the deciding check. |
| Position of the identification strings | Whether the layout (offsets) is the same. |
| Filled and empty areas | Whether one is a full read and the other partial, or padded differently. |
| Byte-swapped comparison | Whether one of the files was saved in the opposite byte order. |
| Differences after alignment | Whether the calibration was changed (modified file) or not. |
The step-by-step version of these checks is in how to check you have the right original.
What this means when you buy an original
Each original in our archive is one read of that software version, delivered as a .bin file. Its size is the size of that read — it may be a full read or a calibration area, and it may be laid out differently from the file your tool produces. That is why the file pages list the numbers rather than promising a particular size: the numbers identify the software, the size only describes how it was read.
If your tool needs a particular layout or its own container format, the conversion is done with that tool's own software. Because files are digital and all sales are final, check how your tool handles external files before you buy. For background on how reads are made, see OBD, bench and boot read methods.
Find the original for your ECU
Search 197 280 stock reads by HW or SW number, ECU type or vehicle. Pay by card, receive the .bin by e-mail.
Your card is charged only when the file is ready. Digital files: all sales are final — compare the numbers before you buy.