MEMS3 Flywheel Trigger Pattern Changes

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

Using my MEMS3 Mapper you can now easily adjust the map to work with a different flywheel trigger pattern.

This follows on from the work I did on allowing a MEMS3 from a Rover 75 or MG ZT to run without its matched BMW EWS immobiliser. The driver behind this was to allow an MG ZT-T engine and ECU to be transplanted into say an MG ZR. Having solved the immobilisation issue, it was then pointed out to me that the MG ZT uses a completely different flywheel and gearbox to other K Series installations and the flywheel trigger pattern was also different, so a ZT ECU would not run with a ZR flywheel. So I set about hunting for the code that managed the flywheel tracking, wondering if I would be able to figure out how to change the pattern. To be honest I was expecting this to be a hard one, and I read up on the TPU (Time Processing Unit in the MC68336 microcontroller) ready for a fight … but once I started to dig into it, the answer was actually quite simple, as I’ll describe later in this article. In the meantime …

By following the instruction below, you will be able to tell the MEMS3 ECU about the new flywheel trigger pattern so that it will then synchronise correctly.

This may be of direct use on a Caterham when upgrading an early MEMS 1.9 engine to MEMS3 without swapping the flywheel.

Basic Instructions

You will need to download the latest version (5.56 or later) of my MEMS3 Tools from here: https://andrewrevill.co.uk/Downloads/MEMS3Tools.zip

If you open a file or read the map from an ECU using this version you should see some scalars listed, with descriptions “Flywheel Missing Tooth Angles[0]” to “Flywheel Missing Tooth Angles[3]” as shown below.

If you are using a firmware version that I haven’t seen, these will not be found. In that case just click Identify, Keep Existing and it should find them all automatically.

All you need to do is enter the new missing tooth angles, in degrees ATDC in increasing order, into these four scalars.

Just to make it a little more convenient to edit and validate them in one place, and to allow you to select from a number of predefined flywheel patterns, I’ve added a wizard to do it for you.

Click Tools, Wizards, Flywheel Trigger Pattern and you should see a dialog like this:

If this menu item is disabled, the application has not been able to identify the relevant scalars in the map. Ensure that you have used the Identify, Keep Existing system to identify the scalars.

 

In this dialog you enter the four missing tooth angles, in ascending order. You can also just select one of the standard flywheels from the combo box to populate the dialog with the correct numbers. Standard flywheels provided include the MG Rover MEMS 1.9 Common Pattern (0°, 120°, 180°, 310°), MG Rover MEMS 2J/3 Common Pattern (30°, 60°, 210°, 250°) and Rover 75 or MG ZT Specific Pattern (80°, 120°, 270°, 300°). As the patterns are all based on 36 teeth, the teeth are always spaced at 10° intervals and the tooth angles are normally integer multiples of 10°.

 

If you are using a different flywheel and you have some numbers, please let me know and I’ll add it to the list.

 

When you’re done, click OK to update the current map. If the OK button is disabled it means that the angles entered are invalid, for example duplicated or out of order.

This wizard is compatible with live mapping mode and will let you play with the flywheel trigger pattern on a live engine.

Technical Details

I original expected this to be a hard one to find.

Inside the MC68336 microcontroller in the ECU is a Time Processor Unit (TPU). This turns out to be very flexible and powerful. It has 16 channels, each of which can be programmed in microcode to perform a different timing function. Channel 0 is programmed to track the crank sensor signal and generate interrupts with the passing of the teeth that allow the CPU to track the flywheel position. Channels 1 & 2 are slaved to Channel 0 and are programmed to trigger interrupts at given points in the cycle – driving the ignition coils. Channels 3, 4, 5 & 6 are slaved to Channel 0 and are programmed to trigger interrupts at other points in the cycle – driving the fuel injectors. Most of the timekeeping of the engine is therefore performed by the TPU alone without direct intervention of the CPU, whose job it is to monitor conditions and update the parameter of the TPU.

