Modifying Motronic 2.3.2 ECU hardware and software.

[prj]

Hallo,
One sub procedure seems to be special (located @ 0x21ba) because it's called very often.

Yeah, it calculates the MAF linearization constant and 8 bit load that is used to lookup maps.

Why are all the map accesses in this kind of loop and not in interrupt service routines?

Because Motronic of this age has three main loops.
1. Background loop - looks up all the maps and stores results in memory
2. Crank-synchronous loop - calculates actual injection time (converts stored values to actual values for seq. injection processor), ignition timing - converts stored timing to teeth, converts MAF and so on.
3. Per-tooth loop - Integrates the MAF, fires ignition events and so on.

This is more than enough info. For everything else RTFM (User manual for SAB80C535) you can see exactly what is what if you keep in mind what I said.

Im looking for a WOT injcetion_durationmap.

Does not exist in this ECU. There is only one main injection map with corrections.
You can easily find where it is accessed, and you can also find the function that processes the values and disassemble it to understand how it works...
Just a tip - normal fueling, warmup enrichment and crank fuel all have completely different ways of calculation and different formulas as to how they work.
But it's just 8051... try disassembling tricore if you get bored

[-ice-]

Hi,

the great wall of silence

Im looking for a WOT injcetion_durationmap. The one I think it might be this map is 2D and starts at 2000rpm. I dont know if there is more interpolation at the edge points, but i think so. Am I right here?


Am I basicly right to say, that a lower value, means more fuel?

Bye

[-ice-]

Hallo,

i'm now using the IDA Disassembler to look at the code. The "graph view" is a good feature to get an overview.

As prj explained the map access procedure uses 77h/78h, 75h/76h and R2 to access a map. With the graph view i was able the group different procedures where these variables are assignend and the map_acess procedure is called. In the most cases R2 ist assigned directly before the map access call.

I followed the code of the reset vector which will lead to the main loop (not confirmed yet). In this loop the above mentioned sub procedures with the map accesses are called one after another. One sub procedure seems to be special (located @ 0x21ba) because it's called very often.

Why are all the map accesses in this kind of loop and not in interrupt service routines? I imagine the important actions like setting the injector opening time are connected with interrupts because they are time critical (f.e. a timer overflow ISR). How does this work together with the map access?

Greetings

[prj]

You need to set the size of the binary in the header info.
The ECU will never crash on emu if you only change calibration data.
There is no loop with ignition off - once the holding relay is gone, it's gone. But there is a tight loop with the engine not running.

[-ice-]

Donated money for the tunerpro guy. The math expressions of tunerpro are really usefull...


convfactor/(X*pow(2;Y)) for example displays the rev_limit, with X= high-byte and Y=low byte.

even convfactor/((X>>8)*pow(2;(X&0xff))) would work...but is not good for editing..

I missed some basic information how to control tunerpro... If i change something in the built-in hex-editor, the changes are made in the bin-file. If i change it with the GUI-windows and click save, the values aren't stored in the bin (same effect, when I'm in emulation mode...). Don't know what's wrong...

I'm surprised how stable the engine is running altough i'm playing with the emulator...no crashes yet.

prj you wrote, that there is a main-loop running even when ignition voltage is turned off. Is it therefore dangerous for the ecu to leave it connected to the harness and the permanent battery supply with a turned off Ostrich?

What will it do, when there is no data in the Fuel/Ign Eprom...maybe watchdog resets?!

Regards

[prj]

Yes, you calculated right.

[-ice-]

Already compared it with B version and it makes sense (for the moment), because for automatic transmission the division factor is higher... Around 6600rpm if i calculated right ...

[prj]

I posted this on another forum a while back:

Rev limiters in these older ECU's are of two types. Some ECU's have one, some the other.

One type is minimum time between two flywheel teeth.
That one works by dividing a number related to the microprocessors frequency by a 16 bit float which in these is X/2^Y if X is high byte and Y is low byte.
Other one is just a 16 bit integer, which is again time between flywheel teeth and is the microprocessors frequency divided by the value.

In both cases, if you want to have higher RPM you must lower the value.

I'm not going to tell you where it is, you have an emulator and IDA Pro, it should be a walk in the park to find it.
I will give you a hint though - automatic had a lower rev limiter

[-ice-]

Ok, engine is running with the emulator

Will try to find the fuel cut rev limiter for fun. I think it it is located in the Block after 0x8300 and will have 2 Bytes. Maybe word 82h03h

Does anybody know?

Bye

[-ice-]

Sorry, I meant 27C512 64kb (0x0000-0xFFFF) for fuel an ignition. I am getting crazy with my eproms here

[prj]

There is no 27c256 chip in the 551AA ECU.

[-ice-]

I think it's a problem with the galep3.

When I write with EmUtility first, read it again with EmUtility, the bin file is still correct and the same. The Galep3 Sofware still "sees" this offset.

Thanks

P.S. I am working still with the 27c256 non buffered eprom and 551aa definition. The 0x7ff have nothing to say...

[prj]

There should not be any problems.
Try loading the binary using EmUtility, just to rule out that you have incorrectly configured your TunerPro project.

Load it to the ECU and communicate...

P.S. I notice the buffer length is 7FFF. Are you working with 3B? If it is AAN, loading a 87C257 file will NOT work, the 87C257 has a tri-state latch, which the Ostrich does not have.

[-ice-]

I have received my Ostrich today

I decided to use TunerPro RT with this emulator but I seem to have a problem with loading the binary files.

I connected the emulator directly to my old eprom programmer (Galep3). I created a bin file with tunerpro (you can see it at the bottom of the screenshot). After loading this to the Ostrich I read it out with the Galep (result is at the top of the screenshot). Basicly the numbers are correct but there seems to be an offset of 1.

Does anybody know where this comes from? I don't know which device i can trust now...

bye

[minim]

Really tempted to order willem GQ-4X programmer and ostrich 2.0 to start playing with this