Technical IAW ECU Live Mapping & Tech Info

Currently reading:
Technical IAW ECU Live Mapping & Tech Info

woj

Established member
Joined
Nov 8, 2005
Messages
1,613
Points
295
Location
Halmstad
OK, promise is a promise. I will try to do it in steps and be informative, but at the same time I do not want to provide you with all my knowledge, I think that you should try things yourself if you are brave enough (and have tons of time to spare too :D). At this point I would also like to strongly state that despite the things I am planning to write about my knowledge is limited in certain areas (I am for example very poor with electronics). Then all the info is based on and for IAW ECUs old families 16F, 8F/18F, and 18FD, with the emphasis on 8F/18F, which I dissected in great detail and reprogrammed to deal with my turbo :D. Finally, I will not answer PMs about this, ask here, and I will try to answer if I can/want ;) Finally, it is not my intention or will to teach you about binary code, hex code, assemblers in general, etc. There is plenty of information about that in Google and following the links provided at the top.

First of, some background and useful information to the stuff that is out there:

The page about Motorola HC11 CPUs

Technical documentation for HC11

A page about disassembling HC11 programs

Tuner Pro web page, tools, and other (definition) files: http://www.tunerpro.net/

For the sake of having all the links in one place: 16F Technical Documentation

There are such technical documentations for 8F/18F ECUs and 18FD ECU too, in Italian, I got them from barnacle (cheers again (y)), but I committed myself to not publishing them (the legal status is not clear to me), so ask him for that and see if he wants to share.

Moates Ostrich EPROM emulator: http://www.moates.net/ostrich-20-the-new-breed-p-169.html

How to hook up diagnostics to your IAW ECU

Background information

All of the mentioned ECUs run on the mentioned Motorola HC11 CPU. The program for all of them is placed in a 64K EPROM chip, 27C512 is its proper code. To do anything useful with the ECU it needs to have an EPROM socket instead of the chip soldered in.

The differences between the ECUs (will talk about differences in the programs themselves later) are the following:

  • 16F family for 1.1 and 1.2 SPI engines, single injector system
  • 8F/18F for 1.2 old MPI (Punto / Palio 75), multiple but batch-fire injector system
  • 18FD for 1.2 16V, multiple half sequential injector system

Otherwise they differ slightly inside in terms of the RAM memory size and some other bits that I do not care to know about. On the outside, apart from the injection differences they are practically identical and use the following sensors and outputs:

Sensors/inputs: RPM sensor, Water Temperature (WT) sensor, Air Temperature (AT) sensor, Throttle Position (TP) sensor, Manifold Absolute Pressure (MAP) sensor, Oxygen (Lambda) Narrowband Sensor

Outputs: Injectors, Ignition Coils (wasted spark principle), Stepper (Idle) motor, Charcoal canister, Fuel pump relay, RPM gauge signal, Warning Light signal

Reprogramming ECUs & Mapping

Most of the program running your engine is something I would call "solid state", that is, the program and tables (maps) are burned into the read-only EPROM chip. Only a few bits sit in the EEPROM (this is writeable) and can be changed in a relatively easy way (through the diagnostics connection). Here I am mainly talking about autocalibration parameters. Autocalibration is a very interesting and fascinating beast, more on that later.

So, the general scheme to reprogram one of these is:

  • take the chip out and download its contents to your PC. For this you can use a Willem EPROM programmer, tons of which are available on eBay.
  • "know" what to change in this EPROM file. This is the difficult part, a good starting point for this is the link provided above on disassembling HC11 programs.
  • once we know where the interesting tables/maps are in the program we can change them (for now just say using any binary file editor) and then

    (1) either write the new bin file to a fresh blank chip (using the same Willem EPROM programmer)

    (2) or use the Ostrich EPROM emulator from Moates

The second option is of course the most interesting one. Using this emulator not only you do not have to re-burn the chip every time you change something, you can also run in in live mode, meaning it can be updated while the ECU works. This last part sometimes gets tricky: once in a while the ECU resets itself during such a live update effectively killing the running engine. So it is not a good idea to live update the emulator while the engine is at high loads.

