Announcement

Collapse
No announcement yet.

Documentary - Motronic 1.7 DIY Reverse Engineering

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #16
    Quick answer about M1.7.2 and M1.7.3 DME part number.

    0261203276, 0261203277 - is M1.7.2 for 1.6 and 1.8 engines.
    0261203660, 0261203661 - is M1.7.3 for 1.6 and 1.8 engines.

    Immo can be disabled in 1 bit for M1.7.2 and custom software for M1.7.3, there is not problem, you can buy any.

    Schematic M1.7.2 and M1.7.3 are complitely different, for example M1.7.3 has no dauther board.

    Comment


      #17
      Originally posted by nando View Post
      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. :)
      Seriously. As much as the 8051 is regarded as being a venerable platform which was instrumental in the proliferation of microcomputing, screw it. I got my start in embedded systems with 8- & 16-bit PIC/dsPIC controllers using assembly language (I sort of prefer it to C in many cases), and I guess I was spoiled by the ease of using a more modern architecture. The extra-wide program pathways allowing single instruction jumps to any address were nice...the 8051's "true" 8-bit architecture has all sorts of jumps and branches with are constrained to a 2K block, so you end up with branhces-to-jumps and that sort of thing. Gross. Even the PIC/dsPIC aren't as nice as the MPC5xx/TC though since a few instructions are larger than others.

      If you want to take a look at the stuff, the full 40K BIN (with everything in address-correct order) is here:
      http://www.e30tuner.com/assist/m17re/M1p7_FullROM.zip

      Originally posted by Rasp View Post
      Quick answer about M1.7.2 and M1.7.3 DME part number.

      0261203276, 0261203277 - is M1.7.2 for 1.6 and 1.8 engines.
      0261203660, 0261203661 - is M1.7.3 for 1.6 and 1.8 engines.

      Immo can be disabled in 1 bit for M1.7.2 and custom software for M1.7.3, there is not problem, you can buy any.

      Schematic M1.7.2 and M1.7.3 are complitely different, for example M1.7.3 has no dauther board.
      Hmm interesting. I can not find much information on the web regarding M1.7.3, and I got the wrong PN so I bought 0261203277. That might be OK though since I do want to understand the hardware differences across the different M1.7 units.

      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? Also looking forward to why M1.7.3 is better than M1.7.2! If M1.7.3 is like the M5.2 (M44 DME) that I took apart, I am not sure if I can make a schematic since Bosch seems to have stopped putting part reference markings on the board, probably to make it more difficult for hackers. I would have to invent my own references (R001, R002, etc).





      I can't pull up IDA right now, but I have noticed some issues that I am not sure of. The SAB80515 differs from "classic" 8051 controllers in that it has 256B of internal RAM, with the lower 128B (00h-7Fh) being directly addressable, and the upper 128B (80h-FFh) sharing addresses with the SFR's. The SFR's are accessed directly, and the scratchpad RAM is accessible only by indirect addressing. 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?

      Comment


        #18
        I am a monster lol. So much for not collecting more junk in my house. I just ordered 2 more DME's on eBay. 0261203282 and 0261200990 which were a couple of variants of the E36 M1.7.2. Just so I can get pictures of the guts and document how this thing changed over time. It will be interesting to see how 0261203277 compares.

        There do not appear to be any 0261203357 units on there, though. Once I dig into the 1.7.2 units a little, I can see about obtaining a M1.7.3 unit. I assume that the difference between the 276/660 and 277/661 DME's is that one is for the 1.6L and one is for the 1.8L?
        Last edited by bmwman91; 01-23-2018, 08:13 AM.

        Comment


          #19
          Originally posted by bmwman91 View Post
          I assume that the difference between the 276/660 and 277/661 DME's is that one is for the 1.6L and one is for the 1.8L?
          Yes.
          Last edited by Rasp; 01-25-2018, 09:14 PM.

          Comment


            #20
            Lets continue old Motronic digging :)

            Thanks to bmwman91 we have full schematic for M1.7 and can deal with software without "black box" engineering.

            So, we know that CPU is SAB80C515 (datasheet - https://mega.nz/#!iFEViaTR!JPTSSeoff...uffwC7KPd61RZE).
            It has several interrupts which can be executed by software and/or hardware.
            Crankshaft position sensor is connected to P1.0, so IEX3 interrupt hardware execution starts with every tooth on crankshaft wheel. So all crankshaft position-math is doing in this interrupt.

            Also this interrupt caused another, software interrupts - per-segment event (IE0) and knock sensor value measurement (IEX4).

            Another hardware interrupt (IE1) is caused by Vehicle speed sensor.

            Also Motronic has background main cycle loop, here caused sensors lineralization (except VAF, Crankshaft sensor, Camshaft sensor and Vehicle speed sensor), store calculated values to RAM for further use in interrupts (directly in interrupts use only raw values from data area, not from 2D or 3D tables with interpolation due to speed of calculation and there is no need to calculate most values often).

            Comment


              #21
              If you want play with Motronic datalogging RAM variables by K2 protocol with standart baudrate 9600, you can use KWP71Diag tool https://mega.nz/#!jU8A1ZYA!ajEXKoQy_...hmoGrmZh3r0T54
              with predefined config to M1.7-M1.7.3



              This program will work with simple VAG COM KKL 409.1 adapter, but only with FTDI chip!

              Virtual COM port must be configured:

              Comment


                #22
                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!

                Comment


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



                  Originally posted by bmwman91 View Post
                  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.

                  Comment


                    #24
                    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?

                    Comment


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

                      Originally posted by bmwman91
                      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.

                      Originally posted by bmwman91
                      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.

                      Originally posted by bmwman91 View Post
                      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.

                      Originally posted by bmwman91 View Post
                      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.

                      Originally posted by bmwman91 View Post
                      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.
                      Last edited by Rasp; 01-24-2018, 06:30 AM.

                      Comment


                        #26
                        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!

                        Comment


                          #27
                          Originally posted by bmwman91
                          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.

                          Originally posted by bmwman91
                          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.

                          Originally posted by bmwman91
                          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.

                          Originally posted by bmwman91
                          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.).

                          Originally posted by bmwman91
                          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.

                          Comment


                            #28
                            Very interesting!

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

                            Comment


                              #29
                              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.
                              Build thread

                              Bimmerlabs

                              Comment


                                #30
                                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.

                                Comment

                                Working...
                                X