What format can a firmware file have?

What format can a firmware file have

Our support constantly receives questions like: “I read the ECU firmware with [flasher’s name]. It’s 500 kB, but the same firmware in your catalog is 2 mB. What is the reason?” Or: “I've found a stock file on the Internet, but it differs in size and format from what I got. Has the flasher read it wrong? How do I write it correctly then?" If you also have similar questions, it’s highly recommended to read this article thoroughly.

Let’s deal with the basics first: what is a firmware?

A firmware is ECU’s flash memory. Basically, it’s a sequence of bytes containing an executable code and other information. When it’s in a control unit’s memory it’s NOT a file, because the control unit doesn’t have an operating or file system. It’s just a long sequence of ones and zeroes. Firmware (in other words ones and zeroes) becomes a file only after reading and saving it on a computer by a flasher program.

And this is the most fundamental point to understand. So let’s repeat it once again. “Firmware file” (dump) and “firmware” are slightly different terms that must not be mixed up. Firmware is a sequence of zeros and ones, abstracted from the storage method. Firmware file is the same sequence but saved as a separate file, as a titled data area within a computer file system. 

Alright, this part is over. But there’s another term that is necessary for understanding this topic – “file format”. Strict definition of the “file format” sounds scary even for IT-guys, so we’ll try to explain it in simple words.

All in all, format is a way of storing any data.

For example, take the number “13”. Its encoding (i.e. its representation) in the decimal number system in Arabic numerals is written as “13”. But it can also be written in Roman numerals - “XIII”. Also, you can write “13.00000”, “13/1”, “0000000013”. The selected number can also be encoded in the form of dots or dashes, or it can be represented as the sum of squares of prime numbers: “22 + 32”, etc. It may sound weird and at the “computer science for preschoolers” level, but the above ways of recording numbers are all types of formats, where the information, in fact, does not change. Only the way of recording and storing this information changes.

Obviously, any information can be represented and stored in different ways. This includes firmware. When storing firmware in a file, it can be encrypted or compressed, for example, but the useful data will not change in any way. Nor will they change if you add auxiliary information for the bootloader to the end or the beginning of the same file. You can store both firmware and virtual eeprom data read from a particular car in a single file, or store two firmware in a single file (for example, from engine and automatic transmission). All these are storage methods, or, as it is more usual to say, formats.

In conclusion, a firmware (sequence of zeros and ones) can be saved as a file. And a firmware file can be in different formats.

We highly hope that things are clear to you now. Because in our opinion, the misunderstanding of the information above is the leading cause of troubles for the running specialists. 

Reasonable question: what does a firmware file format depend on? First of all, it depends on a flasher program.

There are quite a lot of firmware formats you may encounter in your work. It is not always the familiar *.bin. The logic of many dealer loaders is that in addition to the body of the firmware itself, these loaders need certain metadata (about the car, control unit, exchange protocol, etc.). Accordingly, as a rule, the “dealer” format of the firmware file implies that the file contains not only the firmware. At the same time, developers of non-dealer bootloaders for chip tuning are free to come up with additional functionality (e.g. encrypted files-containers of firmware for slave, etc.). Therefore, let us repeat, there are many firmware formats.

Below are listed the most common firmware file formats in chip tuning:

Free form binary file (*.bin)

It’s a simple sequence of bytes. The most used format in chip tunning. As a rule, it represents ECU’s memory dump or its certain area saved “as is”. Almost all multicar flashers work with this format. It’s a significant advantage, as a firmware file made by one tool can be written by another, and vice versa. In many cases the format has *.bin extension, but some tools may use other (e.g. K-Tag uses *.fls and *.mpc).

In fact, a free form binary file is not quite a format. The main problem is in its “arbitrariness”. The point is that different tools (in different modes) can generate files differently.

For example, loader “A” can read only calibrations on a certain control unit, loader “B” will read calibrations + control program, when loader “C” reads “fullflash”. In this case, loader “A” will generate a file containing only calibrations (say, 32kb), and loader “B” will generate a full image (say, 512kb), but fill the unread areas with “0xFF” bytes, etc.

SMS-Soft Container File (*.bcf)

Format is used in products from SMS-Soft company, in particular Combiloader, and has extension *.bcf. It allows storing internal/external flash memory data, eeprom data and other meta-data in a single file, which is very convenient. In addition, it has integrity checking, password protection, compression and much more.

But there’s a fly in the ointment. This particular format is supported only in SMS-Soft tools. It’s not possible to write firmware saved as a *.bcf file with any other flasher except Combiloader. Also, it can’t be opened in any editor except ChipTuningPRO.

Anyways, once firmware was read by Combiloader it’s not necessary to save it as a .bcf container file.  The firmware can be saved as a regular binary file (*.bin). In old modules it’s made with the key combination Shift+Save. In newer modules the format is selected in the save window.

Calibration Update Wizard File (*.cuw)

Toyota/Lexus dealer firmware file format is used specifically in the Toyota Techstream Calibration Update Wizard program. It’s a container file that includes default firmware (default firmware update). Remarkable thing is that one cuw-file can contain two firmware at the same time (for engine and automatic gearbox). 

Volvo binary file (*.vbf)

This is a widespread dealer format with default firmware used by many vehicles manufacturers (in particular by Volvo, Ford, Mazda, Jaguar, Land Rover). It’s a container file with metadata at the beginning (the headline) for a flasher and binary data of the firmware itself.

VAG *.sgo, *.odx, *.frf and other

We should single out dealer container file formats with default firmware for VAG vehicles. The most popular formats are *.sgo, *.odx, *.frf. But you can also find *.sgm, *.pdx, *.sox. 

Obviously, there’re many other dealer and non-dealer formats. There's nothing unusual about that. Just pay attention to what you read and write in ECU, work with good equipment and always (ALWAYS!) read the instructions to the flashers.  Remember: chip tuning is science with nuances which you must be aware of and predict to avoid ECU bricking.