Modifying Motronic 2.3.2 ECU hardware and software.

[-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 is no 27c256 chip in the 551AA ECU.

[-ice-]

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

[-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

[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-]

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]

Yes, you calculated right.

[-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]

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-]

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

[-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

[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,

Thank you very much for the informations.

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

Had a short look on this procedure. It accesses the 2D Map with 12 entrys which is the MAF linearization. unfortunately i couldn't recognize that before because I thought map @8a00 would be this linearization I see also the calculation of load. It's the only codepart where the load-variable is assigned with a calculated result (and not with fixed values...)

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.

With my actual knowledge I think this injection map is accessed in sub procedure 2130. i will see if i can discover different pathes there (i don't know anything about the enrichment map locations yet...)

But it's just 8051... try disassembling tricore if you get bored

The more i work with this, i realizie how much effort and "brainpower" is necessary to analyze and understand all of this code. respect!!
I'm not familiar with asm, i don't see the function behind the code as fast as you do. Even if the command-set of 8051 isn't that big. But it goes on in small steps

Bye

[prj]

I see also the calculation of load. It's the only codepart where the load-variable is assigned with a calculated result (and not with fixed values...)

Yes, but this is only 8 bit load for maps. It is not used for calculation of e.g. injection pulse length.
Internally it uses 16 bit load. Also, it is possible to de-cap the load on this ECU. If you tune this ECU correctly and hit 255 load, the 8 bit load goes to 0 (bug or feature in code... bosch did not envision 2+ bar boost i guess), but anyway, not nice for the engine to go to 30 degrees timing and lambda 1 at 2 bar ...
It is possible to fix this bug and make it stick at 255. And also remove an upper bound check for 16 bit load.

Then the ECU can deal correctly even with 3 bar of boost pressure, and I have seen 280 load

[-ice-]

Hehe i don't think Bosch considered or expected that it will go to zero after an overflow

Another case of "fixing other peoples bugs" nice