Modifying Motronic 2.3.2 ECU hardware and software.

[-ice-]

Hi,

i can't find it at the moment, but it was based on your 'fillbuffer' routine you have posted some time ago. I replaced the whole OBD procedure with the code. Maybe some part of it is still needed, and i should have set the entry point in this procedure?!

I didn't look closer at this and started to make my own serial communcation. Something like this (Just an example to send two fixed bytes one after another):

$NOMOD51
$INCLUDE(80C515.MCU)


MOV DPTR, #0A10eh
RAM_PTR equ 63h

JBC TI, txcomplete

MOV PCON, #080h
MOV SCON, #0E8h


MOV A, RAM_PTR
MOV B, #003h
MUL AB
JMP @A+DPTR
LJMP byte1
LJMP byte2
LJMP getout

byte1:
MOV SBUF, #0aah
LJMP getout

byte2:
MOV SBUF, #0ffh
LJMP getout

getout:
INC RAM_PTR


MOV A, #01h
MOV R0,RAM_PTR
CLR C
SUBB A, R0
JC carry 
RET


carry:
MOV RAM_PTR, #00h
CLR C
RET


txcomplete:
CLR TI
RET

END

It uses the well known JMP@DPTR mechanism, which is also used in the original obd-routine. I think this will meet my requirements for a simple logging-protocol...

I discovered the revlimit word by hex comparison and using the emulator. I don't have an approach to find the code yet. Since it it has something to do with time between two flywheel pulses i guess its accesed in a Interrupt-service-routine.

I accidentaly discovered a factory logging protocol for tracking ram-variables over UART. Is it this McMess thing?

Regards

[prj]

