No announcement yet.

Documentary - Motronic 1.7 DIY Reverse Engineering

  • Filter
  • Time
  • Show
Clear All
new posts

    Documentary - Motronic 1.7 DIY Reverse Engineering

    I am far enough into this project that I feel like I actually have interesting stuff to share. A while back I was starting to make serious plans to convert to a Megasquirt 3 Pro system, which included sketching out a very detailed wiring harness schematic since I wanted to add fully sequential injection, VW pencil coils, a hardwired MAF, knock sensing and wide-band O2 support using the factory harness. The desired features would require mods to the harness, and I wanted to have a complete sketch of the initial and final state of the wiring so that I could make it all factory-quality. Then I changed my mind and started working on a custom tune with Sssquid Tuning since that seemed like a faster way to get a tune dialed in which could be (sort of) transferred to MS3Pro later. Anyway, that was enough to get me started down the rabbit hole, so to speak, and I ended up starting to investigate stuff on a spare M1.7 ECU that I had laying around.

    As you will see, it quickly spiraled out of control, down the rabbit hole I went, and I am fairly certain that nobody has ever seen this on here before. I found one other person on a Porsche forum who reverse engineered a 911 ECU PCB, but they posted a lot less information about their results. Since joining the E30 world 18 years ago, I remember seeing wacky threads like this where someone had way too much free time and did something interesting, and I always learned stuff and wished that I could someday do crazy projects. It looks like it is my turn.

    If nothing else, this thread can be a reference for folks on the web who want to see how to DIY RE a multi-layer PCB with mostly-household tools and materials. This is still very much a work in progress, but the hardware parts of the RE effort are basically done. My attention is presently on the firmware and piecing together the last few details of the interface between some of the chips on the mainboard. My goals are as follows:

    1) Build a complete schematic-driven PCB layout of all components and connections on the M1.7 mainboard - DONE!
    2) Fill-in component values for resistors and capacitors, and characterize any Zener/Schottky/etc diodes - To Do (maybe)
    3) Dump the total 40K of ROM (32K on the EPROM, 8K internal to the microcontroller) - DONE!
    4) Disassemble the 40K ROM into assembly for understanding of its complete functionality - In progress
    5) Rewrite the ROM code to make improvements to function (faster table lookup, wide-band O2 support, etc) - To Do pending #4
    6) Other miscellaneous stuff I’ll mention when I get there

    I am going to share the hardware aspects of this project since it is visually interesting and maybe people can learn some handy stuff which can help them repair their ageing ECU, or at least understand how it works a little better. It is really a fairly simple system compared to just about anything today, but it is very robust and it is more than capable of running a gasoline engine efficiently. You may be thinking "OK, fun times, but why the hell are you wasting so much time with this obsolete ECU when you could already be running MS3Pro?" That is a fair question. The answer is "why not?" Why bother owning and modifying a car as old as the E30 at all? is fun, you learn stuff and if you finally succeed you end up with something unique. Also, I am apparently incapable of going to sleep at a reasonable hour, regardless of what time I need to be up in the morning lol.

    There is one thing that I am NOT going to do in here. That thing is posting map locations, types and how to edit them. The reason for this is that it is not my knowledge to give away. I worked with Sssquid Tuning on a custom tune for my 2.1L M42 last year, and in the process I started collaborating with him on some stuff. Unless he pops in here to detail how to DIY tune your own M1.x ECU (and I see no reason for him to do that), I am not going to post that stuff since I could not have figured it out without him.

    OK, so that is a bit of an intro. Let's get into stuff that is a little more interesting. Images I post in here are very shrunken versions of the ones I have been working off of...I don't think that we need 500MB of pics in here lol. The stuff that follows is probably ~120 hours of work spread over the last year or so.


    First, in order to understand the main PCB, I needed to build a schematic of the components on it. I started by getting detailed images of the populated top and bottom sides (a few of the larger components had been removed years ago). Each of these is actually 9 photos stitched together (the board was panned under a zoomed-in camera to get higher resolution).

    With that done, I depopulated the whole thing. Lots and lots of soldering iron action! I used a heat gun on some of the larger surface mount parts, which was sort of a mistake since the heat caused the internal layers to blister under the components. The problem with this arose later, which you will see. If I were to do it again, I would carefully use a Dremel and cut-off wheel to slice the leads at the plastic package and then remove the remaining leg pieces with the soldering iron. The PCB images hereafter were made with a flatbed scanner.

    Next, the green solder mask layer was removed. I looked all over online for ways to do it chemically, but the chemicals required are a) not really accessible to hobbyists, and b) I don't need cancer. Instead, I got some 3M abrasive pads for metal polishing (they are a lot like the green scrubby pads you find everywhere, but more durable and finer) and attached them to a buffing attachment for my drill. This ended up wearing through a couple of small copper areas, but it was easy enough to reconstruct them in my image editor (GIMP). Again, layers were scanned.

    That stuff was the easy part. This PCB had 4 layers, so seeing the outer ones was not going to be enough. Again, I scoured the web for ways to separate the layers, but there really was no good way of doing that. The main methods seemed to be to CNC the outer layers off, or spend hours and hours working with sandpaper. Since I have access to a manual mill at work, I used some double-sided tape to hold the PCB down and carefully removed the outer layers with a 20mm diameter end mill making ~0.25mm (~0.01”) deep passes. This worked surprisingly well.

    As I had mentioned above, the layers blistered when I used a heat gun, and this caused some of the internal copper to be chopped off during milling.

    It was no big deal. This is because copper cannot cross copper on a layer, so matching up what-went-where was pretty simple via deductive reasoning. Also, I could see "through" the outer layer scans enough to confirm things. There were no vias (inter-layer connecting holes) in these areas, which is why they blistered as badly as they did, but it also meant that traces went exactly where they look like they did. I reconstructed the damaged areas in GIMP and had nice complete pictures of the inner layers.

    That was the easy part of it. I next needed to threshold the images to black/white so that I could use a free program (IMG2CAD) to convert them into DXF vector paths and import them into my schematic/layout program (DesignSpark PCB, free and very capable). There was a lot of manual touching-up to be done to get things to threshold properly, and I probably spent 6 hours tweaking the images in GIMP before vectorization. I also marked every single surface mount pad and plated through-hole so that those would be clear and obvious when I proceeded with future steps.
    (layer 1 for example)

    While I was marking pads and holes, I also noted dimensions of things. This was used to build a complete library of schematic symbols and components for the layout. Every single component was going to be accounted for in my reconstruction.

    Here is where the real "fun" began. My intent was to have a schematic for the PCB so that it would be very easy to see what was what when I started messing with the firmware (which IO pin controlled what). Unfortunately, the standard for PCB layout programs is to start with a schematic and then drive the PCB components and netlist (terminal connections) from that...not the other way around. DesignSpark does allow you to create nets (connections) in the PCB manually, but it has no way of pushing them "backwards" into the schematic.

    I almost gave up at this point. Building the schematic meant tracing all of the DXF geometry in the layout, exporting a text file which listed all of the PCB-only net names & connections, and then going into the schematic side and manually making matching connections & naming nets. Everything would have to be made exactly the same, manually. It was essentially like having to rebuild the circuit twice, one component and net at a time. Ultimately, I sucked it up and did it. It was not as bad as I thought it would be, and maybe 30 hours of work to do both workflows. Now I have a fully accurate PCB that is completely driven from the schematic, so when I do decide to make hardware mods to the mainboard, I can fully track and represent things.

    The PDF files in these links have the schematic and PCB artwork. The schematic is not well organized for viewing in a PDF since things are all separated out by subsystem with net labels indicting connections (a text search makes it easy to find endpoints though). This was to avoid having 200 crossed wires to wade through, since with the actual schematic in DesignSpark it is really easy to highlight nets and know what is connected where.

    It is pretty interesting to see what was and was not populated on the board. These ECUs were used in all sorts of vehicles, and you can tell that the design was modular. Also, many of the pins on the main 88-position harness receptacle are connected to things on the PCB, but not used in the M42 wiring harness. Alfa Romeo used these on various 4 and 6 cylinder models, and the E36 M42 used M1.7.2 which is (as far as I can tell) the same main PCB but with the A250 daughter-board installed which processes knock sensor signals. I am actually planning to run my car on M1.7.2 once I get the firmware fully decoded so that I can eliminate E36-specific stuff like DISA control while also gaining knock sensing, but regular M1.7 is first since it will be 95% of the work needed anyway and my engine runs on it now.

    There are a few partial schematics out on the web for other Motronic versions, and those were pretty helpful in figuring out what was what in my own ECU (meaning giving accurately descriptive names to nets). These included M1.3, M2.3.2 and M3.1. They all share enough in common with M1.7 to be super helpful. The M1.3 and M3.1 schematics are only partially complete and have a few errors in them, but I appreciate whoever it was that took the time to try to build them. The M2.3.2 one was posted on a different forum by a random member who was interested in RE'ing it, and it appears to be a 100% complete scan of an original (hand drawn!).
    None of these are mine, I did not make them and they were all found in various publicly-available parts of the internet where they were posted and/or created by others.

    With that monster task out of the way, it was time to start digging in to the firmware. I have a program which disassembles 8051 microcode, so getting it into a rough representation of the assembly code was fairly easy. Separating out data constants from code is still a work in progress, as is determining what all of the RAM locations are storing and how chips like S500, S550 and S702 work. My main focus has been on S702 lately since it is critical to tons of functions. It is a port expander of some sort which seems to be a custom part made for Bosch to work with the main microcontroller. It is common to all three of the above listed Motronic versions, as well as mine, and I am sure it was used in others.

    I have found how it is accessed in the firmware code and I understand a few of the instructions sent to it and how they control or read various pins. There is much more to it I think, like an internal timer/counter and other output functions which seem to be logical combinations of other input pins (such as pin 67 which seems to have its output programmed to be (A13 OR A14) OR (NOT A15)). I am not sure that I can figure this all out from the code, and since not all pins are even used in M1.7, I am going to need a lot more info on this thing if I want to use it to add functions.

    So, it was time to break in to S702 to start getting some idea of how it worked. "What?" Yes, literally breaking in to the chip to image the silicon die. I work in the electronics industry and my employer has some pretty high-end measurement equipment which they do not mind me using after-hours, so it's not really as silly as it sounds to literally look at the internal silicon. I had the S702 chip from the board I deconstructed above, so I just needed to get the epoxy encapsulation off. I wanted to do it chemically, but that involves sulfuric acid heated to 250 thanks. I found a method that just about anyone can use at home, and as crude as it is, it works.

    I started with the chip and ground off the metal leads to get clean square sides.

    Then I stuck the chip in a cheapo bench vise, aligned the centerline with the top of the jaws and compressed it. I repeated this a few times, rotating the part, and it quickly popped apart.

    Voila, the actual functional bits of it. The actual "chip" is the little silicon die with all of the micro-features etched & plated onto it.

    As I had said, I have access to various imaging equipment at work. Since the features on this are relatively large, an optical microscope was all that was needed to get a reasonable amount of detail from the die. The microscope I used does automatic 3D stitching, meaning I specify a 3D bounding box and it scans through all of the Z-heights, composites everything into perfect focus, pans to the next X/Y locations, repeats the Z steps and then stitches it all together into a big panorama with everything in focus. It is one of the lower magnification instruments in the lab since it only goes up to 2500X, but its automation functions make it one of my favorite instruments.

    This chip was made with something around a 2 micron process (2000 nanometer, versus modern chips which are made with 10-30 nanometer processes). The link has a larger version, which is still a lot smaller than what I got out of the microscope, but more than enough for internet enjoyment. The distortion around the wire bonds is due to the fact that there is a clear adhesive encapsulation about 0.25mm thick covering the whole die. It was easy enough to see through, so I left it on.

    300X mag die overview shot:
    Full-size image (~8MB):

    The smallest features/spacings were on the order of 1.5 microns. These images were taken at 500X to 2500X magnification.

    I am not about to go and try to trace out all of the individual transistors and logic gates since that is a lot of work, and it is probably faster to figure out what I need to know by messing with the firmware. But this was worth the effort since I was able to clearly identify three distinct pin types. Knowing which ones were inputs, outputs and bi-directional has been very helpful in understanding the command structure used to interface with it.
    Inputs have a single metal trace coming from the wire pad, outputs have two and bi-directional ones have three.

    For the time being, that is the high level recap of where I am at with this. I plan to break open the various other chips and image their dies too, just for fun. As crazy as the above stuff may or may not seem, it was actually all of 30 minutes worth of work thanks to the fancy microscope. If and when I come across other interesting stuff during my RE efforts, I will post the details. At one point I started a similar project on a cheap eBay M1.3 (from M20 cars), but it isn't really something I am all that interested in since I do not own an M20-powered car. The M1.3 PCB is only 2 layers and is somewhat less complex, although the core architecture is mostly the same as M1.7. When I am done with M1.7, I will be something like 90% of the way to doing the same thing to M1.3 since the hardware and firmware is actually very similar. But, don't hold your breath for that one!

    Cheers everyone, I hope this is interesting for you!


    Unplanned philosophical mumbo-jumbo because I worked through a coupe of glasses of scotch while typing this up...
    While there have been immense advances in semiconductor fabrication technology, chip design and our understanding of device physics since this chip was made, things have not actually changed at all in some respects. We can pack ~10000 more transistors into the same area now versus back then, but ultimately everything that goes on in all of our various devices which use silicon chips is just a bunch of transistors that form basic logical elements which take in and put out 1's and 0's (as high/low voltages). That's it, really. We just can't "see" it working in any literal way without working in the industry, so it seems like magic. That isn't to downplay the wild science and technology required to make this stuff work. The true bleeding-edge of applied human knowledge is found in the semiconductor world. It took all of human scientific knowledge from the beginning of our existence to make the first mass produced integrated circuit (lots of transistors on one silicon die) less than a century ago. With that, we were able to make better computers which were faster and smaller, with which we could design faster and smaller transistors, which made more powerful computers, which made more advanced transistors, etc. Hell, maybe transistors are the most advanced things on the planet, and we are their slaves. They are self-replicating and self-evolving, with us as their tools to do it. Hell, I exist because of the transistor! My parents both worked in the industry and that is where they met. Maybe that is a bit of a stretch...enough philosophy for now, I think.
    Last edited by bmwman91; 01-09-2018, 12:46 AM.

    Wow very cool read....wish i had something to add but this is way above my head. Interested to see future updates. Do you think the motronic 1.72 could be adapted to run the m20?


      Very interesting stuff to see, looking forward to when you've got a little further into the practical consequences of your observations!


        Great thread, thanks for sharing, I love the photos. Imagine how basically everyone carries one of these around in their pockets every day and that no one probably imagined that back in 1986 when these were designed.
        318iS Track Rat :nice:
        '86 325iX 3.1 Stroker Turbo '86 S38B36 325

        No one makes this car anymore. The government won't allow them, normal people won't buy them. So it's up to us: the freaks, the weirdos, the informed. To buy them, to appreciate them, and most importantly, to drive them.


          Really amazing stuff! I've been working with the Motronic M3.3 system for a couple of years reverse engineering the software code for tuning purposes. This goes beyond anything I can comprehend.


            Wow never thought I'd see someone do this. Are you an EE?

            IG @turbovarg
            '91 318is, M20B25 turbo
            [CoTM: 4-18]
            '94 525iT slicktop


              Wow! Very interesting, and beyond me :) Thanks for sharing. True labor of love :bow::bow:


                Originally posted by kyleconstantine View Post
                Wow very cool read....wish i had something to add but this is way above my head. Interested to see future updates. Do you think the motronic 1.72 could be adapted to run the m20?
                In theory, yes. M1.7 was used in Alfa Romeo 6 cylinder engines with wasted spark ignition, and the drivers for the fuel injectors are able to drive at least 3 per output. There are only two injector driver channels, which is why the M42 fires them in pairs. M1.7 has four ignition coil drivers, so you could either stick with the single coil, or convert to wasted spark. I think that later M20 engines had the 60-2 crank position wheel on the crank, which would be needed to use M1.7, and you would need to add a cam position sensor to really get full functionality. It is possible that knock sensing would not really be an option though since the way that the electronics on knock processors work is that they are essentially tuned for the piston diameter (since the frequency spectrum of knock events is strongly related to that). You would have a much easier time running Megasquirt, and it would allow fully sequential injection and COP ignition.

                Originally posted by Mykk540i/6 View Post
                Really amazing stuff! I've been working with the Motronic M3.3 system for a couple of years reverse engineering the software code for tuning purposes. This goes beyond anything I can comprehend.
                Got any info on M3.3? Chances are you know a lot more about the software on old Motronics than I do.

                Originally posted by varg View Post
                Wow never thought I'd see someone do this. Are you an EE?
                Not officially an EE, no. But I am an engineer in the electronic hardware industry and I have done a lot of EE-esque work over the years.


                  bmwman91 this is awesome info! I have long dreamed for schematics of M1.7.X, because software disassemble without any technical info (or a little with pin calling) is very hard work, mostly wrong, possible for a years.

                  I have some software information given by reverse and research several of Motronics versions for few cars and some my expirience about development process. All my info may be right, or something wrong, or totally crap for current time of writing :) Software of such complex thing of Motronic does not right understandable without full description (of course this information can be given only from insiders, many-many years ago, for now its seems hard - all documentation was kept on paper and I'm sure all Motronic 1.X engineers are already retired or died now), all bits of information was given from diagnostic software or XDF and shared info by another enthusiasts of old Motronics and one "digital" DAMOS from M4.4 system, which based on C51.

                  At first of all (before any research or software modifications) need some software and hardware instruments.

                  EPROM programmer (I'm use MiniPro TL866CS USB)
                  Several W27C512 chips

                  IDA Pro v6.1 (this version best detect code/data for C51) -!mNtGjTaQ!6m7hpX_2Q...yb33ldRiA0NOQY
                  HxD Hex Editor -
                  as515 (modified as31 assembler, for C515) -!fRc2kSxK!hReKkIqON...qCgG9KeQe_hkBs
                  convert (tool for calculate checksum and convert compiled binary to flash binary) -!HctCHZpB!FuNKHd0We...JPh4ymqpd7LH9Q
                  ASM editor (I'm use Notepad++) -
                  Set of ROM files for Motronic M1.2, M1.3, M1.7 -!PJF0BIAY!j7aZx5hVm...QW3f2KZU7Waf-U

                  Next need to compose full binary if Motronic use 32K bytes flash. Bosch wants to save money (because 64K UV-EPROM is two 32K crystals on one case) and use 8K ROM memory for common functions and 32K flash memory for rest code and data. Only M1.7.3 from BMW 1.X Motronic use 64K flash memory, without ROM, because 40K flash is not enought (but use same first 8K segment with common functions).

                  So, for getting full binary ready to disassemble, you need get ROM suitable to Motronic version and place it content from 0x0000 to 0x1FFF, original content from that range must be placed from 0x8000 to 0x9FFF.

                  After that, open result file in IDA Pro, and select "Processor type".

                  Next screen leave without any changes.

                  On next screen select C515 processor.

                  Than press "space" button for switch from code overview to code listing, and click on "Unhide all" item menu.

                  After all preparations, we can produce ASM file.

                  This file is need some modifications for better editing and comatability with as515 assembler. At first need to remove SFR defines.

                  Then add STACK define, after last RAM define:

                  ".equ STACK,0xD5"

                  Stack address (0xD5) is determined from search "mov SP," string, for example search result is "mov SP, #RESERVED00D5"

                  and finally replace all occurrences of "RESERVED00D5" with "STACK"

                  After that need to rename interrupt labels (set by default interrupt labels conflicted with SFR labels) for prevent assembler errors.

                  "RESET:" => "RESET_HANDLER:"
                  "IE0:" => "IE0_HANDLER:"
                  "TF0:" => "TF0_HANDLER:"
                  "IE1:" => "IE1_HANDLER:"
                  "TF1:" => "TF1_HANDLER:"
                  "RI_TI:" => "RI_TI_HANDLER:"
                  "TF2_EXF2:" => "TF2_EXF2_HANDLER:"
                  "IADC:" => "IADC_HANDLER:"
                  "IEX2:" => "IEX2_HANDLER:"
                  "IEX3:" => "IEX3_HANDLER:"
                  "IEX4:" => "IEX4_HANDLER:"
                  "IEX5:" => "IEX5_HANDLER:"
                  "IEX6:" => "IEX6_HANDLER:"

                  And of course need to change "ljmp RESET" to "ljmp RESET_HANDLER" throughout listing.

                  Now you can compile binary, but for Motronic with used ROM inside CPU if you want to change some logic, you can possible to break internal code structure.
                  So we need follow few rules:
                  1) Do not edit everything in area from address 0x0000 to 0x1FFF, because this area is placed on ROM and any changes will be ignored.
                  2) Do not edit interrupts and common fuctions wrapper area, placed from 0x2000 to first occurence of text "djnz RAM_4A", because code from ROM is call on hard links placed in this area, but if you know what you do, you are welcome.
                  For firmwares fully placed on EPROM this rules is not strictly, but necessary.

                  3) it is necessary to fix place of the calibration area because links to this area are found all over the code, and of course need remove empty areas without code shift.
                  So need place the ORG directives in the right places.

                  How find calibration area? Typically, the calibration area is outside the code, in early BMW Motronics it was be. Since Motronic M1.1 firmware strusture looks like this:

                  Segments is not hardly restricted by hardware (except using ROM for first 0x2000 bytes), but in some cases must be placed as is, due to math offsets.
                  So is best practice place ORG directives before each segment start:

                  And put ORG directive to end of code, for prevent exceed 40K size of compiled firmware, also need remove waste 0xFF bytes inserted by IDA for mathing code to 64K size of compiled firmware.

                  Also need fix place of firmware last 288 bytes, who store firmware info for daignostics.

                  I recommend place ORG directives for whole code, for prevent use of waste 0xFF byte-offset, but is not necessary.

                  Of course you can cleanup code from IDA comments with regexp ";(.)*?[\r\n]"

                  After all preparations ASM file can be compiled to bin with as515 tool.
                  Example of execution:

                  as515.exe -Fbin firmware.asm

                  Then for fix checksums and prepare compiled firmware to flash you can use convert.exe. This tool detect using ROM by file size (40K is used, 64K is not) and produce result file (32K or 64K) with correct checksum.
                  Example of execution:

                  convert.exe firmware.bin

                  Also you can produce double 32K file for write to 27C512 EPROM, not 27C256, with param "-D".
                  Example of execution:

                  convert.exe firmware.bin -D

                  In next posts I will talk about the internal strusture of the code, defined variables and some algorithms and methodics used in code.


                    bmwman91 I guess you have mistake in your schematics.

                    AN0 - AFM
                    AN1 - VBATT
                    AN2 - IAT
                    AN3 - CTS
                    AN4 - TPS
                    AN5 - COPOT
                    AN6 - LAM
                    AN7 - KS

                    AN5 is used for retrieve CO potentiometer voltage, AN6 for retrieve oxygen sensor voltage, AN7 used for retrieve selected knock sensor voltage.

                    Select current knock sensor is doing by set logical 1 to P4.0 and 0 to P4.1 and vice versa.


                      Very good info, thanks! I have been doing some work in IDA as well and am starting to get a rough understanding of the code. There are a number of areas in the code where jump offset values are hard-coded into the firmware, so I can see that great care needs to be taken when changing things. There are also some areas with no XREFs, so those are either data constant blocks or the disassembly did not complete properly. If you have some info on the address ranges which are data constants, that would be helpful (so far it looks like 4000h - 5BFFh is one big block, but I suspect others are there too).

                      As for the schematic, this is M1.7 (not 1.7.2 or 1.7.3) so maybe there are other differences that I do not know of. The A250 daughterboard is not actually present in M1.7, but I am guessing that it is the knock processor subsystem based on what is connected to the empty solder connection holes. I double-checked the PCB images, and the connections that I made in the schematic seem to be correct (AN6 and AN7 are linked to two pins on A250 through two not-present resistors). Also I compared the 8K ROM files that you have linked to the 8K ROM that I got out of my ECU. The internal ROM from my ECU matches exactly to the M1.3 ROM, and it matches partially to the M1.7 ROM that you posted. Which version is yours from?

                      Thanks again for the info. Looking forward to more!

                      Also, I found a way to use an Arduino to directly communicate with the MCU, without needing to deal with the K-Line and L-Line. It involves some soldering to connect direct to the 8051 Rx and Tx pins, plus the L-Line endpoint on S550 to send the 5-baud address to initiate communication. I will try to put together some details on that here.


                        Originally posted by bmwman91
                        There are also some areas with no XREFs, so those are either data constant blocks or the disassembly did not complete properly.
                        Not every firmware uses all code, but he is present. Bosch just wrote everything who need at current time of development and place it to firmware.

                        Originally posted by bmwman91
                        If you have some info on the address ranges which are data constants, that would be helpful (so far it looks like 4000h - 5BFFh is one big block, but I suspect others are there too).
                        Main thing that ALL tables in Motronic 1.1-1.7 is between "1 SEGM." and "2 SEGM." (you can see accurate block address with IDA), and of course there is several occurs in the end of binary (last 288 bytes) and inside code, you can find it by search "mov DPTR, " through listing and skip all addresses which point to 4000h - 5BFFh (or another area of MAP segment, if you see another firmware), external RAM and extend chip S702 (A0XXh addresses).

                        Originally posted by bmwman91
                        I double-checked the PCB images, and the connections that I made in the schematic seem to be correct (AN6 and AN7 are linked to two pins on A250 through two not-present resistors).
                        I rechecked asm listing, and found that you correct! Thats what do I call walking around for years, without right schematic. But AN6 is NOT KS1 or KS2, its something else but 100% not knock sensor, because its not readed in crank-syncronised interrupt. In this regard, a huge request will figure out the scheme M1.7.3.
                        M1.7.2 not worth paying attention, if you want I can give a detailed answer, why should switch to M1.7.3 and not to M1.7.2.
                        I'm already swaped M1.7.2 to M1.7.3 on my car.

                        Originally posted by bmwman91
                        The internal ROM from my ECU matches exactly to the M1.3 ROM, and it matches partially to the M1.7 ROM that you posted. Which version is yours from?
                        Its from M1.7.2 and M1.7.3. I have guess that ROM is not hardly strict to Motronic version, but for DME part number, so most likely it depends on the year of release. I called ROM some time ago because of ignorance this fact. If you try to disassemble M1.7 with 1.7 ROM you will notice that all OK and if you want to recalculate checksum with 1.7 ROM, you notice that all OK too.

                        Originally posted by bmwman91
                        Also, I found a way to use an Arduino to directly communicate with the MCU, without needing to deal with the K-Line and L-Line. It involves some soldering to connect direct to the 8051 Rx and Tx pins, plus the L-Line endpoint on S550 to send the 5-baud address to initiate communication. I will try to put together some details on that here.
                        No need Arduino for communication with old Motronic, just need $5 cable with BMW 20 pin adapter, and soft used all around the world :) I wrote about this later.


                          Thank you for confirming the ranges of data constants. So 4000h-5BFFh are data, maybe it is all used, maybe not, and the last 288 bytes. Is that all of the constant data that you know of?

                          Understood about the sections with no XREF's. 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).

                          I can update the schematic to give "unknown" names to the AN6/7 nets since I am only guessing there. Can you take some photos of the top and bottom of the main board so that I can see the layout? The part number etched into the main board is 1268322158-7. 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.

                          Let me know your thoughts on why M1.7.3 is superior to M1.7.2. I am happy to learn and consider that for a conversion. There are many on eBay for OK prices, all in Europe since no US-version BMWs had the M43. There seem to be two versions of 0261203277, a silver label one and a gray label one. Do you know the difference between them? One eBay listing says that the gray label one has the EWS/immobilizer, which I would probably want to avoid, but if the firmware is being accessed then it can probably be removed.

                          EDIT: I got info from the eBay seller and the gray-label one has no immobilizer. So I purchased one from Italy for $50 with free shipping and should have it next week.

                          As for the ROM, the interrupt vector table seems to be exactly the same, so interrupt calls will jump to the correct location in EPROM, but much of the other stuff is different. Some of it looks like code, some looks like data constants, and of course there is a lot of FF!

                          Looking forward to your info on the $5 cable to communicate with. I could not find a KW71 interface box that looked like it would work for less than $120, so I just used the Arduino directly on the DME.
                          Last edited by bmwman91; 01-22-2018, 11:20 AM.


                            A long time ago I found a simple EXE on some random website to calculate checksums for a few different DME's. I disassembled the EXE and got the exact algorithm used for the checksum in M1.x. It is pretty simple. Again, addresses are referring to those on the 32K EPROM, not the proper 40K image.

                            CSUM = MOD([SUM(0000h:1EFFh) + SUM(2000h:7FFFh) + 46367], 65536)

                            This 16 bit value is then stored at address 1F00h:1F01h (MSB:LSB).

                            The EXE I found (not mine, I take no credit for making it) is here. It seems to support a number of variants (run through command line):


                              Nice thread - this is something that I'm really into now (disassembly). Always wanted to play with the earlier stuff since it's so much simpler, but it's hard because everything is so old and the info is lost - the info Rasp has provided is invaluable!

                              I'm pretty comfortable with IDA these days so if you have any questions, maybe I can help - mostly I've been working on MPC5xx and TriCore CPUs though, which is much newer - MPC is actually somewhat easy to disassemble because instructions are fixed length, so if you don't know what something is you can just assume it's 32 bits and move on. :)
                              Build thread