Modifying Motronic 2.3.2 ECU hardware and software.

[prj]

If it's the other DIP28 chip then yes, it's the external ram.
I saw a data sheet at some point, but it's nothing special.

It's a completely standard RAM. It is accessed with MOVX. You write there and you read from there, that's about it.
It stays powered from the live 12V on the ECU even with ignition out, this is why the ECU can remember fault codes.

[-ice-]

Yes, it is next to the eprom. I can't find any datasheet on the net to know the pin description.

[prj]

The pinout is basically identical to a 27c512.

[-ice-]

Possible Pin description. Has to be confirmed...

Ax = Adress Bits, Dx = Databits

1: not connected
2: A12
3: A7
4: A6
5: A5
6: A4
7: A3
8: A2
9: A1
10: A0
11: D0
12: D1
13: D2
14: Vss
15: D3
16: D4
17: D5
18: D6
19: D7
20: Chip Enable 1 low active
21: A10
22: Read Strobe low active
23: A11
24: A9
25: A8
26: Chip Enable 2
27: Write Strobe low active
28: VCC

13 Adress bits would mean 2^13 = 8192 Adresses @ 1 Byte. So it's a 8 kB RAM

[prj]

But why is this important?

[-ice-]

It's the fastest way to get data out of the ecu...

[prj]

It's not really viable, because it's only the fuel chip.
You have the boost chip as well.

I log almost all data from the ECU at 10-12 times per second even on 8000 rpm. I think it is enough.

You need to get the code working on the bench to send data to you.

[-ice-]

Hi,

the pin connections of the x-ram which I have written above seem to be correct.


I've got my x-ram Interface running now and it is really cool It's basicly a microcontroller which logs every x-ram write access. The data for every ram-address is hold in the s-ram of the microcontroller. It can be accessed later over USB (real USB, not tunneled RS232). I am able to mirror the whole x-ram with this. On the one hand you can log everything which is already in the x-ram, on the other hand you can put your data there, which should be transfered to the logging pc.

There are some adavantages instead of using the serial port of the motronic:

- You don't need to implement a serial protocol in the montronic, since you transfer data with an address. For example you set DPTR to h0041, and then put your data (which is in the accumulator) into the usb-interface with the instruction MOVX @DPTR, A. You don't have to deal with the synchronisation of the slow rs232 port and also no sync-bytes etc. are necessary.
- You can log the fastest way possible. Faster than my Windows c++ program can analyze the data since it's not a realtime os
- You won't disturb the execution of the normal motronic program too much. even sending many bytes in a row (to get parallel logging data from different variables at the same time) is possible.

Regards

[-ice-]

Just a picture how it looks like, when i'm playing with the motronic...

[prj]

Not to rain on your parade, but not everything is as rosy as you make it out to be.
1. The XRAM does not contain much useful data, so you have to copy there from RAM and that takes pretty much the same amount of resources as dumping it to serial.
2. Serial at 187500 baud is not slow at all, it's 23kb/s, which means you could log a 100 byte packet at 230hz.
3. The XRAM you are tapping is only connected to 1/2 of Motronic, you do not see anything about boost pressure, wastegate duty cycle or knock retard in cylinders.
4. You need to frankenstein the ECU, instead of using a VAG-COM cable.

I am sure when you learn better how to program the 8052, you will also use serial.
Meanwhile this tool will allow you to study the Fuel/Ign portion of the ECU better.

[prj]

Also, here is the ram data sheet:

http://k1.spdns.de//Develop/Hardware/Infomix/ICs%20computer/RAM/SRAM/6164%20%5bIS61C64AH-20%5d%208k%20x%208%20SRAM.pdf

Btw, it would be nice to find how much free space there is in ram and where it is located.
It is easily possible to modify the map reading routine to directly read from RAM, so many maps can be placed in RAM dynamically.
Also, the important constants can be placed there as well.

That makes it possible to tune the ECU without an emulator over OBD - just a thought.

[Acki]

Hehe nice idea but I guess the basics are also a "good" target because it's a lot of work.

I studied my ABH source and at the injector routine the table access is sometimes (via the R2) not clear. When I do it by hand on a paper I sometimes have the wrong address for a useful map (for example 2 maps for Water/IAT correction but the third loop isn't the third map, is another map) - often only 1 next to the map I have expect.

[-ice-]

Hello,

Accessing the x-ram is many times slower than accessing the eprom. I don't know if it would be fast enough if calibration data is stored there.

I discovered the checksum-routine which is called at the beginning of the main-program. It sets dptr to zero and increments it step by step until it reaches ff00. The content of the eprom ist added up every time and stored to register r0 and r1. The values are later compared with the stored checksum values.

and i think i've seen the rev-limiter code(s) in the external interrupt routine. There is not only 3A for RPM...we also have 3D and 3C. 3A is made out of 3D and seems to be "raw data" coming out of the capture counter. Have to look closer at this, but i'm sure it accesses the rev limiter bytes there and conpares them to the ram variables.

Regards

[prj]

Yes, you are getting to it.

I will give you a bone:
The two variables you are looking at is the time between two edges on the flywheel trigger.
The RPM limiter is simply a minimum limitation for this time.

3A is just a conversion (inversion) of this time. Because 3C and 3D get smaller with bigger RPM and 3A gets bigger with bigger RPM.

[-ice-]

Ok after looking at some logging data i come to the conclusion that 3D is the highbyte and 3C lowbyte. Like it's shown in the charts below...

3B is also rpm dependant.