Revlimiter is very easy on these, don't be lazy
Compare RS2 551B/C and AAN 551AA and you will see about revlimit (it's different in them).

As for your OBD routine, post your code.

[-ice-]

Special question to prj:

I would like to use the xram array to transmit my chars. So i filled it starting at location r0 = #af with length an data. But it won't transmit anything when i start it with enabling the interrupt ien0.4. it only transmitts the data which is put directly in sbuf (which i receive correct with 9600baud).
Do you have a hint for me? i replaced the whole obd routine with the code. Perhaps i missed to initialize something.

Thanks in advance.


Bye

[-ice-]

Hallo,

I'm trying to find the checksum calculation code..

So if the checksum is located @ 0xff00, i tried the following:

- see if it is accessed directly via dptr or a dptr near to this position -> no success
- see if DPH/DPL were set seperatly -> no success
- many things in the motronic are mapped, so i searched in the binary if the checksum adress is also mapped. All results weren't loaded via dptr.
- finding it by coincidence. I suggest the procedure will contain inc dptr instructions to sum up all eeprom values and calculate the checksum. But there are too many places which could have something to do with it and i haven't seen it yet.

Another idea would be to dissasemble the fault codes generation, but this will take a long time. Same thing with the rev limit, knowing where it is, doesent mean you know where it's used in the code

Does anybody know other efficient ways to find it?

Regards

[prj]

For simple mods I just look up the correct spot in IDA, write the code using a random hex editor and reload the binary to make sure I did not make a mistake.

There are only so many instructions on a 8051, it's not difficult to memorise the hex codes for the easier stuff. Of course writing longer code I use ASEM.

[-ice-]

ASEM-51 and HEX2BIN.

I tried this and it worked

I also use adis-51 v4.0. It's a graphical dissasembler with online assembler. So if you want to change single operations you can load the bin, change the operation, and compile it back to bin with one tool. For example if you want to ad a jump to your injected code its very practical.
I'm running it on a 32bit windows xp in the command shell (dont know if it runs under newer os...)

For compiling much code, i think asem 51 is better.

Regards

[prj]

Hi,

Which tools do you use to compile the (changed) code to hex?

Regards

ASEM-51 and HEX2BIN.

[-ice-]

Hi,

Which tools do you use to compile the (changed) code to hex?

Regards

[prj]

since those documents involve a non disclosure agreement with bosch why do you have them since im going to assume you dont work for bosch or are in no way affiliated with bosch. so even you having them is technically against their agreement with whoever they released them to.

1. It is none of your business.
2. Assumption is the mother of all ****ups.

As for this whole noble quest of yours. You do not value your time, I do. That is the difference. I also do not believe for a second that you are going to get anywhere at all with this, since you are attacking this from the wrong angle.

You do not need the hardware schematics to find out what is going on in IDA in the boost chip - there is extremely little code there. I found out most of the things I needed before I got the schematics, as I said. They do not help reverse engineering, they merely confirm that you are on the right track. The thing that helps reverse engineering most is the 80515/535 developers manual.

[vwnut8392]

Basically all i want to do is what the volvo community has done with motronic 4.4. a complete tunerpro definition for both boards along with plugins for the checksums and a way to data log the ECU over the OBD port. most people who would use these have never paid for chip tuning and refuse to pay for chip tuning like myself. i would sooner figure out a way to run another fuel system i can tune myself rather an pay someone to tune my car for me. me retrofitting digifant 1 to 10V NA and turbo engines and fitting motronic 4.4 to my other URS6 avant is an example. there are plenty of people who would rather just pay someone to tune their ECU with no questions asked and im not one of them people. im not made of money and i dont have 2000.00+ dollars to buy standalone so i find alternative ways to achieve what i want.

[vwnut8392]

Hi,

is it possible to highlight one of this yellow lines? This would be nice to trace a single connection.
I don't think it's a waste of time. Sure, factory documents are better, but it could be helpful.


Bye

They will be once im finished. the picture above is just a screen capture from adobe illustrator. you will be able to select individual tracks, select a piece of hardware for information on it and remove individual levels and tracks so you can easily find what your looking for.

sure the using the measuring blocks would work on the fuel/timing chip but there is nothing in the blocks involving the the boost board side. finding any info the fuel/timing side is out there, the mystery is in the boost board as its software isnt layed out like a conventional motronic file with the scalars and axis before each map. i dont have the programming knowledge to work with the OBD protocol like you so im taking another route that will allow me to see all the I/O ports connected to the CPU from a visual prospective and work with IDApro from there and be able to tell what everything does.

since those documents involve a non disclosure agreement with bosch why do you have them since im going to assume you dont work for bosch or are in no way affiliated with bosch. so even you having them is technically against their agreement with whoever they released them to. besides all the bosch documentation floating around on the internet is part of a non disclosure agreement and their still out there for the public to view and no one has lost their life over it. bosch only protects the documentation because of all of the government mandated features they have to add for things like emissions regulations and such. these governments dont want the common folk being able to disable these features and cheat their emissions regulations and stuff. in the states its one of many ways for the man to pinch my wallet and tax me for something as pointless as what comes out of the exhaust on my car. its not my fault gas isnt a clean burning fuel but i have to pay the piper ever year for it.

[prj]

I have no idea how to highlight one of those yellow lines, because I can not see markings on those ECU pictures. And without markings I do not know where is what on the board.
You must understand, the factory schematic is a logical electronic schematic. Not a board layout file.

All the inputs to the fuel-ign processor are exactly the same.

They come in, have a cap connected to them, then a pullup or pulldown resistor, and then an in-line resistor. After the in-line resistor they all go to S900, which is basically like dual schottkey diode IC. It limits the voltage to 0-5V so you do not fry the processor if you connect some larger voltage source or something is shorted to 12v.
After that they run into the corresponding ADC pin on the CPU.

The only thing connected in series is the inline resistor, everything else is connected in parallel. So all you have to do to retrace the signals is trace the CPU ADC pins to S900 and then from the S900 to the resistors, and from the resistor other end to the pins.

But as I said, this is a really difficult way to do this! The much easier way is to just take the OBD logic in the CPU, look which ram location is what input, and then xref that ram location and see where it is written. Then you not only find which ADC pin the signal is taken from, but you also find the linearization maps for IAT, ECT and so on.

Regardless, all this is not needed for correct mapping. It does not matter in the slightest how the CPU internally gets ECT or IAT or battery voltage. What matters is where in RAM they are stored and how they are used inside the CPU. Even if you had the full schematic of the ECU, it would not be that helpful for disassembling the ECU.
I got the schematic very late into my learning of this ECU, and by that time I had disassembled and mapped most pins by hand that I needed.
Let's say like this - it is better to start in the software, and then if you NEED some signal for mapping or NEED to understand where something is coming from, only THEN start tracing the PCB. This way you will actually get things done.

[-ice-]

Hi,

is it possible to highlight one of this yellow lines? This would be nice to trace a single connection.
I don't think it's a waste of time. Sure, factory documents are better, but it could be helpful.


Bye

[prj]

The schematic is interesting for the analog-inputs. The multiplexer is set by software. So i if you know which Sensor is physically connected to which AIN you know which sensor is actually sampled in the software. This will help to understand the software...

I haven't done this yet. So i you want to trace something, the Analog inputs please

Bye

You do not need this information to reverse engineer how sensors are read.
Disassemble the measuring blocks in OBD II diagnostics and you will see how every single value is sampled.
It is not so difficult to do and I did this long before I had any schematics.

[vwnut8392]

The schematic is interesting for the analog-inputs. The multiplexer is set by software. So i if you know which Sensor is physically connected to which AIN you know which sensor is actually sampled in the software. This will help to understand the software...

I haven't done this yet. So i you want to trace something, the Analog inputs please

Bye

this is one of the reasons why i am doing what im doing. basically im doing all of the pain in the butt tedious work for everyone and giving it away. once im done with it life should be alot easier for everyone to trace out the ECU.

ok, this is going nowhere then as always.
The schematics are under Bosch NDA.

I could care less what their under in all honestly. if its re-typed and worded a different way than its no longer bocsch's document. i was close to getting them through my friend who owns a local porsche/audi dealership and an RS2 but he died in january sadly. besides theres no law that says i cant create my own diagrams and distribute them freely. there stuff isnt going to be a complete secret forever and im going to make sure of that. once i finish these schematics im going to move on to working with the I/O ports and seeing what they connect to like -ice- said and im going to write up more schematics and documents for that as well and eventually move back to decompiling the software and posting all of my findings for that too. its only a matter of time before this info spreads like wild fire around the audi community and people will be able to tune their cars freely.

Here's an update on the bottom so far, i have to beep a few tracks out with the multimeter and than that side will be done. these are just screen shots, the real pictures are super high resolution, i had a friend who's a professional photographer take the ECU pictures for me.


on another note im making an attempt to retrofit motronic 4.4 from a volvo S70 to an ANN engine. its looking very promising, i have work on a crank trigger setup and a few other sensors. if this all works out than it will be great! this ECU is full open source and the volvo community has been very open about the ECU. i think it will make a great update over stock 2.3.2 ECU. These guys have implemented some pretty cool features to the ECU like map switching and a knock light. i like the work they did on the data logging end of things in relation to doing it in turnerproRT. they have a plugin to use a generic 20.00 VCDS cable in tunerproRT for data logging along with a tunerpro definition thats very complete plus a tunerpro checksum plugin and the best part is its all free unlike the greedy VW/audi community.

Here's a wiki that someone created that relates to tuning and datalogging the motronic 4.4 ECU. http://m44.wikia.com/wiki/M44_Wiki