Announcement

Collapse
No announcement yet.

DIY: BDM ST Manufactured M29F400BB MSS54HP Flash using a USBJTAG u-Link NT

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

    #16
    Originally posted by karter16 View Post
    Another option would be to open the binary in a hex editor and split it that way. The file must be split exactly in half 0x0 thru 0x7FFFF is the master and 0x80000 thru 0xFFFFF is the slave.

    You'll then flash the master binary to the master EEPROM (as per the diagram in the guide you're following) and likewise for the slave.

    Hope that makes sense?
    This seems to have worked. Used a hex editor to split the file at the address you mentioned. Thanks!

    Comment


      #17
      Awesome! glad you got it sorted!
      2005 ///M3 SMG Coupe Silbergrau Metallic/CSL bucket seats/CSL airbox/CSL console/6 point RACP brace/Apex ARC-8s
      Build Thread | Community Patch | MSS54 DS2 Tool

      Comment


        #18
        For what it's worth, I found the MSS54HP config file to work fine* with the MSS52/4 non-HP, just have to change the length in the config from 0x80000 to 0x40000. Edit: For good measure probably should change the 0xFFFA48 and 0xFFFA4C inits to 0005 -- but read/erase/write seemed to work properly even without doing that.

        *caveat being my MSS52 doesn't appear to be working quite right (slave CPU seems to drop out after a short period of time), but I think that's a fault with the DME rather than an issue with the BDM config

        Comment


          #19
          First of all, awesome script/DIY, it seems to be working perfectly.

          However, I don't know why error 155 and 156 (internal : EEPROM-adaptation) keep popping after flashing 0401PD31 CSL software. I tried erasing error memory and adaptations without success, it pops back everytime I restart the DME. I have done other CSL conversion with the same software but with AMD EEPROM and I haven't had any issues. I compared the files for this DME with other CSL conversion I have done and I haven't seen anything weird. I guess I must be doing something wrong or something is wrong with this particular DME (faulty EEPROM ?). Does anyone have an idea ? Only thing I haven't tried is putting the DME in the car and just give it a try. Last resort I'll just replace the ST EEPROM for AMD ones.

          Also, I had a weird ZIF mismatch error with MSS54 DS2 tool which I never had with AMD chips running with the same file. I figured out that every 211325000401PD31 "unmodified" files available online contain different version string at location 0x7E00 (in full binary) ASCII string state "211325000301" followed by program version "7834981" 2 times. All other locations (0xBFB8 and 0x41B90 in full binary) are stating "211325000401" and "7837340". I solved the ZIF mismatch problem by writing "211325000401" and "7837340" at 0x7E00. I find it very weird that the error doesn't seem to appear with other DME I flashed which were AMD EEPROM. I would really like to understand this behaviour. Any thought about that ?

          thanks in advance guys !​

          Comment


            #20
            Originally posted by ValVal456 View Post
            First of all, awesome script/DIY, it seems to be working perfectly.

            However, I don't know why error 155 and 156 (internal : EEPROM-adaptation) keep popping after flashing 0401PD31 CSL software. I tried erasing error memory and adaptations without success, it pops back everytime I restart the DME. I have done other CSL conversion with the same software but with AMD EEPROM and I haven't had any issues. I compared the files for this DME with other CSL conversion I have done and I haven't seen anything weird. I guess I must be doing something wrong or something is wrong with this particular DME (faulty EEPROM ?). Does anyone have an idea ? Only thing I haven't tried is putting the DME in the car and just give it a try. Last resort I'll just replace the ST EEPROM for AMD ones.

            Also, I had a weird ZIF mismatch error with MSS54 DS2 tool which I never had with AMD chips running with the same file. I figured out that every 211325000401PD31 "unmodified" files available online contain different version string at location 0x7E00 (in full binary) ASCII string state "211325000301" followed by program version "7834981" 2 times. All other locations (0xBFB8 and 0x41B90 in full binary) are stating "211325000401" and "7837340". I solved the ZIF mismatch problem by writing "211325000401" and "7837340" at 0x7E00. I find it very weird that the error doesn't seem to appear with other DME I flashed which were AMD EEPROM. I would really like to understand this behaviour. Any thought about that ?

            thanks in advance guys !​
            What tool are you using to read the codes? These codes will trigger after flashing/BDM-ing and MSS54 DS2 Tool doesn't suppress them like some other tools do. Interesting that you say it's reoccuring after a DME reboot, is that to say you clear the code, then reboot and it reappears as an actual code (not a shadow code)?

            The ZIF mismatch is a result of flashing the program and tune separately. You shouldn't have to manually correct anything and it will sort itself out after a couple of cycles. I am currently investigating the best way to address this. It's worth noting from my experimenting that other OBD2 flashing tools seem to cause this as well (they just don't surface it up to the user like MSS54 DS2 tool does :-) )

            2005 ///M3 SMG Coupe Silbergrau Metallic/CSL bucket seats/CSL airbox/CSL console/6 point RACP brace/Apex ARC-8s
            Build Thread | Community Patch | MSS54 DS2 Tool

            Comment


              #21
              ​I tried INPA and MSS54 DS2 tool both give the same result. When I delete error memory, as long as I don't power cycles the DME 155 and 156 code's don't come back. As soon as I power cycle the DME 155 and 156 are there again as actual code (not shadow code)... Should I try another software to confirm it's an hardware issue ?

              I'm flashing a complete master and slave file with tune and all necessary mods (VIN, ISN, ...) via USBJTAG NT. I don't flash anything via OBD2 afterwards.

              Here is some pictures of what I saw in all "unmodified 0401PD31" full binary I found online :

              Click image for larger version

Name:	7E00.png
Views:	44
Size:	6.8 KB
ID:	572494
              Click image for larger version

Name:	BFB0.png
Views:	40
Size:	13.1 KB
ID:	572495
              Click image for larger version

Name:	41B90.png
Views:	40
Size:	8.5 KB
ID:	572496

              As soon as I change string "21132500030178349817834981" to string "21132500040178373407837340" the ZIF mismatch warning is gone. Who knows why such a mismatch exist in a supposedly "unmodified file from factory" ? Weird isn't it ? I don't think it would have corrected automatically or would it ?
              ​ ​​​​
              I agree MSS54 DS2 tool seems to have a more in depth checklist than all other existing software. Without it I wouln't have noticed the ZIF mismatch warning.​

              Comment


                #22
                Originally posted by ValVal456 View Post
                ​I tried INPA and MSS54 DS2 tool both give the same result. When I delete error memory, as long as I don't power cycles the DME 155 and 156 code's don't come back. As soon as I power cycle the DME 155 and 156 are there again as actual code (not shadow code)... Should I try another software to confirm it's an hardware issue ?

                I'm flashing a complete master and slave file with tune and all necessary mods (VIN, ISN, ...) via USBJTAG NT. I don't flash anything via OBD2 afterwards.

                Here is some pictures of what I saw in all "unmodified 0401PD31" full binary I found online :

                Click image for larger version

Name:	7E00.png
Views:	44
Size:	6.8 KB
ID:	572494
                Click image for larger version

Name:	BFB0.png
Views:	40
Size:	13.1 KB
ID:	572495
                Click image for larger version

Name:	41B90.png
Views:	40
Size:	8.5 KB
ID:	572496

                As soon as I change string "21132500030178349817834981" to string "21132500040178373407837340" the ZIF mismatch warning is gone. Who knows why such a mismatch exist in a supposedly "unmodified file from factory" ? Weird isn't it ? I don't think it would have corrected automatically or would it ?
                ​ ​​​​
                I agree MSS54 DS2 tool seems to have a more in depth checklist than all other existing software. Without it I wouln't have noticed the ZIF mismatch warning.​
                Well that's fascinating - great find!!! I'm going to look into this in more detail later when I'm not working. 0301 is the earlier version of the CSL software - so I think it's a valid string, just not for the 0401 version of the code...
                2005 ///M3 SMG Coupe Silbergrau Metallic/CSL bucket seats/CSL airbox/CSL console/6 point RACP brace/Apex ARC-8s
                Build Thread | Community Patch | MSS54 DS2 Tool

                Comment


                  #23
                  Yeah 7834981 does correspond to 0301 I believe

                  I wonder if the source of that file was a DME that was updated to 0401 or if someone (perhaps even me lol) just copied over the 0401 program and tune by hand and then distributed

                  Comment


                    #24
                    Ok thanks terra, that would explain it.

                    Little update on the matter. To explain what I'm doing, my car is actually running on a MSS54 to HP with 0401PD31 software. The MSS54HP with ST EEPROM and 155/156 errors is for a friend car which is 400km away so I can't test it on his car. What I did is flashing the VIN and tune from my car to this MSS54HP DME. After flashing I still had 155 and 156 errors on the bench. Once I plugged the DME to my car and cleared the code they were gone, great success !!!

                    However, I have two not present shadow code that were not there on the bench and are not there with my MSS54 to HP DME. Here is a picture of the codes :



                    The TOG on my car need to be replaced so the error is normal and EWS error is there because I didn't want to synchronise it to my car so I deactivated it in the tune. The car is running perfectly but I'm bothered by these shadow codes which are again EEPROM related and are not clearing ... Even weirder see the error reading with PAsoft 1.4 in the next picture :



                    PASoft also won't clear anything. If anyone as an idea I'm all ears ...

                    Thanks guys​

                    Comment


                      #25
                      error 155 (master) and 156 (slave) (internal : EEPROM-adaptation) = flash memory master/slave is broken
                      Descripton in German:
                      Prüfsummentest der EEPROM-Emulation über verschiedene Bereiche fehlgeschlagen.
                      Ursache kann defektes FLASH sein.
                      Bei wiederholtem Auftreten FLASH-Defekt sicher.
                      Ausnahme: Steuergerät wurde gerade programmiert!​

                      Comment

                      Working...
                      X