The one fiddly bit one has to remember about when staring on the remapping adventure with EPROM chips is that the ECU program contains a checksum check of the EPROM data. Any change to the EPROM contents will invalidate this checksum and the ECU will conclude that there is an EPROM error. This may result (depending on the version of program) in the ECU refusing to start the engine, or it will start the engine but will keep the Injection Warning Light on. The solution is to switch this checksum check off by changing one of the bit flags in the EPROM file itself (yes, you guessed it, you have to find that bit too).

Making the Process More Civilised

Editing EPROM files with binary editors has obviously certain inconvenience factor. What you do instead is use TunerPro and/or TunerPro RT. The RT version can upload the changes in the EPROM file directly to the EPROM emulator. It can also do live updates and it can also live trace cells in maps based on the connection it makes to the ECU through the diagnostics cable. Suppose that after analysing the EPROM file you figured out that a fuel map is of size 16x16 and is placed at address hex 0:LOL:EAD. You load the EPROM file into Tuner Pro, you create a new table/function, and describe the map that you identified, including the X and Y labels, conversion formula for the data in the table (in particular useful for ignition tables to know exactly what the advance is in degrees before TDC). The x and y labels (RPM and MAP pressure values) you can enter manually or you can try to identify where the so-called scales are in the EPROM file and point Tuner Pro to these locations. In any case, there is plenty of example files (both bin and definitions (.xdf files)) on the TunerPro website to look into. After defining a table you can simply double click it and edit it in a human friendly form.

As said, you can do live updates to the the emulator while you edit the tables. For that Tuner Pro RT has to be used and switched into emulation mode (otherwise you can only upload a complete file to the emulator and this effectively resets the ECU). What you still would love to have is to be able to trace cells in tables while the engine runs to show you which values were just used. This is also possible, but I have not yet tested it. For our ECUs Tuner Pro RT beta 5.0 is needed and a IAW diagnostics connection definition for it. Luckily there is one available (since recently), look on the Tuner Pro website for file named Lancia_v1_1.adx. This file is said to work with all IAW HC11 based ECUs. However, I looked into it, and as much as I can see that it in principle should, there are some minor mistakes in it (from the top of my head the ignition advance formula is wrong for our ECUs). I have not had time to play with it yet and for my purposes I actually use a small quickly hacked Java application of my own for live mapping. Anyhow, in theory, after hooking up the .adx file to Tuner Pro RT the only thing left to do is to link the x and y axis of the tables to live ECU parameters and the cell / table tracing is ready. Exactly as you have with all those facncy MS and other stand alone ECU tools. I am promising myself to try out this thing with Tuner Pro and also correct this .adx file to work correctly with our ECUs.

Bootstrapping the Disassembly/EPROM Analysis Process

OK you say, but how the feck am I supposed to know what is in these EPROM files. If you want to take the lazy way, you can try using the WinOLS program (sorry, no link, I am too lazy and do not care for this program) that tries to find maps in EPROM images simply by guessing it out of the shape of the data in the image. Guessing means testing it out, and if the program/you is not right you can get interesting ECU behaviour, including engine damage.

The other, more proper, but more difficult way, is to disassemble the program and try to figure what it is doing. The link at the top gives actually a good tutorial on how to do that. For our ECUs the great help is the diagnostics interface definition (16F Technical Documentation). What I did is I first located the diagnostics (serial communication) routine in the program. To help you with this looking for the ISO code string in the program is very helpful. Once the diagnostics code have been identified we can see where the injection times, ignition advance, rpm, etc. are stored, because from the technical documentation we know what the diagnostics should give on what request. Once you know where for example the ignition advance is stored, you can try to see how this gets calculated.

Having said all this, for those who got excited already, I need to destroy your day a bit. It took me close to 2 years of some of my spare time to analyse and experiment with the ECU to fully dissect the 8F/18F program. This is also the reason why I am not that eager to share too much of this, so that eBay will instantly become full of modified programs. But, for the brave ones that want to try things out I attached some images to this post, compliments of the Polish Centomania forum :worship:.

In the next parts I will try to give you a general description of how the ignition system works, the fuelling system, and autocalibration. The idle control code is still a little bit of a mystery to me though. And then perhaps a few insights on how I went about convincing the 18F program to understand what a turbo is :D.
 

