E30 M42 to Motronic 1.7.3 Conversion Project

[bmwman91]

So in the code, is it set up to switch S702.20 for Check Engine indication, even though it is not connected to anything? If so, then it is pretty easy to modify the PCB to connect this pin to actually perform its function. The "missing" items in the T430 circuit, whatever they may have been originally intended for, can be populated and used to provide a switched ground for the CE light.

I am mostly certain that the T430 section is not for the CE light since M1.7.2 also is also missing these components, including the US-spec ones. Perhaps it was part of some other engine system in a non-BMW car?

[Rasp]

Why you so worry about CE light? If you need it for government - just short circuit with oil lamp :) On stop engine its lights, on running its extinct. Thats all.

Practically this does not make any sense, because Motronics before M5 has quite conditional plausibility check, only border states. Thats why defective engine can work for a years without CE light or DTC.

[Rasp]

Perhaps it was part of some other engine system in a non-BMW car?

It's hard for me to say, let's assume what this system could do, tell it from the electric point of view.

[bmwman91]

I find the CE light to be very helpful actually. Vacuum leaks, sensor issues, etc. It is a better "early warning" system than waiting for issues big enough to notice by sound/feel of the engine. The ability to get the CE light to report 4 digit fault codes is also nice since it means no need for extra diagnostic tools.

But yes, also it is somewhat needed for inspection here. That much is simple since it only needs to be on when in accessory mode, and off when running. The car is so old that nobody actually checks for stored faults during inspection.

For T430, if there is code to switch S702.22, then maybe a clue is there. First we need to figure out which command changes this pin though! Still working on that, but I have been busy finishing plans for the full repaint of my car...there are like 100 little plastic clips and plugs to replace since they are old and cracked. Once I get those ordered and I strip the car down to drop off at the paint shop, I should be back on this 100%.

[wazzu70]

Just ran across this thread/project. Its awesome!

From the previous thread, the diagnostic code is a very large chunk of whats in the ECU. More so on newer systems than older, but it almost takes more code to predict engine behavior than to create it :)

If you work backward from the DTCs you should be able to get a good idea of what the measurements are, and where the functional tables are if they are not known already. Since IDA lays everything out pretty nicely you can see all the places a measurement is used/manipulated.

The thread on Romraider for the E36 Siemens ECU might be of interest to you if you have not read through it. Similar project and the methodology should be similar as well even if the processor, etc is different.

Is DAMOS what Bosch calls the A2L/ASAP? I see it used on German car forums, but is it an industry term? Maybe the term is used in other platforms, but I only work with German cars!

Wish I had time to dig into this myself and join the fun! I don’t have assembly code (most our stuff is just done through simulink models) experience, but I am a calibrator so I can recognise the algorithms and figure what they are doing and why for the most part.

[bmwman91]

Good info, thanks. I will go see what all is in the Romraider thread you mentioned.

DAMOS is, I assume, a German acronym for something. The PDFs I have of ancient scanned paper ones are basically giant definition files for the tables and various constants, telling you what their addresses are, the conversion factors into "real" / engineering units and the names of the quantities they represent. I am not sure if the A2L files are the same thing, those seem to be used along side OLS files in WinOLS, or at least people usually have them together.

Once we get a little further into the disassembly and start identifying functional blocks (assuming it is arranged in a way to make that possible) then I'd be all for hearing some input on how it all compares to more modern stuff. It's all super interesting to me, regardless of usefulness.

So do you now work on engine management / tuning stuff professionally in the automotive industry? I think that we have both been into the E30 world since we were still students...finding some of my old threads is pretty funny because I had no clue at all about so much a decade ago!

[nando]

There's no such thing as a DAMOS or A2L for a DME this old - the format didn't exist for one. A "DAMOS" for Motronic is basically a bunch of printed pages of data that programmers could use to tune the car (like what you have scanned to PDF).

Also people tend to use "DAMOS" interchangeably with a WinOLS project - but they're not the same thing. If you are lucky enough to find an A2L/ASAP2 file for your DME, that is definitely the best format to work with raw data..

[Rasp]

Good info, thanks. I will go see what all is in the Romraider thread you mentioned.

There is no point, MS41 is same as M1 like a snake same as a hedgehog.

A2L/ASAP is just modern DAMOS distributed in files, not on paper with hex addresses :)

[bmwman91]

Yeah, sounds about right. I am always curious though, although I do have to set priorities!

So I have been continuing through the RESET code (yes yes, it is init/error checking stuff, not so much functional). I have reason to believe that the 8K of data in the 80C515 internal ROM is actually different than what is in the first 8K on the EPROM. I have found a loop which creates a sum of PMem values from 0x0 - 0xFEFF. Summing the EPROM values and truncating to 16 bit gives 0x624D. Assuming that the data at 0xFF00-FF01 is the expected checksum, its value is 0xC48F.

