NefMoto

Attached is a document of all of the variables in RAM that I have documented. These have all come from my ECU disassembly in IDA of the 8D0907551M 002 binary. I documented all of these originally for use in my data logger. They have all been tested via my data logger, but there may still be errors. I have attached the reference ECU binary as well.

Update, here are a few more variables:
wkrdy 0xF9B4 byte unsigned degrees 0.75
etazws 0x380D96 Percent byte unsigned 0.5
dzws 0x380D95 Degrees byte signed 0.75
zwopt 0x380CB6 Degrees byte signed 0.75
zwsol 0x380D97 Degrees byte signed 0.75

thanks tony!

direct download here (hopefully mime type plain/text and not BIN)

http://nyet.org/cars/files/8D0907551M_0002%20RAM%20Variables.txt

Wow. Just goes to show how little APR cares (cared?) about PID tuning. I always wondered why ECUx never included any of those (CRITICAL!) values.

Also, of note:

Max spec MAP is 0xff*10 = 2550 mBar
Max measured MAP is 0xffff/25.6 = 2559.9609375 mBar *BEFORE DSLOFS*

AFTER DSLOFS, max measure MAP is 2559.9609375 - 16.4065 = 2543.55... bad news :)

Wow, good work Tony. I have some questions:

1. where did yo uget the naming conventions?
2. when you say "address" witihin the RAM, does it just mean that if one were to be picking up data she'd have to probe at that address with her own Motronic routines, or is it just a simple request via their protocol/API and you just provide the address and size where probing is desired?

(Displaimer: I may not know enough about the logging infrastructure to be asking the right questions.)

Nyet try and explain what you mean by bad news. As I understand it, we have an 8-byte integer limitation on the maximum requested boost. Yeah... but what do we know about the sensor itself and the voltage-signal interpretation? There are some 16-byte integers in there for measured boost! Isn't that good news in some sense? OK, so for the purpose of controlling boost with PID and such internally (closed-loop with ECU PID functions), doesn't that mean that the sensor may be providing accurate readings for higher boost, and then it would work just fine?

(I am thinking out loud and could be dead-wrong here.)

First off: byte != bit

The accuracy isn't really relevant. I was pointing out that the maximum measured value is lower than the maximum possible set-point if you use the stock DSLOFS.

Not good.

Yes, sorry, I mean bit.

I still do not understand -- and that may be fine. If there were a way to bypass the specified boost (since it is all load based other than component protection), couldn't we just do PID with the existing sensor? (Provided it can physically read accurately boost higher than 2550 or so mbar.)

Great collection. Lots of these variables have not been prepared for logging even by Bosch.
Just two minor things I saw:
(Address=0x380984, DataType=UINT8, Scale=(1.0 / 1.25), Offset=(0.0), Name="Vehicle Speed", Units="km/h")

I think it must be Scale=(1.25) instead.

(Address=0x380F88, DataType=INT16, Scale=(1.0 / 256.0), Offset=(0.0), Name="Bank 1 Intake Camshaft Adjustment", Units="Degrees")
(Address=0x380F8A, DataType=INT16, Scale=(1.0 / 256.0), Offset=(0.0), Name="Bank 2 Intake Camshaft Adjustment", Units="Degrees")

Here Bank 1 and Bank 2 must be exchanged.

Tony

Great stuff this.  Good work!

Just so you can cross ref with Bosch docs:

0xf878 is called nmot
0xf9fc is called zw_out
0x380c76 is called ldtvm

You've noted 0x380bbe as intake temp, Bosch use 0x380bbf called tans in their docs.  Tans is copied from 0x380bbf post sensor error check I think, at program counter 0x85deb8.

0x380b43 is called plsol, it is created at program counter 0x852A0A  from 0x382284 which is plsol_w, by what looks like a cast to uint8. plsol_w is used more frequently.

I think actual boost is at 0x382214, called pvdk_w (pressure in front of the throttle plate is the translation).  It's a word.

I'll write something to pull these out of other S4 roms.

Here is what I have for Bosch translations:

http://s4wiki.com/wiki/Motronic_abbreviations

I think we should work in some of the variables nyet lists on the translation. 

0x380bbe is tanslin.
For Boost values: pvdkds_w is at 0x382216 and pvdks_w at 0x38221A.

I was working since some time on a tool that extracts information about variables out of ME7 images.
The list of RAM cells that Spen gave me once inspired me to dig further ...
Basically the list of variables in section TKMWL of the Funktionsrahmen is processed, as far as possible.
I hope to get this finished in the near future.

