Documentary - Motronic 1.7 DIY Reverse Engineering

[araohfilho]

Thanks bmwman91, for now i don't have any posts on this project, but when this project will be ready to sell, some videos explaining how it works will be published on my channel. I will try to find a video a video that i sent a friend last year and send you a pm with the youtube link.

https://www.youtube.com/@zkteletronica

[bmwman91]

Hi bmwman91, the main goal for my prototypes of this ecu is to make a module that can replace the original without any change on wiring or parts, so all actuators, sensors and the can networked dash were modeled and are supported on my current firmware.

The coils are dumb and on another ecu project that i made part of the electronics on 2008, the driver had mosfets and some bjts for driving.

On this project, to reduce board size, the only option for me was to use the ST VB025 driver, its a great driver and give some limited diagnostics, but the driving current must be carefuly calculated before every driving cycle. Thermal are really a problem on this delphi case.

I posted a photo of the current version of the board and you can see some of the choices i made. This version works well on bench up to 8000rpm and were tested on the car till 4000rpm, there are some issues now on idle, and i think that making a proper fuel trim long term will be needed.

Today this project is waiting for me to finish another project and on the meantime i am searching on patents and any document that can help me solve this idle issue.

That is a very impressive project, I am really happy to see someone taking skills to that level!

Yes, driving ignition coils can be tricky for sure. Aside form having to deal with large flyback spikes on the switched primary leg, dwell current is highly dependent on other system variables and needs to be accounted for to get smooth running. Hopefully you sort out your idle problem. Do you have any posts or anything where you document this project? I would love to follow along!

[araohfilho]

Are you going to use "smart" ignition coils with internal ignitors, or will you be using "dumb" coils like the ones in the E30 which require driver transistors?

Hi bmwman91, the main goal for my prototypes of this ecu is to make a module that can replace the original without any change on wiring or parts, so all actuators, sensors and the can networked dash were modeled and are supported on my current firmware.

The coils are dumb and on another ecu project that i made part of the electronics on 2008, the driver had mosfets and some bjts for driving.

On this project, to reduce board size, the only option for me was to use the ST VB025 driver, its a great driver and give some limited diagnostics, but the driving current must be carefuly calculated before every driving cycle. Thermal are really a problem on this delphi case.

I posted a photo of the current version of the board and you can see some of the choices i made. This version works well on bench up to 8000rpm and were tested on the car till 4000rpm, there are some issues now on idle, and i think that making a proper fuel trim long term will be needed.

Today this project is waiting for me to finish another project and on the meantime i am searching on patents and any document that can help me solve this idle issue.

[bmwman91]

Thanks for the kind words.

I am not aware of any funktionsrahmen in the public domain for these ancient ECUs, although supposedly some people have copies.

Are you going to use "smart" ignition coils with internal ignitors, or will you be using "dumb" coils like the ones in the E30 which require driver transistors?

[araohfilho]

What a nice job bmwman91 did on reverse engineering this ecu. I'm now working on my own ecu module the with firmware and electronics made from scratch for another model of car. The electronics and the can bus are almost done. But on some areas like short term fuel trim it will be very helful to see for example which sensors were involved on these older modules to get a better idle on my current setup. I've seen some funktionsrahmen on newer ecu's but none for the older ones, does anybody knows if there are any of these manuals around for the 90's ecus?

[petejk]

I think I commented out this code, not because it didn’t work, but because nobody ever used it lol.

I’d be happy to run your file, at the very least it will validate my algorithm, and at worst you’ll be no worse off than you are now. Send me a pm and we can transfer files through email

Thanks, I sent you a PM

[nando]

Nando,

I found this thread as I've been trying to find a tool to calculate the correct checksum for my modified M70 DME rom. It was sold to me by a German tuner, and as a result, the checksum was not corrected (early EU 850i do not come with a check engine bulb in the dash as US cars do).
If you could help out I would appreciate it. I'm a new poster here, as I usually post on bimmerforums.

Thanks,
Pete

I think I commented out this code, not because it didn’t work, but because nobody ever used it lol.

I’d be happy to run your file, at the very least it will validate my algorithm, and at worst you’ll be no worse off than you are now. Send me a pm and we can transfer files through email

[petejk]

I added the M1.7 checksum to my web app a while back. I also tested it on a couple other DMEs (such as the M70) and it worked fine. Would be cool to extend it to 1.3, even if 1.7 is much improved 1.3 is far more common on the E30.

Nando,

