Modifying Motronic 2.3.2 ECU hardware and software.

[-ice-]

Ok, the harcoded first byte ist the "Kennzahl". So vagcom uses the Kennzahl to know how to calculate the result and give it a unit.


So 3A = 0x14 should be 800 rpm.


That's a simple buffer for me... first i thought it would put data directly into sbuf

Sorry... for you this is boring, because you already know everything. Thanks alot for your hints...

Greetings

[prj]

My vagcom Demo can't read Block 000

As I looked closer to the measurement block-routines, there seems to be a pattern. I think MOVX @R0 pushes a char into the uart-buffer. For every block the buffer is filled with three bytes. The first seems to be fixed an special for a block. Second an third byte seem to be parameters.
f.e. in Block 02 variable 0x3a is pushed into the buffer as last value. Previous byte is also fixed. Maybe theses are a and b in blafusels table?!

prt, dou jou have a typical 0x3a value for me running at idle rpm? Then i can check the formula and if it makes sense..

Thank you

Come on man...

Die folgende Tabelle (basierend auf der Datei Value-calculation.txt aus der Yahoo! Gruppe opendiag) zeigt die Kennzahlen für die Sensordaten (1. Byte) und deren Umrechnung, wobei a für das erste Meßwert-Byte (2. Byte) steht und b für das zweite Byte (3. Byte).

It's written right there exactly how it is. ID, A, B. Refer to that table for formulas.

There is also no magic "UART buffer". There's just an array in XRAM. If you look closely you see it increments the buffer length as well. It's just a structure of length and then a sequence of bytes.

[-ice-]

My vagcom Demo can't read Group 000

As I looked closer to the measurement block-routines, there seems to be a pattern. I think MOVX @R0 pushes a char into the uart-buffer. For every block the buffer is filled with three bytes. The first seems to be fixed an special for a block. Second an third byte seem to be parameters.
f.e. in Block 02 variable 0x3a is pushed into the buffer as last value. Previous byte is also fixed. Maybe theses are a and b in blafusels table?!

prt, dou jou have a typical 0x3a value for me with engine running at idle rpm? Then i can check the formula and if it makes sense..

Thank you

[prj]

How to replace code? You can replace the entire diagnostics routine.
All of it. Right from where it calls into it.

You can use the same buffer in xram as it does to fill it, then you have to send the data.
The diagnostics routine is called with a limit of 100 times per second at RPM below 5000, above that it starts to slow down a little, still gets about 60-70 times per second.

If you want good data - say 15 bytes and minimum 10 times per second (better is a bit more), then you need something that is executed more often. So you have to think where you do the sending of your buffer...

The map lookup routine is a good place to put your buffer sending logic for example, as that gets called very often - much more than 100 times per second.
It's just a bog standard 80C535 chip. There's no magic about it. Everything that works on a standard 8052, works here, you just have to take care not to trash the stack or overload the processor with naively written code.

[-ice-]

Step by Step, i dont't have the asm skills that you have Im not able to replace whole code parts yet, because I dont't know how the whole program works together...


Basicly I want to learn about the variables usesd, that's why i analyze the measurement routines.
I will connect my Vagcom tomorrow and then I will see which channels are the same in different Groups.

ByeBye

[prj]

And 8bcc should be group 000. But i can't find a description or label file for this group on the net. It doesn't seem to be the same with aby.

It is exactly the same on all 2.2T.
Don't believe everything you read online - there is only one truth, and this truth is in the code. Not what someone writes online...

Why do you need this anyway? It's like 4 times/sec and unstable. If you want data from the ECU, just kill the entire diagnostic routine and write your own. 187500 baud works well.

If you want to identify the scaling and memory locations in the ECU, then surely looking at 001 groups and up is MUCH more interesting, as this is standardised in KWP1281 and you can get exact formulas.

[-ice-]

I'm tired of staring at the screen

I think 8BA8 is for the 4 block groups (because of the repetive pattern of single blocks in the binary; f.e. Many groups have engine rpm in them)

And 8bcc should be group 000. But i can't find a description or label file for this group on the net. It doesn't seem to be the same with aby.

[prj]

Hi,
In the code before the jmp seem to be two cases where the accu is loaded with help of dptr (8BA8h and 8BCCh). Maybe these are the offsets you are talking about?

Correct, these map blocks to groups.
Now look a bit more and you will see how everything works.

[-ice-]

02 03 09 08
02 07 10 11
02 06 12 04
02 06 13 1D
01 17 14 1E

