Hacking the Motronic ECU (Audi RS2)

[prj]

This has nothing to do with motronic data. You are posting in the wrong thread.

[vertigone]

I don't know if I can ask this here , but it speaks about motronic data too
1- Anyone has translate to "human language" the block 00 for 3b motor ?
2 - how do you reset adaptation tables ?

[prj]

Thank you, this is a great info.
Too bad I do not know assembly.

I hope you guy post more info.
Again, thks

If you want more info, you must give some info of your own.
You can not learn this by only reading, and for everyone there is a limit on how much info they will give without getting anything in return.

[kotnelson]

Thank you, this is a great info.
Too bad I do not know assembly.

I hope you guy post more info.
Again, thks

[S2central.net]

I can tell you where the injector constant is... PM coming

[prj]

You are making good progress there... you are absolutely right about limitations with assembly code - I thought I would have learnt a lot from it, but you mostly get a headache. This is why you need tracing in real-time and why I decided to go for the engine simulator so that I can traverse maps much more accurately and repeatably on a bench - and to see some other scenarios as well.

Thanks... and we both came to the same conclusion it seems.

One thing I did learn from disasembly output is that much of the code at the bottom of chip (0x0000) is interrupt routines for the micro - I have never tried to reverse engineer them yet - a memory map would be awful useful as well to know where the I/O for sensors and actuators is addressed... again I hope my simulator will help that.

Memory map you say. Just checking, but are you aware, that the axis constants in many cases ARE the memory locations? Only some are "fake"...
I have a pretty good idea on how to figure out what is stored in the memory locations using the trace function on the emu. I can PM you with that, if you like...

I guess you have worked out the trick for calculating axis on the maps - I wrote something in PHP that helps a lot. Tis a pain doing it manually - thank goodness as I have actually forgotten how to do it manually now

That is very, very easy. There is enough information on the net that literally spoonfeeds it to you. What is a lot harder is translating those numbers into real world values. Like if you have coolant temp 182 in decimal in the map axis, it tells you nothing. You can only guess without a trace.

I seem to recall there are some maps not mentioned in the directory but I am not 100% sure sitting here.

I don't think so. What I found not mentioned in the directory were things like the RPM limiter... I have a lot of work to do still. Most importantly to figure out where the injector constants are and do some more work to understand how some stuff works in the turbo map.

[S2central.net]

You are making good progress there... you are absolutely right about limitations with assembly code - I thought I would have learnt a lot from it, but you mostly get a headache. This is why you need tracing in real-time and why I decided to go for the engine simulator so that I can traverse maps much more accurately and repeatably on a bench - and to see some other scenarios as well.

One thing I did learn from disasembly output is that much of the code at the bottom of chip (0x0000) is interrupt routines for the micro - I have never tried to reverse engineer them yet - a memory map would be awful useful as well to know where the I/O for sensors and actuators is addressed... again I hope my simulator will help that.

I guess you have worked out the trick for calculating axis on the maps - I wrote something in PHP that helps a lot. Tis a pain doing it manually - thank goodness as I have actually forgotten how to do it manually now

I seem to recall there are some maps not mentioned in the directory but I am not 100% sure sitting here.

[prj]

Going to post a little bit more on topic.

Something that is very helpful in finding things is having many different ECU files.
If you take the 27C512 files from the 551C ECU from an S6 and a 551C ECU from an RS2 they are almost identical, the only difference is in the maps and some constants. This eases the task a lot.

To look deeper into this, one must understand how the EPROM is generally laid out.
From what I understand this applies to any ECU used in cars with the AAN, ABY and ADU engines. When you have many files, you can find some similar ones. For example by comparing the software of the late RS2 with the S6 from the ECU with the same number, you can figure out a lot of things.

This seems to be the EPROM layout of the 27C512 chip:
From 0x0000 to 0x1FFFF you have from what I understand the main Bosch software provided with any ECU. From what I have read, it used to be in the internal ROM of the CPU in earlier motronics. Luckily it does not seem to be the case here.
From 0x2000 to 0x7FFF (in the later "C" ecu-s to 0x9FFF) should be the manufacturer specific code.
Actually it is not that important to know which code belongs to whom, just that 0x0000 to 0x7FFF (or 0x9FFF) is mostly code that can be disassembled and looked at.

After this, at 0x8000 (A, AA, B) or 0xA000 (C) comes some more data that is static between different car types. I haven't tried to figure out what it is yet.

Things get interesting after another 300h (0xA300 or 0x8300), where there is a small block of data, some padding and after 20h more (0xA320 or 0x8320) there is a data area, which varies between different cars. The rev limiter is located in this area, and at my guess perhaps the "injector constants" (krkte) are somewhere around here as well.