I found this thread as I've been trying to find a tool to calculate the correct checksum for my modified M70 DME rom. It was sold to me by a German tuner, and as a result, the checksum was not corrected (early EU 850i do not come with a check engine bulb in the dash as US cars do).
If you could help out I would appreciate it. I'm a new poster here, as I usually post on bimmerforums.

Thanks,
Pete

[tjwasiak]

I added the M1.7 checksum to my web app a while back. I also tested it on a couple other DMEs (such as the M70) and it worked fine. Would be cool to extend it to 1.3, even if 1.7 is much improved 1.3 is far more common on the E30.

M1.3 checksum is same as M1.7, same addresses and same way of calculation (both are using same ROM contents).

[tjwasiak]

Spark Cut RPM Limiter test file

Here is a quick dirty file i patched that has a hard spark RPM limiter. this file is an output from biela's IDB file so its stock with only my code changes. i would only suggest someone with a chip emulator like a moates ostrich and understands how to use tuner pro RT to test this because some of the variables will have to be adjusted to see if its going to work right.

to test it open tuner pro RT and load an XDF that matches this BIN. you will have add a few new things to your XDF.
RPM Limit hex address=0x4127 equation=X*40
Ignition Dwell Angle address=0x412D equation=0.75*(X-30)
Actual Ignition Angle address=0x4130 equation=0.75*(X-30) This is ATDC not BTDC(...)

Unfortunately your spark cut test file is wrong. It is not going to work in M1.3/M1.7 simply because you used wrong factor and offset for ignition advance value stored in RAM_50. Using your code "as is" you are getting ignition @46,5* BTDC which could be harmful at low engine speeds and high load values (throttle fully opened). Proper value for BMW M1.3 and M1.7 (did not checked M1.7.2&M1.7.3 variants) to get ignition @39* ATDC as you intend would be 0xC4 as proper values are factor: -0,75 and offset: 108.
I have tested very similar code in M1.3 ECU (M40B16 engine, stock exhaust with catalytic converter) and using ignition angle 30* ATDC and stock dwell angle it just cuts... Perhaps it needs more retarded ignition or more dwell.
It seems vehicle speed should be stored in EXT RAM @0xA4 but at least in M1.3 I need more testing to get working launch control. I will post my code as soon as it will be fully functional.

High speed logging output base

I made a base high speed logging output file for M1.7. This is made from an audi M2.3.2 file that i made several months back. The RAM variables are not right for the output but the base is there. i corrected all the jumps so that everything flows correctly and keeps logic with this code. over all it still needs work but could be tested using a freeware program called coolterm. coolterm will show the raw hex code output on a serial port. the baud rate for this is 187500 which is the maximum that the processor can output.

for hardware you will need to use a generic blue VAG cable or a BMW K+DCAN cable connected to the K-line. how it should work is when the key is on and engine in not running you have access to the factory diagnostics but when the car is running the high speed data logging protocol takes over and starts constant output.

The suggested RAM variables along with their equations that need to be found/added to this are
-RPM in RAM
-Ignition angle in RAM
-coolant temp in RAM
-intake air temp in RAM
-injector constant in RAM
-Injector dead time in RAM
-Injector on time high and low bytes in RAM
-wheel speed in RAM
-TPS position through ADC
-Load (preferribly 16bit because load could be uncapped) in RAM
-MAF voltage
-Knock control retard degree or counts of knock in RAM

Also a wideband input could be added for logging as well, how i did it before was i found a spare unused ADC input on the processor and wired the 0-5V output from my zeitronix wideband controller into that. also using the ZT-3 controller it will simulate the 0-1V output of the stock lambda controller too! the ZT-3 is the best bang for the buck wideband controller on the market with both 0-5V and 0-1V dual outputs!

With something like this working it will make the job of reverse engineering the rest of the ECU a heck of a lot easier because you can just change RAM variables and see what your output is. The other end of this that will need to be setup is a tuner pro RT ADX definition and dash layout. for now though using coolterm to get the logging output working is the first step. if you can get data to flow and see the raw hex in coolterm than you have something thats working.

in coolterm you need to add 187500 baud to the through adding baudrates.ini file to the cooltermwin folder. you can make this with a text editor. in the baudrates.ini file add this and save the ini file.

[baudrates]
187500=187500

this is all i can do because i dont own an E30 to test anything with so someone with 8051 knowledge, a moates ostrich emulator and some free time in their hands will have to develop this further.