Since you (Rasp) noted that the stuff on the EPROM from 0x0 - 0x1FFF does not do anything, my guess is that it is debug code or something, which is different than what is in the MCU. None of this matters very much (I think) since the internal ROM is most likely only interrupt vectors, but I think that it will be good for me to dump the internal ROM anyway so that we know we are working with 100% of the true functional code.

Anyway, am I correct that the checksum is at 0xFF00-FF01? The suspected checksum function has its call address at 0xADAC. I have been making notes in the IDA project in the "nando_ida" folder on the Dropbox.

If the above is accurate, then PSW.5 (F0) is a flag to indicate a checksum error for at least part of the code, RAM 0x28.1 = 1 indicates checksum error, XRAM 0x020C is a fault indicator when = 0x55 and XRAM 0x020B is more or less a down-counter for cases of (XRAM 0x020C = 0x55) which turns off the fuel pump relay when it gets to zero. So far it seems like 0x55 (and sometimes its complement 0xAA) are values which signal an error condition in various RAM locations.

More to come.....

[Rasp]

Summing the EPROM values and truncating to 16 bit gives 0x624D. Assuming that the data at 0xFF00-FF01 is the expected checksum, its value is 0xC48F.

You just make mistake in your calculations, so you completely wrong about assumption that ROM and EEPROM 0-1FFFh is not equal.

Anyway, am I correct that the checksum is at 0xFF00-FF01?

Yes.

The suspected checksum function has its call address at 0xADAC.

RAM 0x28.1 = 1 indicates checksum error

Only for debug/factory mode, which used this code.

[bmwman91]

Weird, I used HexEdit to do the sum and it was giving a very different answer. Maybe its checksum function is broken or doing something different than a simple summation.

What is the "switch" or setting that tells the code to run in factory/debug mode? Knowing that would make it easier to know which sections of code are not at all useful. There is a lot of stuff going on in the RESET code that is not super obvious to me (like writing to RAM and immediately reading it back to see if the value is different), and some that is (like initializing the serial UART, Timer2, etc).

If a lot of the stuff in RESET is debug junk, then I would like to stop spending time on that and get to the important stuff that actually gets used. Some of the boot/init stuff is important to me because I want to know how the different peripherals (UART, timers, ADC, CCP, etc) are initialized, but I do not care about factory debug code.

[Rasp]

What is the "switch" or setting that tells the code to run in factory/debug mode?

Its hard to ask question, because if you has spent a lot of time in firmware - you see that :)

Update XDF definition, fix dead time conversion factor.

[bmwman91]

I spent some hours tonight going through other areas in the main loop since that code is more related to things that matter. Specifically, I worked through the call to 0xC587. I have more to go over in the call, but it looks like this mostly deals with IAT and CLT linearization, or at least something to do with those parameters. I will need to keep going through more main routine calls over the weekend. Hopefully I will begin to get small amounts of understanding about how it is operating. I am still not quite sure what I will need to do to get my M42 running on this, or I should say running WELL. The engine will probably run with stock M1.7.3 if I make a few wiring changes, and with EWS disabled, but it would probably not be much fun!

Anyway, many more hours are needed in the firmware, that much is very obvious. Do you think that all of the necessary switches (disabling DISA, EWS, etc) can be done through the XDF with small or no firmware changes? I would like to try to help with that in some way, so if there is a specific area to try to look into understanding let me know. I know that there are one or two electrical projects that could be helpful, like adapting NVSRAM, so I can also just look into that.

[bmwman91]

Spent some time working on IEX3 making notes in it tonight. Mostly in the branch where there is no sync to the crank wheel gap, and the various tests it performs to determine if sync is established, or if sync is not yet established or if an error/random pulse has been detected. This seems like a very important interrupt since the crank wheel drives it, and that seems to be the primary sensor for determining all critical engine events. Going through it is giving a little more understanding of some things, but I also need to review more of the 80C515 datasheet since I am not as familiar as I should be with the timers and capture/compare systems used in this controller.

[wazzu70]

So do you now work on engine management / tuning stuff professionally in the automotive industry? I think that we have both been into the E30 world since we were still students...finding some of my old threads is pretty funny because I had no clue at all about so much a decade ago!

Yeah you and I have been around a while on here and the M42 board so we have crossed paths a number of times in threads like this!

If you still come out to Redmond for work let me know and if you are willing to drive north a bit I can show you my work facility.

I do diagnostics calibration for the fuel and misfire systems for PACCAR engines (Kenworth/Peterbilt). I interface a lot with CARB and being a heavy duty diesel guy we are now very hated by regulators thanks to VW :( Its an overall interesting job, but I think Nando has more fun than me doing what he is doing! I spend 90% of my time to get that last 10% dialed in!

I work in here a lot: https://youtu.be/zu4r2taGI6Y