Now comes one of the most important parts. At 0x8800 or 0xA800 in the later ECU-s is the master table. It simply contains all 16 bit addresses of the tables found in the ECU. At my guess (again... I hate guessing), almost every table that is referenced by the ECU is here. The only things that are exempt are the constants, such as the rev limiter, about the location of which I wrote above.

Finally we get to the map data. From 0x8A00 (0xAA00) until 0xFEFF we have all the maps one after another, as referenced by the map table above. The maps are dynamic. It is possible to resize and rescale them, and the ECU will cope. This is evidenced by the fact, that software for the ADU engine is exactly the same as for AAN (bar one byte) and the maps have different dimensions.
There is enough information online on how to read the maps, no point for me to repeat it here.

And now we are done. At 0xFF00 we have the checksum, after which we have the ECU version, then for lack of a better name "the string that gets displayed in VAG-COM" and finally the exact version of the software.

So, this is the structure of the fuel chip. We also of course have the turbo chip, but that is for another time.


The difficulty comes from understanding what each of these maps and constants do, and how they are read. This is where the real work begins.

One can get some hints from the assembly:
The 8051 CPU always uses it's 16 bit register (DPTR) to load data from external memory (EPROM). One of the instructions to load a static location, is MOV DPTR, #data. In hex it is 90 followed by the address. Interaction with the register is little-endian, so if you want to check whether the CPU directly loads a value from somewhere, you can just try to search for 90 XX XX in the hex code. Of course there are other ways to modify the data pointer, but just searching for all memory accesses in the code and mapping them out (while weeding out false positives) will give you a rough idea of what code touches what.

However, from what I gather (and from what I have been told), it is almost impossible to figure this thing out by assembly alone. A trace and some data logging is required, so that you can get rough ideas on how the multitude of analogue signals coming in and going out of the ECU are scaled and represented in digital form within the ECU software itself.

I hope this is of some help to someone. Some mistakes might have slipped in, so feel free to correct me, if I got something wrong.

Oh and, if anyone wants to help me along with figuring a few things out, It'd be pretty cool. Whether it is done in public or privately. Though from what I have seen, if you start digging in this thing, you need to have a head of your own.

[S2central.net]

Oh would probably need to fake a lambda probe signal too.

[S2central.net]

The more I think about all this - the more I need to dig up my 'engine simulator' project - in theory this makes it MUCH easier to fake the ECU into thinking it is attached to running engine... then its just a matter of tweaking some pots and/or switches to exercise all interesting areas of the chip while hooked up to an emulator. This is so much easier than driving around / burning fuel / scaring the locals / getting chased by police etc etc - and also gives one simulator that will play with all types of 20VT ECU.

I have decided to move this along in two phases. I might need some help on the simulation circuitry so I would be happy to collaborate on that in the interests of scientific exploration.

I have something that will simulate the rpm sawtooth waveform at fixed rates. A simple tooth counter could trigger a couple of astables that simulate crank reference and camshaft reference pulses at the right time... With a powered up ECU this is all we need to make it think the engine is running... Then use pots to set IAT, ECT, MAF, TPS, Altitude etc etc and make sure all ECU outputs are loaded with something to keep it happy. Add some flashing lights to simulate sparks for fun and thats it. Easy to say, but trickier to carry out properly. I have done some high level elaboration at systems for this already - just never invested time & effort to follow it through.

I would need some help to design the analog stuff that generates the crank reference signal in particular as it has a really odd shape... Could just be some fun with an old school 555 timer that can create a waveform that is good enough to be interpretated by the ECU. I am fine with designing the counter circuit to trigger that though.

[prj]

Ostrich is OK - I did have the very occasional crash when dumping new binaries in, but real-time edits are fine. I got in the habit of pulling over before doing anything too radical though just cos I couldn't trust it to be 100% reliable. I haven't used it a long time - need to find time for more explorations on this stuff.

Ok, thank you. Then for just tuning and monitoring the Ostrich will be okay for me.

As for two banks on turbo chip - tis something of an anomolie alright - I can't even remember which bank is used by default (just duplicate into both banks as Tommy says) but its rather convenient for mode swapping I just figure that chip is the way it is because someone at Bosch decided they wanted to choose an oddball chip with a latched bus cos it was convenient somehow - I know it suits the micro well enough, but why not do this on both chips ? Maybe there is no latched version of the chip big enough for motor chip. Odd but nice.

Seems like our thoughts are following pretty much the same path. Oh well, I guess it is somewhat of a mystery. Though I guess it is not all that important for the actual tuning, rather more in the direction of satisfying personal curiosity.

I would love a disused airstrip to play on - it isn't easy doing tweaks on the public road.

Yeah, it's very handy, there are other things that are not that handy about this country though. Like discovering your mirror glasses being stolen in the morning

[S2central.net]

Ostrich is OK - I did have the very occasional crash when dumping new binaries in, but real-time edits are fine. I got in the habit of pulling over before doing anything too radical though just cos I couldn't trust it to be 100% reliable. I haven't used it a long time - need to find time for more explorations on this stuff.

