ECU programmers may export files labelled flash, EEPROM, iflash, dflash, eflash, MCU or even MPC. These names do not describe interchangeable files. They identify different memory areas, processor-related dumps or tool-specific packages, and the exact meaning depends on the controller and reading protocol.
For workshop work, the first question is not “Which file is bigger?” It is: Which memory area did the tool read, and which operation are you trying to complete?
Flash and calibration data
The flash area normally contains executable software and calibration data, but a programmer may expose it as one file or split it into several parts. AutoTuner’s official file-format documentation, for example, says maps are usually located in eflash0 or eflash1, while the remaining content includes code needed for the controller to operate.
A calibration or map file can be sufficient for a supported recalibration workflow. It should not automatically be treated as a complete ECU backup, a cloning package or a replacement for every memory in the controller.
Internal Flash: iflash
iflash generally refers to flash memory integrated into the microcontroller. A Boot-mode read may expose more than one internal-flash section. AutoTuner lists iflash0 and iflash1 among the parts that can appear in a Tricore Boot backup.
The fact that a tool exports two internal-flash files does not mean another ECU family will use the same layout. Always preserve the original filenames and structure generated by the programmer.
Data Flash and EEPROM
dflash is a data-flash area inside some microcontrollers. Separate EEPROM may also exist internally or as an external component. These areas can hold persistent controller-specific data, but their contents and importance vary by ECU or TCU.
Do not assume that EEPROM, dflash, coding or immobilizer-related information is located in the same place across different controller families. Magicmotorsport’s official cloning matrix illustrates why controller-specific verification matters: supported cloning methods and required memories differ, and some entries require an external EEPROM operation rather than a generic flash write.
External Flash: eflash
eflash normally indicates external flash memory connected to the MCU. It may contain program or calibration content, depending on the controller design. Some controllers have it; others do not. AutoTuner therefore lists external flash in its Boot backup structure only when the MCU uses that memory.
What do MCU and MPC mean in file names?
MCU means microcontroller unit. MPC is commonly encountered in the names of certain processor families and workshop dump files. Neither label, by itself, proves that a file is a full backup or identifies every memory it contains.
Treat the programmer’s protocol screen, exported archive structure and official instructions as the authority. A file casually called an “MPC dump” by one workflow may not be equivalent to a full backup produced by another tool.
Full backup versus a single memory file
AutoTuner describes its backup file as containing all MCU memories captured by the supported operation. In its documented Tricore Boot example, that package can include internal flash, data flash and external flash where present. It also states that an OBD read does not create this backup.
Magicmotorsport likewise distinguishes controller-specific cloning solutions: some use a full backup, some use individual memories, some require additional physical EEPROM work, and some have no validated solution. That is strong evidence against applying one generic “write the flash and it is cloned” rule.
Which data does the workshop need?
| Job | Starting point | Main caution |
|---|---|---|
| Supported recalibration | The exact file type requested by the programming protocol | A calibration file is not automatically a full backup |
| Return to exact stock software | Verified original matching the ECU identification | Match software and hardware identifiers before writing |
| Interrupted-flash recovery | Original read, identification, logs and any available backup | Confirm the damaged memory area and supported recovery mode |
| Replacement or cloning | Controller-specific cloning documentation and preserved source data | Flash alone may not include all unique or persistent data |
Safe workshop checklist
- Save the complete ECU identification before programming.
- Keep the untouched original read and the programmer-generated archive.
- Record the tool, protocol and access mode used.
- Do not rename, merge or split backup components unless the tool’s documentation requires it.
- Verify checksum handling for every modified memory.
- Confirm that the intended write operation accepts that exact file type.
- For cloning or replacement, check the controller-specific solution rather than inferring from file size or ECU family.
Finding the correct original file
ECUFlashFiles is intended for identified stock/original files and instant catalogue discovery. Search the software-number index and compare the ECU’s complete identification before using a file. For matching principles, read How to Match an Original ECU File by Bosch SW and HW Number. For read-type differences, see Full Backup vs Virtual Read vs Calibration File.
Sources
Bottom line: identify the memory area before judging the file. Flash, EEPROM, iflash, dflash and eflash describe different data, while MCU or MPC wording alone does not prove that a dump is complete.