Ahh, ok, I won't duplicate effort! Good luck.

Well, I'm still continuing work on the tool to discover variables and other things in ME7 images
as far as time allows. At this point I wanted to give a first impression of the results for review.

I prepared output for the M-Box as example, as this is most widely used here.
At first there is an overview which variables get logged in the measurement groups
when using KWP1285 (e.g. with VCDS):
  -> see attached file 8D0907551M.grp
Might be usefull if you are wondering which internal variables you see in VCDS logs.
This list is not fully correct when a result consists of multiple variables or bitmasks,
but for single values it is fine.

Then there is the list of variables that are detected from the image:
  -> see attached file 8D0907551M.ecu
In this file, the alias names are just at the starting point and definitely it's needed to add more of them.
The comments in the file are derived from damos/asap2 files, so they are in German ...  :P.
I checked the data for correctness as far as possible using all images with matching damos
files I have on my hands.

The .ecu file in the current format is used as logger input. In the meantime I had successful runs   
with my ECU and my serial interface cable, but I could not gather experience besides this setup.
Next step on this will be to check with other ECUs/cables, but I won't distribute tools to public
before having some basic functionality working also with other setups.
Would one or two be willing to act as beta tester?

Happy Easter!  :)

Maybe interested to somebody...
Here is full RAM locations list for

Audi Allroad 2.7T
4Z7907551S  0020
0261208288
Sw: 1037368391

Variables names are in Bosch abbreviations.
Legend text in German

setzi, if the offer is still up, I would caan test out your tool with various ECU's :)

pm me your email, then I can collect & send something for you to test.

The vehicle speed is stored in RAM as the actual speed times 1.25, so the scale of 1.0 / 1.25 is needed to convert to the real value.

All of the variables I posted were derived using the code that implements the KWP1281 measuring blocks function. So unless the measuring blocks are wrong, then I am pretty sure that the intake cam adjustments are for the correct banks.

Any info on why you think these variables are wrong?

Hi Tony,

for the vehicle speed it is quite easy to see: if you would calculate RAM-Value / 1.25,
the variable (is an UINT8) can keep only 255 / 1.25 km/h = 204 km/h.
Having a look at the definition of 'vfzg' in ASAP2 files, it is of type 'vfzg_ub_q1p25'
and it can store speeds from 0 .. 318.75 km/h. The definition of 'vfzg_ub_q1p25' contains
conversion factors (COEFFS 0 1 0 0 0 1.25) which result in the conversion
formula: INT = (0*PHYS^2 + 1*PHYS + 0) / (0 * PHYS^2 + 0 * PHYS + 1.25) = PHYS / 1.25
-> You have to multiply the internal value with 1.25 to get to the physical km/h.

For the two intake cam adjustments:
I used the result type numbers defined in the Funktionsrahmen, section TKMWL, page 1555:
179 wnwi_w  Nockenwellenverstellung Bank1 SY_BDE=0               degKW 34 100 +/-100 degKW
180 wnwi2_w Nockenwellenverst.Bank2       SY_BDE=0 & SY_STERVK=1 degKW 34 100 +/-100 degKW

When I look into the image, type 179(0xB3) uses address 0x380F8A and type 180(0xB4) uses 0x380F88.
Therefore I was thinking they are mixed up in your definition.

But in the meas group definitions in the image, it seems like they mixed up also Bank1 and Bank2
for the measurement reports of ME7.1:
measgroup 090: 0001(nmot   ), 008D(      ), 00B4(wnwi2_w), 00B3(wnwi_w )
measgroup 091: 0001(nmot   ), 0002(rl    ), 008D(       ), 00B4(wnwi2_w)
measgroup 092: 0001(nmot   ), 0002(rl    ), 008D(       ), 00B3(wnwi_w )

For a single-bank engine, type B3 is used in the measurement group definition:
measgroup 090: 0001(nmot   ), 025F(      ), 00B3(wnwi_w ), 0000(----   )
measgroup 091: 0001(nmot   ), 0002(rl    ), 025F(       ), 00B3(wnwi_w )
measgroup 092: 0000(----   ), 0000(----  ), 0000(----   ), 0000(----   )

Now I'm confused, seems like Bosch mixed up two times. Can't say which one is for which bank,
but most probably the first address is for Bank1 and the second for Bank2 as you said.
Is there a way to determine the bank from the code which uses the variables?