I would like a little clarification on the difference between some of the terms used around flashing ECUs.
Good to know:
Over OBD means using the KWP1281 or KWP2000 protocols supported by the ME7 firmware. This is how the dealership flashes the car and it requires the ECU to have a working version of the ME7 firmware. Since this uses the protocols in the ME7 firmware to read the flash memory, it is possible to update the protocols to disable reading.
Boot mode means using the boot strap loader built into the C166/C167 processor. This uses the debugging features supported by the processor to load a program into RAM to allow you to read/write the flash memory. This does not require the ECU to have a working version of the ME7 firmware on it. Since the boot strap loader is loaded by you into RAM, you can bypass any software protection in place to prevent reading the flash memory contents.
If you remove the flash from the PCB, you can read/write it using something like this:
This hardware device reads/writes to the chip in essentially the same way the processor does – using the electronic interface of the chip and sending the appropriate electronic signals.
Note that you can’t use a willem programmer read flash contents that are behind an encryption board (note: you can, but you will just be reading the ENCRYPTED contents of the flash), because the encryption chip waits to detect the ECU booting, before it “unlocks” and starts decrypting the contents of the flash. This “decryption/encryption” process is kind of a misnomer from what I understand, because in most implementations, the encryption chip sits between just jumbles the contents of the flash around – so the data meant to be stored at a particular address is actually intercepted by the encryption chip, and then the chip stores it in a completely different location on the actual flash chip. When you request to read a location, the encryption chip knows where the byte is that you’re looking for, and then reads the alternate location on the flash chip, and sends the data back – the CPU is non the wiser.
Note I am not condoning stealing somebody else’s work – but there are some times you many need/want to bypass this “protection” to fix a tune you rightfully own – or – if you’re like me, you don’t like the idea of lots of mechanical interfaces that could potentially fail over time with corrosion/vibration, etc. In most cases boot mode can be used to circumvent this “protection”. I have also seen one instance where NefMoto could read it, probably because the tuner didn’t think that reading over OBD would be a threat in the future, or didn’t know how to disable the function used for reading over KWP.
I then removed the eeprom from the encryption board, desoldered the encryption board, desoldered the eeprom from the encryption board, soldered it in place of the board back on the ECU’s PCB, made the necessary changes to the rom, and then used boot mode to write the decrypted/modified flash to the freshly soldered eeprom that was encrypted. The result was a configuration I think is more reliable, and the flash could be read/changed in the future without any hassle.
In closing, each tool is extremely useful and you will probably find that NefMoto is invaluable along with Galletto. You probably don’t need an eeprom programmer.
An easy way to differentiate between the functions/use can be broken down like this:
*Fast flashing by only writing CHANGED data.
*Convenient because the ECU stays in the car.
*Tony is awesome and provides awesome support.
*Future functionality like checksums will be great.
*Sometimes tuners disable the read function required to read the ECU
*No recovery if you have an ECU with a flash that won’t boot
*Can recover from a bad flash
*Can bypass some protection mechanisms
*Requires physical access to the ECU’s PCB to short the boot pin to ground. This can suck if your ECU is buried below tons of trim pieces.
*Slow flashing because the ENTIRE flash is written.
*Absolute low-level recovery from a bad flash
*Eeprom can be tested/zeroed out
*Can be used with an adapter to read the Serial eeprom (separate from the program eeprom, where DTC’s and other parameters are stored separate from the program flash)
*Requires desoldering/resoldering the eeprom from the PCB, which has a risk of damaging the PCB by lifting pads, etc.
*Even if socketed, you run the risk of PCB damage, or physical connections that come loose over time.