What makes these things difficult for firmware tuners to reprogram?

1.) OBD - II.

This is a *diagnostic* system. If the new maps aren't tuned correctly, the system will report a fault. It also includes an anti-tamper security feature that tries to detect if any unauthorized reprogramming has been done.

I've been told that the main part of the M5.2 firmware and maps is very similar in appearance to previous Bosch (non OBD - II) systems. The OBD - II diagnostic and security firmware was 'patched' around the older designs. Tuners who were familiar with the older versions feel right at home with most the maps in the new system, but readjusting the diagnostic monitors to expect the behavior of a modified engine is a new experience for them. Also, they can't get away with sloppy tuning practices without disabling the diagnostic monitors (It's much better to leave the monitors enabled). Lastly, the security firmware hides calculated checksums all over the place, and each revision of M5.2 changes the hiding places.

All of the above are strictly firmware issues. Overcoming them is a matter of gaining a detailed understanding of how the firmware works.

2.) Flash reprogramming.

M5.2 uses FLASH EPROM memory. This is a type of memory that can be erased and reprogrammed, and that also retains information when the power is off. Some older (non OBD - II) systems also used flash memory.

Most older systems used EPROM memory that couldn't be reprogrammed while they were installed in the circuit. To make a firmware change, it was necessary to remove the EPROM (an IC chip).

FLASH EPROM memory is still a type of IC chip. If the circuit that it's installed in is designed to support it, it can be reprogrammed without removal. It is, however, still possible to remove the chip and reprogram it externally.

An analogy might be made to a hard disk drive. Normally, code is written and read while it is installed in a computer. It is still possible to physically open up a computer, remove the hard drive, and take it to another device or computer for reprogramming.

(Note: the information I've placed between {brackets} is partly speculative, and partly very second and third hand. It should be considered a *possible* explanation, not a definite description of Bosch or Siemens controllers).

Bosch M5.2 uses special custom FLASH and Microcontroller ICs. They aren't used in other products. Data on these devices is highly proprietary and hard to come by.

The Siemens control units (like the M3 uses) use standard off - the - shelf ICs that have plenty of published information about them.

Both the Bosch and the Siemens units have proprietary firmware. Bosch's proprietary hardware makes life even more difficult.

It appears that Bosch M5.2 circuitry was designed so that only part of the FLASH memory could be reprogrammed in-circuit. Siemens' designs allow the entire flash to be reprogrammed. There's pros and cons to both approaches.

The advantage to Siemens' approach of entire flash reprogramming is just that, everything can be reprogrammed. The problem is that running firmware is still required to do the reprogramming. One way to deal with this problem is to use a separate memory device to hold the reprogramming code. It looks like Siemens doesn't have a separate device. It appears that the reprogramming firmware is copied from FLASH into RAM. The reprogramming code then runs from RAM while the FLASH is being reprogrammed. The problem is that if something goes wrong during reprogramming (such as losing power), then not only is the main firmware lost, but also the reprogramming code. The control unit then becomes a useless 'brick'. The only way to reprogram it at this point is to remove the FLASH chip and manually reprogram it.

It looks like Bosch tried to overcome the 'dead brick' problem by making only part of the FLASH memory area reprogrammable. The hardware circuitry is designed so that only a portion of the FLASH memory could be written to. It also appears that they may have put some other key elements of the main code in this protected area, not just the FLASH reprogramming code. If this is true, and if there is something that is desirable to change in this area, then the only way to do it is to remove the part.

I was surprised this week to read that Garrett was unsoldering the M5.2 FLASH for reprogramming. He does have the capability to download to earlier units. It may simply be that he hasn't figured out how to do the serial download on this system, or it could be that M5.2 hardware prevents serial reprogramming from changing everything that he wants to. He does fortunately have the proper equipment for removing and replacing parts.

Jim C. mentioned that there might be some of the M5.2 code that could be inaccessible, he hadn't started looking at it yet. If he can serial download everything that's necessary, then it would be a superior method.

All of the above discussion has to do just with the methods and tools used for reprogramming. Serial downloads are absolutely more elegant. Unsoldering parts is trickier and much less convenient, but the end result is acceptable if it's done properly.

The real issue comes back to their skill at tuning engine maps. This is more important than how they get things into the box. They both have a good reputation.

Competition and choice are *good* things.

Brian Brown