I went looking for the coding of the flywheel trigger pattern in the TPU management, following examples such as this: Period Measurement With Missing Transition Detection TPU Function (PMM), by Motorola / Freescale / NXP who make the microcontroller. Following the examples, one of the first things I looked at in the ECU code was the routine that handled the TPU interrupt for TPU Channel 0, and that led me to the routine that manages the internal RAM variable for Crankshaft Rotation Position, which starts off like this:

                             *************************************************************

                             *                                                           

                             *  FUNCTION                                                 

                             *************************************************************

                             undefined  funProcessCrankshaftRotation ()

             undefined         D0b:1          <RETURN>

             undefined2        Stack[-0x2]:2  local_2                                 XREF[2]:     0011127a (*) ,

                                                                                                   00111280 (*)  

                             funProcessCrankshaftRotation                    XREF[1]:     FUN_00110d4a:00110dfa (c)  

        00111120 70  05           moveq      #0x5 ,D0

        00111122 32  35  03       move.w     (0x832 ,A5,D0w *0x2 ),D1w

                 20  08  32

                             LAB_00111128                                    XREF[1]:     00111132 (j)  

        00111128 6c  0a           bge.b      LAB_00111134

        0011112a 53  40           subq.w     #0x1 ,D0w

        0011112c 32  35  03       move.w     (0x832 ,A5,D0w *0x2 ),D1w

                 20  08  32

        00111132 60  f4           bra.b      LAB_00111128

                             LAB_00111134                                    XREF[1]:     00111128 (j)  

        00111134 42  47           clr.w      D7w

        00111136 34  38  04  c6    move.w     (varWordCrankshaftRotationalPosition_S21 ).w,D2w

        0011113a 04  42  00  64    subi.w     #0x64 ,D2w

        0011113e 3a  3c  0e  10    move.w     #0xe10 ,D5w

        00111142 da  6d  08  32    add.w      (0x832 ,A5),D5w

        00111146 32  35  03       move.w     (0x832 ,A5,D0w *0x2 ),D1w

                 20  08  32

Straight away I noticed the bits I’ve highlighted in the above listing. The whole routine is heavily dependent on an array of scalars at offset 0x832 in the map. And I went to look what was in that array, there were the four missing tooth angles. And it turns out the routine isn’t really dependent on anything else, those four tooth angles are all it needs and uses to track the crank angle.

I don’t have access to a Rover 75 or MG ZT to test this on, so I had to test it on an ECU test harness.

My test harness generates crank and cam sensor signals corresponding to MG Rover MEMS 2J/3 Common Pattern (30°, 60°, 210°, 250°). When I flashed a Rover 75 firmware and map onto a test ECU, it would not synchronise with my test harness at all. The ignition coils and injectors were firing away but in an erratic pattern, and live diagnostics showed that the ECU thought it was cranking rather than running; it was recognising that there was a signal from the crank sensor, but it was unable to synchronise to it.

When I used the above method to change the flywheel pattern in the Rover 75 map and flashed it onto the test ECU again, it synchronised and appeared to be running normally. The ignition was firing in a regular pattern and the injectors were firing sequentially. But to be sure, I had to confirm that the engine timings were as expected. To do this, I took a VVC firmware and map and a Rover 75 firmware and map. In the maps I took out all of the adjustments applied to the ignition timing and modified the ignition timing table to hold a constant value at all MAP and RPM values. This meant that I knew exactly what the ignition timing should be on my test harness. I was then able to attach an oscilloscope to the crank signal and the ignition coil drive.

Stock VVC Map:

Flywheel-Swapped Rover 75 Map:

These are arranged such that the heavy vertical scale line in the middle is at TDC. The closely-spaced peaks in the crankshaft signal are at 10° intervals, so the point at which the ignition coil fires (the rising edge of the yellow line) is at approximately 20° BTDC, which is the value I had programmed into the tables. You can see that the flywheel-swapped Rover 75 map is a very close match indeed for the VVC map, and so the ECU with the Rover 75 map is now correctly tracking the flywheel position based on the standard trigger pattern. Similar measurements on the injector timing also yielded the expected results (after a bit of head scratching; the very early NNN100683 ECU, which I already knew to be riddled with bugs in its OBDII code, seems to fire the injectors exactly 10° later than specified in the map, even with the stock flywheel, but later 75 ECUs behaved as expected).