-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
'Recovering a bricked Simos18 ECU' method does not work #4
Comments
Erasing any kind of flash memory can only be done a sector at a time, so the calibration should indeed be missing the first 4KB. That's normal and should be just fine. This will cause an ECU to enter a permanent CBOOT state. I have never tried immediately putting it back behind the gateway, and perhaps there is some issue that prevents this from working (although there shouldn't be; CBOOT gets its identity info from DFlash and shouldn't be looking at CAL besides to see it fail checksums as far as I know...). Maybe ODIS just can't talk to an ECU stuck in CBOOT? I actually don't know... What we usually do is erase the first sector of CAL, reset the ECU, and immediately just run VW_Flash on the Pi from the command line to flash the ECU from CBOOT. There are quite a few folks using this setup so I promise it does work; it's just very rough-around-the-edges since it's a research tool I haven't had time to maintain. Try connecting to the ECU using VW_Flash over a direct connection rather than behind the gateway and see if it works. |
@bri3d , The reason I'm doing this is because the 'professional' guy, whom I sent my ECU to the opposite side of the planet to get it recovered after I screwed it up by flashing a firmware with non-matching powerclass, turned out to be bloody miserable and incompetent. After he read PFlash and DFlash from my ECU he reported he is unable to write a modified firmware back no matter what he was doing. Eventually I identified the reason - he fried the ECU by shorting SC90 chip to ground and now it consumes 1.3A of current, generates 2V from all output channels instead of 5V and 3.3V and produces enormous amount of heat. After he had no success with that ECU he told me he needs another ECU to move immo data from my fried ECU to this donor ECU making it to work in my car, so I purchased and sent him another one which he reflashed to modify data and sent both ECUs back to me. After getting the package I immediately plugged in the second ECU and attempted to start the car - but that didn't succeed. The second ECU had 2 errors - P157000 'ECM Locked' and P060600 'ECM/PCM Processor' (which indicates corrupted data in flash afaik). So now I'm left for myself with 2 ECUs - one with cooked hardware and another one with screwed up software. Luckily he was kind enough to provide me with all readings from these ECUs before he messed them up. The reason I'm telling this is because I do have a strong suspicion that DFlash in the ECU I'm working on is corrupted in some way. Although I tried to erase a sector in PFlash to force it into CBOOT to get flashed with factory firmware from frf, it was just to exclude the most obvious and easy to fix potential root cause among multiple others as the chances are high DFlash is corrupted but not PFlash. Once again, thank you for your advise, I'll definitely try VW_Flash on the bench with direct connection to ECU, although I'm currently more into restoring of PFlash and DFlash into that ECU from the original reading and then will try my own immo transfer procedure using paid online services dedicated for these purposes. And this project including Pi and TC1791 BSL toolchain is my only chance to do this as there is noone on my continent having suitable tools to do this for me. |
Howdy @bri3d ,
Me again.
After a day of fighting with miscellaneous issues with hw and sw I have finally made the tool and script work. I've also modified bootloader.py to be able to read into files without compressed read and added some options to create a 256K DFlash and 4M Pflash concatenated files similar to files created with commercial tools and have successfully read full PFlash and DFlash areas to have a backup before erasing.
Erasing of the first sector of calibrations (80800000) went well too. However after erasing this sector, disconnecting all jumpers and wiring attached for bench operations and plugging the ECM back to the car the rest of the described method was unsuccessful. The ECM simply didn't come up in diag and showed as missing in the list of modules. Direct querying from ODIS did nothing. Hence it was impossible to flash it with ODIS through OBD.
The ECM is 06K907425B, Simos18.1, firmware 5G0906259E. I have performed reading of PFlash starting from address 80800000 after erasing was done and compared to previous reading. It turned out that ECM is missing first 4000 bytes of calibrations. Is this supposed to be this way or did something went wrong again? I suspect a simple erase of 1 byte would be enough to cause checksums not matching but why 4000?
Should I try to restore this area from backup and erase just a random byte or two somewhere in calibration area where it does not cause the entire communication process to break?
The text was updated successfully, but these errors were encountered: