Documentary - Motronic 1.7 DIY Reverse Engineering

[bmwman91]

Alrighty, I found the wiring diagrams for the E36 with M1.7.3. It looks like it supports full sequential injection, along with all of the software improvements that you mentioned. I had thought about M5.2 at one point since I really wanted sequential injection, but there is so little information out there for it! Obviously sequential injection requires harness modifications, but that is fine.

http://www.e30tuner.com/assist/m173re/E36_M1p7p3_WiringDiagrams.pdf

One more question about the M1.7.3 DME's. There seem to be a lot of BMW part numbers for these, with newer ones superseding the old ones. Some seem to be flash based with the version listed as BMS43 instead of M1.7.3. Any ideas on what the differences are between all these PNs, and does it even matter?
http://www.realoem.com/bmw/enUS/part...&q=12141432060

Two flavors seem to be common eBay...12141432060 and 12141432519.

[bmwman91]

Thanks. So basically, one big improvement is that the injector constants in M1.7.3 actually work in the way that you would expect (since changing them in M1.x does not properly adjust for different injectors and you still have to remap everything)?

Can you run full sequential injection with M1.7.3 (individual injector control)? There are not enough CCP/PWM outputs on S700 to do it, but it looks like S702 has extra PWM pins which are not used in M1.7 so it could be possible there.

Overall, it sounds like the fueling model is a lot more advanced in M1.7.3 if it is actually using TPS% for more than switch points. But I thought that even M1.7 did some sort of wall film compensation?

I guess that if I am going to do a lot more work on this, maybe I should consider M1.7.3 going forward since I would imagine that there are going to be big differences in the firmware. What microcontroller does it use? 80C535 which has no internal ROM, and then everything on the external 27C512 EPROM?

[Rasp]

Very cool! So when you did full disassembly projects, did you go through the ASM code and make all of your own comments and re-name things to make more sense to you?

Yes, I have some info about variables and math functions used everywhere in listing, will share this info later. Code matched to diag and DTC not too big :) My circle of interests is migration to M1.7.3 (done), migration to "modern" injectors (done), migration to MAF (in progress) and then migration to MAP (in future).

Rasp, can you give a summary of your thoughts on the benefits/limits of M1.7, M1.7.2 and M1.7.3? I know you said that you feel that M1.7.3 is possibly the best option to run on the M42, and I would be interested to know more.

Ok.

Benefits M1.7.2:
1) Knock detection system, seriously just this fact is enought for migration.
2) Updated software - many things are reworked, for example Wall film (Acceleration enrichment), after start enrichment, overheat enrichment (it not used, but can de configured :) )

Benefits M1.7.3:
1) M1.7.3 is final edition of M1.7 :)
2) It has more interesting schematic (I guess some slightly more I/O pins)
3) It has 64K EPROM and no need to clean original firmware for adding some custom code (like in M1.7.2 - it has very little empty space inside 32K EPROM)
4) It has new modern (and cheap) IAC valve with two windings like E46 M43 (of course any M1.7 can be modified by software and hardare to use it, but this is an additional job)
5) It use new modern injectors which can be directly replaced by another BMW injectors, for example I'm use M52B25 injectors for my M43 engine (of course any M1.7 can be modified for software to use same injectors, but its a lot of calibration work for fuel enrichment, wall film compensation, dead-time, e.t.c. this work no one will do and no one will do correctly)
6) It use correct VAF limp mode by throttle which can be used with individual throttle bodies, unlike other M1.7
7) It use IAT compensation tables for ignithion, which not bad if you wants turbo...
8) It use both models for Wall Film compensation (Acceleration enrichment) by throttle and by load, which good if you want add MAP in load factor calculation.
9) and a lot of other differencies in software.

[bmwman91]

I received the 990 DME today. Yup, it is a cousin to the 175 DME, but there are differences. A lot of the IC's are updated versions of the previous ones, there's the A250 knock processor board, and one of the 6-channel mid-current drivers (S470) is no longer present.

I have not gone though enough to say for sure, but I feel like regular M1.7 might be a more capable system because it seems a lot more generic (designed to run a lot of different engines) versus M1.7.2 which looks like it is a lot more specific to the M42 and it has a lot less unused outputs and IO's.



Rasp, can you give a summary of your thoughts on the benefits/limits of M1.7, M1.7.2 and M1.7.3? I know you said that you feel that M1.7.3 is possibly the best option to run on the M42, and I would be interested to know more.

[bmwman91]

Neat. Are most of the mid-90's and early 00's systems 8052-based, or something else entirely?

[nando]

I used to be really into MS back in the day - I was one of the first to run an MS3 kit when it came out, I built MS1/MS2 PnP setups before it was even a thing, etc. My M20 still runs MS3 (mostly reliably), but honestly - I've been playing with OEM computers for the last 5 years or so, and I don't think I could go back.. at least, not on something that wasn't a complete toy/science experiment.

After several years of constant tweaking just to keep it from driving me crazy (I daily drove with it for years, all 4 seasons, as my only car), I just could never do that again. There are some things, like startup, coast down, and idle, where the OEM computer 'just works' that you will almost never get right on something tuned from scratch. Sure, people will say theirs is fine - but I doubt many people here have put anywhere near as many miles or driven in as many conditions on Megasquirt as I have, so I don't really buy it.

I've been working on a BMW tuning platform for the last two years - currently the oldest I support is MS45. I'd love to support these old Motronics but there's only so much time in a day..

[bmwman91]

Yeah, the newer DME's with their digital DAMOS defs are so much easier to work with. There is a DAMOS from a Group-A M3 / M1.0 floating around over on ecuconnections, and it is literally a scan of pages from either a typewriter or a dot matrix printer. I also have a scan of a M3.1 DAMOS, also a paper scan with hand-written corrections lol. But that one was given to me by someone who had requested it not be made public, so it's not getting posted.

The purpose of this goes waaaay beyond simple remapping. That is, as you mentioned, easy enough to do. I'd like to see just what all can be done with these old systems in terms of adding more modern functionality. It could all end up being a waste of time, and I have zero commercial interest in this. Worst-case, I just go back to my original plan and do a super clean plug-n-play install of MS3Pro.

[nando]

It certainly helps you guess at them if you know the inputs (tps, load, rpm, etc), but it doesn't have anything that says 'I'm a fuel map!" because IDA is much higher level than that.

It does at least map out where all of them are, but at least on Motronic that's pretty obvious without a disassembly anyway. The value is in what I stated above.

On newer DMEs you can map a Damos file into your disassembly which is awesome, but on these old DMEs the Damos was literally printed or written down on a sheet of paper and are basically all lost (or buried in Bosch's archives somewhere).

That's why cutting apart the DME is necessary, since now you can map each output in the disassembly to the pins on the DME, and then you can know that a certain map is related to ignition etc.

[Mykk540i/6]

Very interesting!

Using the IDE are you able to identify the function of maps?

[Rasp]

What was in your post which is under moderation?

Nevermind, I'm already almost said everything in other posts. Only M1.7.2 vs M1.7.3 comparison need to write again.

As for the "JMP @A+DPTR" I found 5 instances of this which seem to be in code regions. The SAB80C515 reference manual also describes this as a way to make a decision-tree, which is what it looks like in IDA.

Yes, you absolutely right! I'm a dumb, skip this parts of code... I'm add this info (and how to fix offsets) in my first post and will say this in the following messages.

The checksum makes more sense now, I was not accounting for the fact that the 40K addressing is different than the 32K addressing when looking at the EPROM dump. So yes, you are correct!

In early Bosch Motronics checksum is a just checksum :) Bosch himself deceived her in his ROM (see last two bytes in each ROM files). Because ROM use some core with new additional functional with each new version. Thats why 1.7.2 rom can be used with 1.3-1.7 and there is no need to update the checksum.

As I know wrong checksum only gives an DTC, many people drive cars with this error and nevermind. It can be disabled in two ways (directly in code and in calibration data), I can tell how to do this.

What does the main loop do and is its loop speed variable depending on engine RPM? So far, the interrupt subroutine related to the crank position input seems to be the longest, most complex piece of code.

No, main loop is a background loop operation, doesnt depends on engine RPM. I wrote about it above, its lineralization of values from "slow" sensors, process all 2D and 3D maps and store results in memory for further use in interrupts, and process given RAW values from interrupts (for example Air flow to load, crankshaft timings to RPM, e.t.c.).

Thanks again for all of this. It is really great to have someone with all of this knowledge here to share it!

As one of our famous poet said: "fight together and you will win" :) Thanks you for the company and work that you did.

[bmwman91]

What was in your post which is under moderation? I don't think I have seen anyone get stuck with that before, or at least not someone who is a "real" account. Maybe try breaking the post up into 2-3 smaller ones if it was really long? Or you can see about emailing me the text and I can try posting it and make sure that it is referenced as your work?


As for the "JMP @A+DPTR" I found 5 instances of this which seem to be in code regions. The SAB80C515 reference manual also describes this as a way to make a decision-tree, which is what it looks like in IDA.

5 addresses where this instruction is found:


Example of the decision tree:



The checksum makes more sense now, I was not accounting for the fact that the 40K addressing is different than the 32K addressing when looking at the EPROM dump. So yes, you are correct!


The "RESERVED" instructions are gone now that I properly marked more of the data sections.


(maybe this is in your moderated post)
What does the main loop do and is its loop speed variable depending on engine RPM? So far, the interrupt subroutine related to the crank position input seems to be the longest, most complex piece of code.

Thanks again for all of this. It is really great to have someone with all of this knowledge here to share it!

[Rasp]

Trying to answer again, probably the previous post will not be never moderated :)

There are one or two large ones, and a number of small ones (some I was able to fix because they use "JMP @A+DPTR" which cannot be properly traced without real emulation).

Motronic do not use construction like "JMP @A+DPTR", this can be data instead of code, or debug code. Does not matter, it's not something you need to pay attention, just leave as data.

My guess is that M1.7.2/3 have the same main board, but maybe different daughter boards in A250 and A200. So, depending on this I might be able to build a complete 1.7.3 schematic for you.

All Motronic 1.7 family use completely different hardware. M1.7.2 use daughter board, M1.7.3 - is not, M1.7 M40/M42 look like you described, M1.7 M70 looks like ordinary M1.7, but has external ADC with 10 bit resolution for MAF reading.

Do you know what the difference between the 0261203277 DME and the 0261200990 / 0261203282 / 0261203357 DME units which I believe were all M1.7.2 units used on US E36 M42 cars between 1992 & 1995?

As I know its same hardware on this DMEs.

Also,
A long time ago I found a simple EXE on some random website to calculate checksums for a few different DME's.

Checksum in BMW Motronics calculate by "Checksum-16" from 0x0000h to [firmware size - 0x100h], for full firmware, placed result word in address [firmware size - 0x100h]. convert.exe is do this job with convert 40K to 32K firmware and for 64K without convertation.

There are some instructions in the disassembly which try to directly access locations in the 80h-FFh range, but do not correspond to SFR's. An example would be "MOV A, RESERVED_B2" or something like that. I can make a list of these instructions later, and maybe they all fall into data constant regions which I have not correctly identified. Thoughts?

Please give screenshots or addresess in firmware. This can be:
1) Data instead of code :) as is often caused with unclear instructions in C51.
2) This is part of debug code
3) Construction like "MOV SP, " is valid in this case.

[bmwman91]

Very cool! So when you did full disassembly projects, did you go through the ASM code and make all of your own comments and re-name things to make more sense to you? As in, you went through 100% of the code and understood all sub-functions, calls, etc? I feel like there is a lot going on in the code, and it jumps all over the place! How much of the code and data constants are entirely related to error checks / fault conditions / Check Engine Light?

[Rasp]

Thats for BMW Motronic, I did a long time ago:

I will look into doing that as one of my first customization projects...

Best way for first done as much as possible with the existing code, matching tables and variables.

[bmwman91]

Awesome. The DEF file in the tool is very helpful in a number of ways since a lot of info about axis descriptors / RAM addresses is there.

PRJ in the M2.3.2 project changed the source code to increase the baud rate and the data output rate. I think that maybe I will look into doing that as one of my first customization projects..."high" speed direct data logging!