02 leads to engine speed, 06 to engine load?

[-ice-]

Hi,

Thank you for your reply.

I saw this block of long jumps yesterday. I didn't know they point to the measuring block routines. It depends on the accu, which of the 31 adresses is selected. The accu value itself depends on the multiplication of the accu and B. B seems to be fixed to 03h. So possible accu values for the multiplication are 01h to 1Eh to get a valid adress. In the code before the jmp seem to be two cases where the accu is loaded with help of dptr (8BA8h and 8BCCh). Maybe these are the offsets you are talking about?

I'm not sure how this data is aligned in the binary. I tried to calculate the accu-value by reading the code, but didn't find out anything useful.

For group 000 i expect ten bytes in the binary which select (after the calculation...) the coresponding ljmp adress? Is it like that?

Greetings

[prj]

Hi,

im trying to understand the obd subroutines

We know that the ECU responds with 0x55h after the "wake up" part. The UART is configured to 9600 Baud. SCON 0E8h and SMOD in PCON = 1. The two following bytes sent by the ecu aren't hardcoded (i dont know them, because i haven't logged the serial communication with a running ecu yet). The ecu waits now for an acknowledge (ff-last byte sent)

In this code area (around 0x5548) the typical vagcom strings are loaded (4a0...). There is one adress called very often after loading such data: 0x59f2. Am i right to say it's a kind of uart_send_char procedure? I think finally it sends contents of 35h.

I searching for the part where it loads the block data which are demanded by vag com. I guess there must be a sort of switch case structure which selects the data to send.

Grettings

Look for JMP @A+DPTR, you will find the jumps one after another to the 30 measuring blocks. Look at KWP1281 protocol docs on blafusel.de to understand how measuring block data is converted to real world values.
To know which block is in which group and what it represents, look just before the jump instruction and you will see two offsets. One for Group 000, one for the rest. Each group, including the 10 values in Group 000 are mapped in the binary one after another.

After this you should be able to figure out the scaling of most variables inside the ECU...

Of course it does not write directly to the port, it writes to a buffer in XRAM and then transmits this buffer over protocol. Well, you will see...

[-ice-]

Hi,

im trying to understand the obd subroutines

We know that the ECU responds with 0x55h after the "wake up" part. The UART is configured to 9600 Baud. SCON 0E8h and SMOD in PCON = 1. The two following bytes sent by the ecu aren't hardcoded (i dont know them, because i haven't logged the serial communication with a running ecu yet). The ecu waits now for an acknowledge (ff-last byte sent)

In this code area (around 0x5548) the typical vagcom strings are loaded (4a0...). There is one adress called very often after loading such data: 0x59f2. Am i right to say it's a kind of uart_send_char procedure? I think finally it sends contents of 35h.

I searching for the part where it loads the block data which are demanded by vag com. I guess there must be a sort of switch case structure which selects the data to send.

Grettings

[vwnut8392]

been trying to figure out a way to run a manual boost controller on my car now i seen theres a way to piggy back it on with the N75 but i dont like that idea. i think if i could find the proper maps in the boost chip i could just FF them and run it straight up on a manual boost controller. any hints on what i do to make this possible?

[prj]

i cant locate any data sheets on this ECU, searched high and low and i keep coming up empty handed so developing a full understanding of A15 for me is a far cry. when i said fuel cut i mean by the ECU shutting down the fuel pump relay as it has full control of it. i fought with getting the fuel pump relay to power up properly with my last AAN swap. i realized it the type 85 fuse box is missing a pin needed to make the swap easy and allow the fuel pump to act as the factory intended so i ended up using a fuse box from a 1993 audi 90 that had all of the provisions i needed for the AAN swap and was still plug and play with all of the 84 4000's connectors.

1. Look at the 87c257 datasheet.
2. ECU never shuts the fuel pump relay unless RPM falls below 13.

[vwnut8392]

i cant locate any data sheets on this ECU, searched high and low and i keep coming up empty handed so developing a full understanding of A15 for me is a far cry. when i said fuel cut i mean by the ECU shutting down the fuel pump relay as it has full control of it. i fought with getting the fuel pump relay to power up properly with my last AAN swap. i realized it the type 85 fuse box is missing a pin needed to make the swap easy and allow the fuel pump to act as the factory intended so i ended up using a fuse box from a 1993 audi 90 that had all of the provisions i needed for the AAN swap and was still plug and play with all of the 84 4000's connectors.