Attachments

  • IAW_8F_5T_Punto12_75.zip
    33.6 KB · Views: 1,428
  • IAW_16F_CCS.zip
    24.9 KB · Views: 1,516
  • IAW_18F_B4_Palio12_75.zip
    35 KB · Views: 853
  • IAW_18FD_5Z_Punto12_16V.zip
    34.4 KB · Views: 965
Last edited:
Ignition System

Let's start with the simpler things. Ignition is practically static (meaning very few dynamic adjustments are made on the static data taken from maps). From the point of view of the ECU program, for the ignition system, the engine can be in one of these states:

  • cranking
  • closed throttle / idle
  • closed throttle / fuel cut-off deceleration
  • part throttle
  • Wide Open Throttle (WOT)

A word on WOT here. In all of the following, WOT is a state of the engine, not the state of the throttle itself. Pressing the throttle to the floor does not cause the WOT state right away. It has to stay there for a while. Then WOT state can be also caused by high enough pressure in the inlet manifold. In particular, if you would do a turbo conversion and run it on a stock ECU, the ECU would go into WOT each time there would be boost in the inlet. This as you guess does not require pressing the throttle that far.

For cranking there is just one or two numbers giving the initial ignition advance. For the 8F/18F program there are two such values depending on how far (in terms of RPM) the engine is from "I managed to start" state.

For the closed throttle / idle state in the 8F/18F program there is one 16 cell map depending on RPM that gives the ignition advance. On top of that this static advance is constantly corrected back and forth depending on the current RPM being below or above target idle speed. This is the only part that I know of in the ignition that is dynamic. These idle corrections make the ignition advance quite jumpy in the 1.2 MPI engine.

For the closed throttle fuel cut-off deceleration there is one 16 cell RPM based map, but without any dynamic corrections.

For part throttle there is a properly sized ignition map 16x16, function of RPM and MAP. Again in 8F/18F program. This gives a practically static advance for normal engine operation.

For WOT there is a one dimensional 16 elements RPM dependent map in the 8F/18F program. So in the WOT state the control over the advance is rather limited. This is especially important when you think turbo :cool:

Corrections and limiters

Having said that the advance is mostly static, there are several correction and limiter tables:

  • startup correction based on the coolant temperature to help with cold starts
  • correction for when the air conditioner is on (although in 8F/18F this correction is set to 0 degrees)
  • coolant temperature vs. MAP pressure correction map
  • air temperature vs. MAP pressure correction map
  • ignition advance limiter table for when the engine is not fully warmed up
  • finally ignition attack and retreat limiter tables to make sure the advance does not change too drastically from one rotation of the engine to another

Differences in other ECUs

All ECUs have almost the same ignition procedures. The main differences are in table sizes of the main maps (the correction and limiter maps also differ in sizes, but it is not that important):

  • 18FD program has a lot of RPM scales sized at 24 cells. This means that the mentioned maps are either 24x1 or 24x16.
  • 16F program has its MAP scale for all the main maps sized at 12 cells only. This means the part throttle map is 16x12 RPMxMAP.

Apart from that, it seems there is no separate closed throttle fuel cut-off deceleration map in the 18FD program.
 
Last edited:
i wish i was clever:(

My honest request to you is, if you feel that I should elaborate on something just tell me. I try to be concise and short, so that there is less reading (and less writing, it actually takes time :cool:), but I know that there are some things that perhaps I consider too obvious to even mention. So please make this interactive (y)
 
i understand pretty much everything you are saying about how ECUs refer to the tables for their operation and how some ECUs have 'higher resolution' tables than others but to reverse engineer the ECU EEPROMs is just amazing to me.

the 16F Reader thread is firmly in my bookmarks on every browser i use (even on my mobile phone) maybe twice a week i read it in awe of how much of peoples time and effort went into diciphering the hex and binary code.

programming to me is alien mainly because i just dont understand it but my hat goes off to those that do it and can then explain it to others!
 
@woj

Absolutely awesome, great work! :D

I was just looking into this the other day, was going to use the 18FD as a starting point after playing with the diag side before and then move onto the ME7.3.1 (20v VIS Bravo/Coupe). Can't wait to start playing again :D

One question, the 18FD, from what I've always understood, the EPROM is soldered and sealed, thus not removeable? So live mapping is a no-go, right? Problem is, there are no docs for the 18FD, only the 18F and there are differences which I gave up trying to understand :p
 
Last edited:
@woj

Absolutely awesome, great work! :D

I was just looking into this the other day, was going to use the 18FD as a starting point after playing with the diag side before and then move onto the ME7.3.1 (20v VIS Bravo/Coupe). Can't wait to start playing again :D

One question, the 18FD, from what I've always understood, the EPROM is soldered and sealed, thus not removeable? So live mapping is a no-go, right? Problem is, there are no docs for the 18FD, only the 18F and there are differences which I gave up trying to understand :p

Not sure if all 18FD have the chip soldered in. But if it is soldered in, you solder it out, then solder in the socket and plug in the emulator into it, and later the ready burnt chip.

Re the 18FD docs, see the top post ;)

