Modifying Motronic 2.3.2 ECU hardware and software.

[Tonks4x4]

So you have written your own software to decode and trace the ECU?
What language have you written in?

[vwnut8392]

This functionality does not exist in the ECU.
I wrote custom firmware for the ECU to include ability to data log, as well as custom drivers/tools for Windows to be able to talk to the ECU.
I communicate with the ECU at 187500 baud over K-Line...
The file is a CSV generated by a standalone custom tool, and yes, I have the ability to log any variable in the ECU.

There is a factory logging protocol in there as well, mcmess, but it's not very good.
My protocol is currently logging 29 ram cells, 20 times per second.
McMess can do cylinder-synchronous 3 bytes from boost/knock chip and IIRC 12 bytes crank-synchronous from the fuel/ign chip.

As I said, knowing what the maps are is just a small piece of the puzzle. You will never be able to tune this ECU that well without writing custom add ons for it.
And these add ons are my own proprietary work. This is not something Bosch ever put in the ECU...

i knew you had done alot but not this much, wow. well i have to start somewhere if im going to attempt to get on the same page as you. i know it takes years of learning and prior knowledge to do this. personally i dont have an electronics background directly nor have i ever done any schooling but i have a want to learn about all of it. im a computer guy who carried over the love for working with them to my cars. i figure if i can use the setup i build to learn atleast basic functionality than it should help me with learning how to decompile the binaries in IDApro. Im determined to learn this and i i dont care how long or how much it cost's me, i will learn it.

[a4kquattro]

I just have stuff like this:

Looks familiar

[prj]

So you have written your own software to decode and trace the ECU?
What language have you written in?

Assembler for the portion that runs inside the ecu.
C for the bit that runs in Windows

[vwnut8392]

very neat PRJ. i just realized your avatar is a smoothed RS2 ignition map lol. i havnt had time myself to look at anything else lately because i've been slaving on repairing a few imac's for my buddy's business. i have to replace 27 capicitors in 6 machines and its a pain. im still waiting on that other URS4 so i can start setting up the mock engine.

[vwnut8392]

Well i worked with the URS4/URS6 4A0 907 551AA chip set a little bit and came up with these XDF's. I know their not perfect but their a step in the right direction. the category labeled "Differences by comparison" are differences i found between comparing the 551C RS2 binary and an MTM stage 1+ file. those maps are different in some way in comparison to the original 551AA file. i've been trying to figure out the axis's for the boost chip with little luck. also i think i have the XDF for the boost chip setup so it will correct the checksum. Im not sure if it actually works as i havn't tested it. Please use these with caution as they aren't perfect and revisions/input to them is much appreciated.

[kaross]

nice, that someone wants to understand these ECUs.

I think you should read this to better understand this Motronic.
http://www.mikroe.com/chapters/view/...-architecture/
M2.3.2 uses 8051 MCU.

[Tonks4x4]

I am even more inclined to stick with Motronic now Dimitri has cracked the code to run without a MAF

[vwnut8392]

nice, that someone wants to understand these ECUs.

I think you should read this to better understand this Motronic.
http://www.mikroe.com/chapters/view/...-architecture/
M2.3.2 uses 8051 MCU.

thanks for the link, i've been reading that off and on for several days.

I am even more inclined to stick with Motronic now Dimitri has cracked the code to run without a MAF

How do you run without a MAF? motronic bases most of its fueling from the oxygen sensor and the MAF. i dont know if i'd feel safe with running M2.3.2 without a MAF. if a MAP sensor could be used in its place that would be great. i know the MAP sensor in the ECU is only used for the boost control end and nothing at all pertaining to the timing/fuel end so using the onboard map sensor is out of the question unless there is some custom code made for it to be possible but i highly doubt that would happen.

also disregard the checksum calculation in the last XDF, as it is just easier to do it manually for now. Go to XDF-XDF Header info-checksum tab and delete both of those in the XDF and save it. they will only cause more problems for getting the checksum right.