As for two banks on turbo chip - tis something of an anomolie alright - I can't even remember which bank is used by default (just duplicate into both banks as Tommy says) but its rather convenient for mode swapping I just figure that chip is the way it is because someone at Bosch decided they wanted to choose an oddball chip with a latched bus cos it was convenient somehow - I know it suits the micro well enough, but why not do this on both chips ? Maybe there is no latched version of the chip big enough for motor chip. Odd but nice.

I would love a disused airstrip to play on - it isn't easy doing tweaks on the public road.

[prj]

asking is never too much.

Because the parts are identical, it needs to remain as it is. Mod the first part as needed and then make identical copy to next half. Did not answer to your question but works...

Yepp, I figured that out. Maybe it has something to do with the special 87C257 chip...

I also do manually the boost chip even though I have the converter base. Normally it is so that variety of existing boost chips are so close that "only small" mods are needed to wake the turbo in a proper way between 2000 to 4000 without too much overboost. The upper part is then easier.

Thank you. I have not looked that much at the turbo chip yet, I just recently started taking it apart and learning.

Real time emulator is (mostly) needed to adjust fuel & ignition and some correction factors. The trick is to do such combo where there is lowest possible fuel consumtion and enough power. The Real time adjustment is easier when lambda steering is switched off (small map where 0 values mean off; idle to ~2000 can remain under steering when adjusting ). You can adjust the mixture so that lambda oscillation is on "lower or upper" stokiometric area ~below or above the 14.7. slightly over 15 is for best economy. high 11 / low 12 is safe for power on high boost.

The little map I guess is dependant on temperature...
From what I have read, motronic runs open loop below 70C (when coolant temp is low) and also at high load. The rest of that time it runs in closed loop mode with lambda control and if you sway too much from the stoichometric ratio (14.7) the ECU will correct it. Everything you said makes perfect sense, thanks. I will also try to find that map to switch the lambda off. Also, I guess if the car being tuned does not have catalytic converters, then I can just leave the lambda disabled. Although I am not sure how that would affect the ECU in case of a MAF failure.

use exhaust temp measuring and wide band lambda to make it safe (not melt nor knock). Note that even cruising on vacum @150km/h makes the engine exhaust glowing "hot" => adjust all areas and not just the power band. Most time is needed in outside the power area to make the chip good and drivable. Many chips have far too less ignition in vacum area and low low boost (safety margins for hig tow load).

Thanks. I have an old soviet airstrip about 2km from my house. It is very good for testing various conditions. I appreciate the hints. I will also be buying a wideband controller with EGT display. Something like the one offered here: http://www.14point7.com/.

tell us how you liked the product.

Which product? If you mean Moates Ostrich 2, then I have been told that it does not always work correctly and can crash the ECU when reloading the firmware. I am trying to get more information on it before I buy.

EDIT: Regarding the Ostrich, as I got told, it can crash the ECU only during code changes (assembler) and reading of values that are larger than 1 byte. Everything else should be fine. This makes sense too. If the ECU is reading code and suddenly you modify it, it might read an incomplete opcode or a wrong combination. In case of map changing, this can not really happen, and with 1 byte values the probability of reading a wrong value is lower. Even if it would happen, you can not fail by a lot.

[Tommy200rs]

asking is never too much.

Because the parts are identical, it needs to remain as it is. Mod the first part as needed and then make identical copy to next half. Did not answer to your question but works... I also do manually the boost chip even though I have the converter base. Normally it is so that variety of existing boost chips are so close that "only small" mods are needed to wake the turbo in a proper way between 2000 to 4000 without too much overboost. The upper part is then easier.

Real time emulator is (mostly) needed to adjust fuel & ignition and some correction factors. The trick is to do such combo where there is lowest possible fuel consumtion and enough power. The Real time adjustment is easier when lambda steering is switched off (small map where 0 values mean off; idle to ~2000 can remain under steering when adjusting ). You can adjust the mixture so that lambda oscillation is on "lower or upper" stokiometric area ~below or above the 14.7. slightly over 15 is for best economy. high 11 / low 12 is safe for power on high boost.

use exhaust temp measuring and wide band lambda to make it safe (not melt nor knock). Note that even cruising on vacum @150km/h makes the engine exhaust glowing "hot" => adjust all areas and not just the power band. Most time is needed in outside the power area to make the chip good and drivable. Many chips have far too less ignition in vacum area and low low boost (safety margins for hig tow load).

tell us how you liked the product.

[prj]

I will probably meet the grand wall of silence, but who cares... here we go:
Does anyone know why our turbo chips have double data?
The two halves seem to be identical... I also disassembled it and found the checksum routine, it also only sums half the chip at once (as expected).

Is there a sort of hardware switch, that chooses which image the CPU sees?