I have not forgotten about this thread ;) still trying to find time to write about fueling and autocalibration :cool:
 
Fuelling

Fuelling is bit of a more complicated beast, even if the Auto Calibration (AC) is not taken into account. For this part let's assume there is no Auto Calibration of fuel active and also that the lambda sensor is not providing any feedback (this is for example the case when the engine is cold, or the sensor is broken/disconnected). Also, even though I know exactly all the calculations involved in producing injector timings, some of these calculations are not clear to me from the operational point of view (for example, why does the ECU need to operate additional enrichment when there is "sudden" drop in RPM or change in MAP pressure). But first things first.

During cranking the fuel is calculated from only one table and a few simple calculations. This table is WT dependent and gives different fuel dosage depending on the coldness of the engine. At this point no other corrections are made whatsoever. Once the engine reaches certain RPM threshold (never cared to see what it actually is) and there is enough voltage in the system (alternator starts to work) the main fuelling procedure goes into effect.

When no Auto Calibration is considered there is actually no separate state for idle when fuelling tables are concerned. The same procedure as for part throttle / constant load is used. Furthermore these are the states that the 18F procedure cares about:

  • part throttle / (more or less) constant engine load / idle
  • closed throttle / fuel cut-off (what I call strong deceleration). This case is simple from the point of view of fuelling - there is no fuel provided
  • more than minor change in throttle position. That is, when the driver requests acceleration or deceleration
  • substantial change (I think the ECU actually cares about drops here) in RPM
  • substantial change in MAP pressure
  • WOT state of the engine
  • first few seconds of engine operation after start-up

There are corrections interleaved in all this for WT and AT sensors, battery voltage, and atmospheric pressure. The calculation goes roughly like below, note that the unit of these calculations is not really determined until the last point where the timing is made from the final result. Also I noted on the side where Auto Calibration (AC) takes place that I will describe in the next part.

  • based on current RPM the first fuel base is calculated (+AC1, AC2, AC3). This part includes the so called trimmer parameter. This parameter is the only means by which you can steer fuelling from the level of diagnostics. It is stored in the writeable persistent EEPROM memory, and can be updated by the active diagnostics commands of ECU (see 16F Technical Documentation). Normally it is never used and the default value is 0 (no manual correction)
  • to this base the current MAP pressure sensor value is added
  • then a small altitude (current barometric pressure) correction is added (this one seems really irrelevant when one looks at the values it provides). (Side note: having a turbo effectively kills this correction as the ECU gets lost with what barometric pressure is after first boost :cool:)
  • this result is then multiplied again by an RPM dependent value (+AC4). I call this the global universal fuel corrector. Normally this step would not need to be separate from the first one (both calculate in RPM dependent things mostly) and the two could be combined together in one calculation, but they need to be separate because of different AC parameters used here and there.