files attached are an IDB for IDA 7.0 that has the logging code patched in and the BIN file itself that is a direct output from the IDB.(...)

This code is not going to work in any M1.x ECU!!!
First of all you placed it in wrong place - 0x0-0x2000 is placed in ROM and even M1.7.3 is using code from ROM!!!
I did not have time to do any further tests but with your code placed correctly in M1.3 dump and configured in such a way it is working only when A/C is on (I have some switches wired into A/C ON and A/C compressor engaged inputs - those could be used checking status of bits 6&7 in RAM_20 - at least in M1.3 and M1.7) with engine running and activating the code engine just dies after few seconds. The only modification I did was to put proper RAM (engine speed, load, coolant temperature, IAT, oxygen sensor voltage - all 8bit) addresses and removing other data. I am not sure if it is related to usage of bit RAM_24.4, wrong XRAM area or maybe 187500bit is too much for those 8051 when engine is running. I am going to do more tests when time permits.

[bmwman91]

M1.7 has two injection modes:
>>> Batched - Fires all 4 injectors at once. It does this when starting, when the cam position sensor is not functioning and also under some other fault conditions.
>>> Banked - Fires injectors 1+3 and 2+4 separately (2 sets of 2 injectors). This is the normal operating mode used when the engine is running and there are no hardware faults with any sensors.

[reloadstorino]

if I understood what you are saying is to improve the cold start injected in the 4? and then goes on par? Thank you

[pazi88]

Cranking is bit different than running and many ecus do that batch fire to start engine easier.

[reloadstorino]

Hello, sorry to deflect the thread of the converzacion, but I have a doubt, in the motronic 1.7 the injection is simultaneous? inject the 4 cylinders at the same time? I have in my workshop a 318 1993 model with that type of injection. I am looking for manuals of that injection to verify if it is correct or is there a problem? thanks for your time


so I understood it injected in pairs, but here it would not be happening

https://youtu.be/3hABSENEzlM

[vwnut8392]

It's been super busy for me the last week or so, and will probably continue to be. But, there's a lot of cool stuff going on in here all of a sudden lol. I am not likely to be testing the ignition-based rev limiter since I have a WBO2 and catalytic converter on the car, but we'll get it figured out.

The way that the tables are accessed seems nuts to me. Like, super inefficient, especially considering how badly these ECUs could use more instruction cycles in the main loop at high RPM. Anyway, I will try to take a look through instruction areas that look like what you showed and trace them into the actual table accesses. I'd really like to see how they look-up and interpolate table values since the way that axes are defined seems like it would inherently eat way more instruction cycles than necessary.

The checksum is dead simple on these DME's. It just sums up all of the values in program memory from 0x0000 - 0x9FFF, EXCLUDING 0x3F00 - 0x3FFF in the full 40K binary dump (0x1F00:1FFF in the EPROM) and truncates them to a 16 bit value, which is stored at 0x3F00:3F01. The value of 46367 from my previous post is simply the sum of the 8K internal program memory of the SAB80C515 MCU, which is mainly just interrupt vectors and some other stuff I am unsure of. I used the constant because I had not yet dumped the internal MCU program memory. This is identical in M1.3 & M1.7, and probably others. The IDA project based on "TotalCombinedROM" uses a binary I made by dumping the MCU's internal 8K via the K-line and combining it with the 32K from the EPROM (well, actually I just tapped an Arduino directly into the MCU's UART).

thats awesome how you got the data from the MCU! when it comes it arduino programming or anything in that area im stupid. i focused all my learning over the years to being able to just read the raw HEX from the 8051 or 68HC11 and follow it. my friends say i can see into the matrix because i can roughly follow code without IDA if i need to and make raw edits to the binary that actually work lol. tell me to make something in C or write a sketch for arduino and i'll just sit there and beat my head off a desk. im like the rain man of programming .

i'd like to learn how to do more with arduino because i bought a freematics one+ programmable OBD logger. i wanted to see if i could get it to work with the M232 data logging protocol. this would be awesome because that device has an SD card port for standalone logging without a PC, bluetooth and wifi that could be used for wireless logging of the old motronic. i made a really good looking winlog dash for M232 recently and i'd like to make a quick mount in my car for a windows tablet and use it as a virtual multi gauge/dash. would be way cooler than having all these separate gauges mounted all over the place. but the problem is i cant write ardunio code and i have no idea where to even start with getting that rolling. why i bring this up is because this idea could also work on the BMW DME if a similar data output protocol is achieved like in my other posts ;D.