Support for Early Rover 75 / MG ZT / NNN100682 ECUs

Download Link: https://andrewrevill.co.uk/Downloads/MEMS3Tools.zip

Over the time I’ve been developing MEMS3 Mapper and associated tools, I’ve had a lot of problems with very early NNN100682 ECUs. A lot of things just didn’t seem to work properly on them, and to be honest until recently I’d pretty much dismissed them as very early production ECUs, which appeared to have been released before they were quite ready, and were probably not going to be used in many cars on the road.

When I released the 5.87 Release version of MEMS3 Mapper which included the custom RAM agents for maintenance tasks, I very quickly received several emails from people saying this version wasn’t working properly for them, and all of them had NNN100682 ECUs. So it appears that these are actually found quite widely in Rover 75 and MG ZT cars. It was obvious I really needed to do something about being able to support them properly.

The problems all seemed to stem from the boot loader code, version bootp004. This regularly returned messages with the wrong checksums, or even messages with bytes missing or extra bytes of gibberish on the start or end. As a workaround, I developed some special project files which, instead of real firmware, contained a boot loader update program. You could write these to the ECU without having to rely on any of the custom features in 5.87, and when the ECU booted up on them, instead of launching a new firmware it just ran the update program, which replaced the faulty bootp004 with something more reliable, like bootp016 from the superseding NNN100683, then deleted itself and left the ECU ready to receive a new firmware again. This all worked, and the boot update projects are now packaged with MEMS3 Mapper version 5.90 Release onwards, however whilst testing I discovered something which made them rather obsolete …

MEMS3 Mapper supports two communication protocols. The one I use most frequently, and which is selected by default in MEMS3 Mapper when downloaded, is reasonably close to the standard for ISO 14230 / KWP2000. This is the most robust protocol for later ECUs as it includes features such as a communications timeout (which means that if something goes wrong with the messages between the PC and the ECU, the ECU never sits waiting forever for a message that isn’t coming) and a “Fast Initialisation Pulse”, which is special “wake up” signal to the ECU at the start of a conversation which can get ECUs attention and bring it back to expecting the start of a message if it has got into state where it’s expecting something different. However it seems that it is just the implementation of KWP2000 in the early ECUs which is faulty, and if you switch to using the other Rover BMW protocol, everything seems to work properly.

I would strongly recommend that anyone with an earlier ECU downloads version 5.90 Release or later of MEMS3 Mapper.

In version 5.90 I have added checks which detect when you try to talk to an ECU with a boot loader version lower than bootp009 (which is the earlier boot loader I know for sure to be stable using KWP2000). If you try to use ISO protocol talk to these ECUs it will stop and tell you to switch to Rover BMW protocol. This will ensure robust communications with the ECU. I have also removed all of the checks in 5.87 which prevented you from using some of the new features with the earlier boot loaders as they will all now work using Rover BMW protocol. I’ve also taken out a lot of the messy work-arounds I had accumulated over the years to try to cope with the malformed messages sent by these ECUs as they were all in KWP2000 only, which can no longer be used with NNN100682 and bootp004.

Switching Protocols

The communications protocol is simply selected in the combo box in the top right hand corner of the MEMS3 Mapper main window:

One point you to be aware of though: Once you have tried to talk to the ECU in any ISO protocol (either the ISO14230 / KWP2000 protocol used by MEMS3 Mapper or the ISO9141 protocol used by a lot of OBDII scan tools), the ECU will not want to talk the Rover BMW protocol. The ISO protocols both have special “wake up” signals that alert the ECU to the fact that you want to start a conversation with it in that protocol, the Rover BMW protocol does not, so there is no way of exiting the ISO mode until the ECU resets. This applies even if you have tried to do something with ISO14230 protocol and have received the message that you need to use Rover BMW protocol on an older ECU, as even asking the ECU what boot loader it is running will have put it in ISO mode.

If you see the error message “Error establishing communications. ECU is silent.” after switching protocols, the ECU is probably still expecting ISO mode messages.

To reset the ECU, you can either leave it switched off for several minutes (it takes a while as the ECU remains powered up for a while after you turn off the ignition to run the cooling fans), or you can use MEMS3 Mapper to reset it:

Note that MEMS3 Mapper ALWAYS uses ISO14230 protocol to reset the ECU, whatever protocol you have selected, so the ECU will always respond to it, and it NEVER tries to re-establish communications with the ECU immediately after a reset, so after resetting the ECU it will not be reinitialised into ISO protocol and will be ready to talk either protocol.

Once you have reset the ECU, it should be ready talk Rover BMW protocol. Then stick to Rover BMW protocol exclusively and everything should work correctly.

Given that the Rover 75 and MG ZT models are considerably more demanding in terms of ECU configuration and coding, I will continue to try to make sure that everything I supports these models in future versions.