OK, let's stop here for a second. This calculation already gives a first good estimate of the fuel for any constant load operation (the result is heavily dependent on MAP pressure (more air = more fuel) as expected and also, but less, dependent on RPM values). In fact, at this point the engine would already run almost fine on idle and other constant loads, perhaps running a bit lean or rich at moments. But this is not good enough for precise fuelling. Because of that next steps take place:

  • the main full resolution fuel correction is read from a 16x16 RPMxMAP table and calculated in the current fuel base. This table is the main fuel map that most people refer to. At this point the engine in part throttle should have an exact fuel dose needed for the current load. This main map is in practice only a correction map - it corrects the already known base dose, it does not give any fuel absolute bases
  • then a slight correction base on RPM is added when the engine is in WOT state
  • then the lambda correction is applied. The default factor is 1.0 (= no change) when lambda correction is not active. But it can vary from 0.75 to 1.25 in the 18F program, and from 0.66 to 1.33 in the 16F program.
  • then there is a base WT correction applied - the colder the engine the richer it gets
  • also here some more fuel is added during first few seconds after start-up, not really that important...

For any constant load including WOT we are at the point where we should get precise fuel dosage. At the very end there are two more corrections applied, one based on the AT sensor value, the other one based on the current battery voltage. The first one compensates for hot/cold intake air temperature, the second one for poorly operating injectors when there are charging problems. But, before these two are applied, corrections for changing/dynamic engine load are added:

  • extra fuel is added when there was substantial positive change in throttle opening (acceleration). This is a function of RPM, WT, and throttle position change
  • similarly fuel is subtracted when there was substantial negative change in throttle opening (deceleration), similar function as above
  • fuel is added when there is sudden RPM drop. Function of WT and RPM change. I am clueless why is this applied, and the practical implication that I can see on my AFR readings and logs is that on closing a throttle while at cruise the engine gets slightly flooded for a short while
  • fuel is added when there are substantial changes in MAP intake pressure. Again function of RPM, WT, and MAP change. My brief experimentation here shows that this correction happens seldom and again, I do not understand the practical justification behind it (Substantial load change while cruising at part throttle, like entering a hill climb?)

All this gets calculated in the part throttle dose and then the AT and battery voltage corrections take place as stated above. This is it! This gives the final injector timing.

The differences between ECUs are the following. The 16F and 18F programs differ mostly in table sizes (apart from the main map all these calculations and corrections are based on one or two dimensional maps that vary in sizes between 8 and 16 cells, and there are literally tens of these maps) and some other minor calculation details. But the overall calculation sequence is roughly the same. Most importantly, the main fuel map in IAW 16F is 16x12 (RPMxMAP). For the 18FD program the changes are bigger and I have not yet fully dissected this one. Three things I can state with some level of confidence:

  • the main fuel map is 24x16 (RPMxMAP)
  • the Auto Calibration parameters are more complex, but also more accurate
  • the lambda correction is applied after dynamic load change corrections, not before as in 16F/18F.

In the next part I will try to describe what are the closed loop operation conditions (lambda correction), how the Auto Calibration works, and how the charcoal canister interplays with all this. Also why I think that using a 1.2 ECU on a 1.1 engine or vice versa without a full remap is not actually that good of an idea (although in practice it works) :(
 
Thank you for bumping up the thread :cool: Again, I have not forgotten about it, just the time seems to be scarce these days to write something comprehensible that I promised. But I hope I can make a nice X-mas gift... ;)
 
I shouldn't have to, this thread should be stickied!! Where are the mods when you need them? This thread has a wealth of knowledge :D

really sorry Im not meeting your approval :rolleyes:
this thread will never be a sticky.
why? because nobody reads them
however i have been monitoring it and will break it down to an FAQ when its near complete/I get a chance or the OP can create a guide.thats what the section is for.

I will now go and flail myself for dereliction of duty
 
