Announcement

Collapse
No announcement yet.

Modifying Motronic 2.3.2 ECU hardware and software.

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • I have no idea how to highlight one of those yellow lines, because I can not see markings on those ECU pictures. And without markings I do not know where is what on the board.
    You must understand, the factory schematic is a logical electronic schematic. Not a board layout file.

    All the inputs to the fuel-ign processor are exactly the same.

    They come in, have a cap connected to them, then a pullup or pulldown resistor, and then an in-line resistor. After the in-line resistor they all go to S900, which is basically like dual schottkey diode IC. It limits the voltage to 0-5V so you do not fry the processor if you connect some larger voltage source or something is shorted to 12v.
    After that they run into the corresponding ADC pin on the CPU.

    The only thing connected in series is the inline resistor, everything else is connected in parallel. So all you have to do to retrace the signals is trace the CPU ADC pins to S900 and then from the S900 to the resistors, and from the resistor other end to the pins.

    But as I said, this is a really difficult way to do this! The much easier way is to just take the OBD logic in the CPU, look which ram location is what input, and then xref that ram location and see where it is written. Then you not only find which ADC pin the signal is taken from, but you also find the linearization maps for IAT, ECT and so on.

    Regardless, all this is not needed for correct mapping. It does not matter in the slightest how the CPU internally gets ECT or IAT or battery voltage. What matters is where in RAM they are stored and how they are used inside the CPU. Even if you had the full schematic of the ECU, it would not be that helpful for disassembling the ECU.
    I got the schematic very late into my learning of this ECU, and by that time I had disassembled and mapped most pins by hand that I needed.
    Let's say like this - it is better to start in the software, and then if you NEED some signal for mapping or NEED to understand where something is coming from, only THEN start tracing the PCB. This way you will actually get things done.
    http://tuner.ee - http://www.facebook.com/tuner.ee

    Comment


    • Originally posted by -ice- View Post
      Hi,

      is it possible to highlight one of this yellow lines? This would be nice to trace a single connection.
      I don't think it's a waste of time. Sure, factory documents are better, but it could be helpful.


      Bye
      They will be once im finished. the picture above is just a screen capture from adobe illustrator. you will be able to select individual tracks, select a piece of hardware for information on it and remove individual levels and tracks so you can easily find what your looking for.

      sure the using the measuring blocks would work on the fuel/timing chip but there is nothing in the blocks involving the the boost board side. finding any info the fuel/timing side is out there, the mystery is in the boost board as its software isnt layed out like a conventional motronic file with the scalars and axis before each map. i dont have the programming knowledge to work with the OBD protocol like you so im taking another route that will allow me to see all the I/O ports connected to the CPU from a visual prospective and work with IDApro from there and be able to tell what everything does.

      since those documents involve a non disclosure agreement with bosch why do you have them since im going to assume you dont work for bosch or are in no way affiliated with bosch. so even you having them is technically against their agreement with whoever they released them to. besides all the bosch documentation floating around on the internet is part of a non disclosure agreement and their still out there for the public to view and no one has lost their life over it. bosch only protects the documentation because of all of the government mandated features they have to add for things like emissions regulations and such. these governments dont want the common folk being able to disable these features and cheat their emissions regulations and stuff. in the states its one of many ways for the man to pinch my wallet and tax me for something as pointless as what comes out of the exhaust on my car. its not my fault gas isnt a clean burning fuel but i have to pay the piper ever year for it.
      "The really good drivers got the bugs on the side windows." Walter Röhrl

      Comment


      • Basically all i want to do is what the volvo community has done with motronic 4.4. a complete tunerpro definition for both boards along with plugins for the checksums and a way to data log the ECU over the OBD port. most people who would use these have never paid for chip tuning and refuse to pay for chip tuning like myself. i would sooner figure out a way to run another fuel system i can tune myself rather an pay someone to tune my car for me. me retrofitting digifant 1 to 10V NA and turbo engines and fitting motronic 4.4 to my other URS6 avant is an example. there are plenty of people who would rather just pay someone to tune their ECU with no questions asked and im not one of them people. im not made of money and i dont have 2000.00+ dollars to buy standalone so i find alternative ways to achieve what i want.
        "The really good drivers got the bugs on the side windows." Walter Röhrl

        Comment


        • Originally posted by vwnut8392 View Post
          since those documents involve a non disclosure agreement with bosch why do you have them since im going to assume you dont work for bosch or are in no way affiliated with bosch. so even you having them is technically against their agreement with whoever they released them to.
          1. It is none of your business.
          2. Assumption is the mother of all ****ups.

          As for this whole noble quest of yours. You do not value your time, I do. That is the difference. I also do not believe for a second that you are going to get anywhere at all with this, since you are attacking this from the wrong angle.

          You do not need the hardware schematics to find out what is going on in IDA in the boost chip - there is extremely little code there. I found out most of the things I needed before I got the schematics, as I said. They do not help reverse engineering, they merely confirm that you are on the right track. The thing that helps reverse engineering most is the 80515/535 developers manual.
          http://tuner.ee - http://www.facebook.com/tuner.ee

          Comment


          • Hi,

            Which tools do you use to compile the (changed) code to hex?

            Regards

            Comment


            • Originally posted by -ice- View Post
              Hi,

              Which tools do you use to compile the (changed) code to hex?

              Regards
              ASEM-51 and HEX2BIN.
              http://tuner.ee - http://www.facebook.com/tuner.ee

              Comment


              • Originally posted by prj View Post
                ASEM-51 and HEX2BIN.
                I tried this and it worked

                I also use adis-51 v4.0. It's a graphical dissasembler with online assembler. So if you want to change single operations you can load the bin, change the operation, and compile it back to bin with one tool. For example if you want to ad a jump to your injected code its very practical.
                I'm running it on a 32bit windows xp in the command shell (dont know if it runs under newer os...)

                For compiling much code, i think asem 51 is better.

                Regards

                Comment


                • For simple mods I just look up the correct spot in IDA, write the code using a random hex editor and reload the binary to make sure I did not make a mistake.

                  There are only so many instructions on a 8051, it's not difficult to memorise the hex codes for the easier stuff. Of course writing longer code I use ASEM.
                  http://tuner.ee - http://www.facebook.com/tuner.ee

                  Comment


                  • Hallo,

                    I'm trying to find the checksum calculation code..

                    So if the checksum is located @ 0xff00, i tried the following:

                    - see if it is accessed directly via dptr or a dptr near to this position -> no success
                    - see if DPH/DPL were set seperatly -> no success
                    - many things in the motronic are mapped, so i searched in the binary if the checksum adress is also mapped. All results weren't loaded via dptr.
                    - finding it by coincidence. I suggest the procedure will contain inc dptr instructions to sum up all eeprom values and calculate the checksum. But there are too many places which could have something to do with it and i haven't seen it yet.

                    Another idea would be to dissasemble the fault codes generation, but this will take a long time. Same thing with the rev limit, knowing where it is, doesent mean you know where it's used in the code

                    Does anybody know other efficient ways to find it?

                    Regards

                    Comment


                    • Special question to prj:

                      I would like to use the xram array to transmit my chars. So i filled it starting at location r0 = #af with length an data. But it won't transmit anything when i start it with enabling the interrupt ien0.4. it only transmitts the data which is put directly in sbuf (which i receive correct with 9600baud).
                      Do you have a hint for me? i replaced the whole obd routine with the code. Perhaps i missed to initialize something.

                      Thanks in advance.


                      Bye
                      Last edited by -ice-; 11 April 2014, 19:05.

                      Comment


                      • Revlimiter is very easy on these, don't be lazy
                        Compare RS2 551B/C and AAN 551AA and you will see about revlimit (it's different in them).

                        As for your OBD routine, post your code.
                        http://tuner.ee - http://www.facebook.com/tuner.ee

                        Comment


                        • Hi,

                          i can't find it at the moment, but it was based on your 'fillbuffer' routine you have posted some time ago. I replaced the whole OBD procedure with the code. Maybe some part of it is still needed, and i should have set the entry point in this procedure?!

                          I didn't look closer at this and started to make my own serial communcation. Something like this (Just an example to send two fixed bytes one after another):

                          Code:
                          $NOMOD51
                          $INCLUDE(80C515.MCU)
                          
                          
                          MOV DPTR, #0A10eh
                          RAM_PTR equ 63h
                          
                          JBC TI, txcomplete
                          
                          MOV PCON, #080h
                          MOV SCON, #0E8h
                          
                          
                          MOV A, RAM_PTR
                          MOV B, #003h
                          MUL AB
                          JMP @A+DPTR
                          LJMP byte1
                          LJMP byte2
                          LJMP getout
                          
                          byte1:
                          MOV SBUF, #0aah
                          LJMP getout
                          
                          byte2:
                          MOV SBUF, #0ffh
                          LJMP getout
                          
                          getout:
                          INC RAM_PTR
                          
                          
                          MOV A, #01h
                          MOV R0,RAM_PTR
                          CLR C
                          SUBB A, R0
                          JC carry 
                          RET
                          
                          
                          carry:
                          MOV RAM_PTR, #00h
                          CLR C
                          RET
                          
                          
                          txcomplete:
                          CLR TI
                          RET
                          
                          END
                          It uses the well known JMP@DPTR mechanism, which is also used in the original obd-routine. I think this will meet my requirements for a simple logging-protocol...

                          I discovered the revlimit word by hex comparison and using the emulator. I don't have an approach to find the code yet. Since it it has something to do with time between two flywheel pulses i guess its accesed in a Interrupt-service-routine.

                          I accidentaly discovered a factory logging protocol for tracking ram-variables over UART. Is it this McMess thing?

                          Regards

                          Comment


                          • I'm not sure but I think you understand the JMP @A+DPTR wrong.
                            Other Motronic Sources don't have this line

                            Comment


                            • In the Code above?

                              That's self written code...sure it's not in any motronic

                              bye

                              Comment


                              • Does anybody have a datasheet for the NEC B57727 Chip? I think it's the external RAM but I'm not sure...

                                Bye

                                Comment

                                Working...
                                X