anyhow a user on a another forum im a member of by the name of RS4BOOST has helped me by explaining how to correct the boost chip's checksum right. i'll explain where it is on the chip and how to correct it.

The first thing your going to want to do is go download a copy of HxD hex editor.
Here's a link to the download page for it, pick the language that suites you best.
http://mh-nexus.de/en/downloads.php?product=HxD

once ya have that open your modified 32k boost chip BIN file in HxD. highlight from 0x0000 to 0x3FFF. next you'll want to click analysis up top and pick checksum. with the little window open pick "Checksum-16" and make sure the region radio button is highlighted. and say OK. after that a window will pop up showing the 16 bit checksum.
That part of the checksum goes at at offset 0X3FFA and ends at 0X3FFB. now for the next 2 sets of bits in the checksum. these have to be inverted and to do so you must take the checksum you calculated with HxD and subtract it from FFFF. once you have those values input them into offset 0-3ffC and offset 0x3ffD. Oh and the last to sets of bits ar ethe ECU's internal number. To do this math easily you can simply use the calculator in windows. To do that open it up, click view and than programmer. once that is up make sure you click the radio button on the left for HEX and your good to go to calculate the second half of the checksum.

Here is the example from RS4BOOST. These example are from stock bainaries for so you can see what is exactly changed.

xx = 16Bit Checksum of the complete binary file
yy = binary complement of xx => FFFF - xx

zz is an internal Bosch build number of the file

Here different examples for the last 6 Bytes (xx yy zz):

Audi S2 - ABY - M2.3.2
895907551A* *- 0261203145 - 1267357519
...F9 D9* *06 26* *A1 47 => FFFF - F9D9 = 0626

Audi S6 - AAN - M2.3.2
4A0907551C - 0261203601 - 1267358644
...0A 96* *F5 69* *A2 45 => FFFF - 0A96 = F569

Audi RS2 - ADU - M2.3.2
8A0907551C* - 0261203543 - 1267358647
...AA 37* *55 C8* *A2 53 => FFFF - AA37 = 55C8

Regards Tom

Also remeber that with the 32K files they are technically a double file so if you modify anything from 0x0000 to 0x3FFF you must make the same identical modification from 0x4000 to 0x7FFF. also the checksum is repeated starting at 0x7FFA so if you change it at 0x3FFA you must make it identical at 0x7FFA.

Feels good to have some help with this and i'd like to thank tom AKA RS4BOOST for explaining that for me because my brain is fried from working on all this. hope this helps all you guys with the steps toward tuning you own ECU's.

[kaross]

you are a bit wrong. There is no doubt.

PRJ has written custom code for MAFless M2.3.2.

[vwnut8392]

you are a bit wrong. There is no doubt.

PRJ has written custom code for MAFless M2.3.2.

Well its a shame he doesnt share this code with the rest of the world, id be interested in seeing it.

[irishs2]

Well its a shame he doesnt share this code with the rest of the world, id be interested in seeing it.

Really?Wow! do you put any value on the mans work?

[Sonic]

Id love quite a few people to release their code, but given the time and money they or the company have put into it, and the competitive advantage it gives them, that's not going to happen.

[kaross]

Please without offtopic again.

this is PRJ work and it is his decision what to do. Share or not to share. Nothing more about it.

[andy10v]

How do you run without a MAF? motronic bases most of its fueling from the oxygen sensor and the MAF. i dont know if i'd feel safe with running M2.3.2 without a MAF. if a MAP sensor could be used in its place that would be great. i know the MAP sensor in the ECU is only used for the boost control end and nothing at all pertaining to the timing/fuel end so using the onboard map sensor is out of the question unless there is some custom code made for it to be possible but i highly doubt that would happen.

Custom

http://www.s2forum.com/forum/showthread.php?t=63752

Marc/EFI are doing it as well.