Hi Custard, I never meant this to be sticky (we don't have these any more, do we?), and yes I am planning to arrange a move to FAQ or Guides once I am done with it ;) So far I await for opinions, comments, and improvement suggestions (y)
 
really sorry Im not meeting your approval :rolleyes:
this thread will never be a sticky.
why? because nobody reads them
however i have been monitoring it and will break it down to an FAQ when its near complete/I get a chance or the OP can create a guide.thats what the section is for.

I will now go and flail myself for dereliction of duty

So you wont sticky this but in the sticky's section there's a blumming wanted ad!!! :nutter:

Usually you'll kick ass or close a wanted/for sale thread.
 
Closed loop operation

OK, so now we want to see how does lambda help in fuelling. Quite a bit in fact.

Let's start with issues of getting O2 sensor readouts. Our sensors are narrow-band types. In practice this means they only show if the fuel is below or above the stoich AFR of 14.7:1. The sensor will hardly ever, if never, show that the fuel is spot on 14.7, even if it is according to, for example, a parallel wide band lambda system. On top of that the sensor is considered unstable, it gives readouts that are in the 0-1V range, subject to dodgy screening of the signal, engine misfires, temperature of the sensor, just to name the few. For these reasons, the ECU procedure to get the readout from the sensor is actually quite complex. It keeps a short history of O2 readouts and fuel judgements made so far. After the procedure is done in every of the reading cycle, it judges two things:

  • whether the sensor is giving sensible readouts, and hence whether lambda correction can be applied
  • whether the fuel is rich or lean

The same procedure also ensures that readouts are only considered once the lambda sensor was warmed up. This is why there is no lambda correction for a fair amount of time after starting up the engine, even when the engine is properly warmed-up itself. Finally, a seriously broken sensor will be detected by this procedure and lambda correction will be switched off. Depending on the ECU, an error will be recorded in the ECU and/or the injection warning light will be light.

Even when the sensor is warmed up, and reading properly, there are situations when the ECU ignores the O2 sensor reading. First of the air and coolant temperatures need to be within "engine warm" limits. This really varies for the different ECUs we are talking about here. For the 8F/18F one, it is actually enough for the coolant temperature to be somewhere above 30 degrees IIRC for the engine to be considered "warm". Then, the readout is ignored during soft and hard deceleration (closed throttle). Hard is high revs and closed throttle, soft is low but above idle revs and closed throttle, which also results in a low manifold pressure, usually below 32kPa. And this is another switching point for lambda operation - MAP below 32kPa. Finally, the lambda correction is not applied when the engine is close to or in WOT state. WOT state we already discussed, close to WOT state means that the MAP is high enough for given RPM. For low RPM MAP needs to be practically atmospheric, for very high RPM it is enough for the MAP to be above 70kPa to go into no-lambda operation. There is a small table in the ECU which gives the RPM-MAP relation for which lambda should be switched off.

Now you ask, what about regular soft acceleration. Well, during acceleration lambda is also applied. But there is a switch in the ECU program that can switch this off IIRC. But by default lambda is on during acceleration.

This leaves us with the fact: once engine is warm and not in (close to) WOT state, nor in deceleration state, lambda sensor is constantly read and the results applied to the fuel correction.

How is the actual correction calculated? Well the longer the lambda readout stays lean/rich the bigger/smaller correction is. For the 8F/18F the limit is 0.75-1.25. Once the threshold is reached the ECU records a fault. So your fuel tables have to be close enough to 14.7 for the ECU not to go ballistic :D Come to think of it, the 0.75-1.25 range is quite wide and forgiving. For the 16F it is even wider, 0.66-1.33. Then the dynamics of changing the correction (for example, we are at 0.9 and the sensor still shows rich, how much should we change the 0.9 value?) depends on the current engine load. For this there are four load dependant 8x8 RPMxMAP tables that steer this. The semantics of these tables is way too complex to describe here, but I think that the overall result is that for some engine loads the resulting AFR will be slightly above 14.7, and for some other loads slightly below, while still for some other loads more or less spot on 14.7.

Once the lambda correction is known it is simply applied to the fuel injection time, that is the time is multiplied by the correction factor. For 8F/18F and 16F ECUs this happens before the acceleration corrections are made, as I described in previous part, for 18FD ECU my unconfirmed understanding is that the correction is always applied last (well, almost, still before air temperature and battery voltage corrections).

That's more or less it. The final word is that fuel tables are typically constructed in such a way that when the O2 sensor is broken the fuel stays on the rich side for safety. Hence high fuel consumption when lambda is gone or disconnected. In the long run this rich feature of the fuel tables is compensated by auto calibration to be described in the next part ;)
 
thanks for that latest update... its the bit ive been waiting for.

do you know anymore about rpms and manifold pressures at which 14.7afr is kept?
does the engine run at 14.7 while cruising?
I run mine at near 16.0 afr at low throttle/cruising to try get good economy and it works well. just wondered if the stock ecu does this to and to what extent?
 
Back
Top