Originally Posted by Mike Benvo
Thank you for your question, I am happy to answer for you.
When I was in Europe a few weeks ago, I tested this particular reason as to why many of those that attempt an update on their own 'brick' their ECU. Theoretically, you should be able to use these cables for flashing. However, there is one BIG problem that 99.9% of people are unaware about.
I purposely used one of the coding cables to 'brick' the ECU and determine what in particular is happening behind the scenes. When people attempt these updates, it often goes to 100% and appears that it has successfully flashed, only to receive an error at the very end which leaves the ECU in a state of no communication. This means no reprogramming it through the OBD-II port, and no communication with the car itself - so basically it's a 4000lb paperweight.
Now.. on to why this happens. Many of the cables that people are using have an inherent firmware flaw. The DME and TCU are one of the few control units in the car that are programmed with D-CAN. Most of the other modules in the car are programmed via K-CAN or KLINE, and the junction box may convert signals to the appropriate type depending on the ECU we are dealing with.
What I have found is that when programming DCAN modules (such as the DME and TCU), the firmware flaw causes erroneous data - specifically '06' to be written to the ECU every 253 bytes. This causes almost irreparable damage to the software programming and pretty much makes the DME useless.
The MSS60 (M3) and MSS65 (M5) DME's have two Motorola MPC563 Freescale processors. The MSS60 and the MSS65 share a very similar architecture, however, there is one pretty major difference. On M3's (cars with software from 2009 and above), BMW has introduced a revision of the code which 'locks' the left processor from reading. The ECU I tested this on was my E60 M5 DME, and luckily, both processors are not locked. This allowed me to open the DME up, and BDM (Background Debugging Mode) them. BDMing an ECU is when you open up the DME and use heads to connect to the pins on the motherboard which connect directly to the processor. This allows for reading and writing to the DME even if it is bricked, allowing you to now program and read a corrupted processor. Reading out the information from the processor gave a clear indication of why these DME's are left in a bricked state after such failed updates. I was able to recover the M5 DME completely, and it is working great again. Even flashed an M3 file into it for fun, and it accepted the flash.
However - with the M3, when this happens, it's a different story. Because the left processor is locked, you can not read or write to it using BDM. You can recover the right processor no problem, but without both processors working properly the DME will not be operating as designed and the vehicle will not start or run. On the M3, in order to fix a damaged ECU programmed with one of these cables, you have to desolder the left processor from the DME, and resolder a new one. After that, the processor will accept programming once again, and you can fully recover it.
Even a completely working M3 ECU will not allow communication with the left processor over BDM. OBD II will read fine from both processors, but you can not program certain sections of the processors over OBD II. I have a spare M3 DME that I use for testing, and unfortunately it will not work in my car because of the electronic immobilizer data written to the left processor which is secured from OBD programming. For this reason I am going to replace the left processor which will allow it to be programmed to a virgin state. I will then be able to link this ECU successfully to my M3 and have two working DME's for my car.
Now onto why the cables that eVolve and I offer you do not cause this problem: They are designed 'specifically' for DME programming over D-CAN. They do not program any other modules because they are not designed for that, although the second generation of bluetooth cables will likely have a pass-through for coding and programming other modules. Not only that, the cables test ranges to program and are not nearly invasive as WinKFP for flashing. They don't alter the boot sector. They also have built in recovery mode features in the off-event that something does go awry, such as a cable getting pulled out in the middle, drastically low voltage, etc. The worse thing you can do to an electronic control unit is program bad data to the operating system part of the firmware/software. A properly designed system takes all measures to ensure that bad data is not written, and that in the event there is a fault, recovery can be performed. The master of all of this DME stuff is the engineer that designed these end user flashing cables.
I hope this helps!
|