Skip to content
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

Open
em1ter opened this issue Nov 9, 2024 · 2 comments
Open

'Recovering a bricked Simos18 ECU' method does not work #4

em1ter opened this issue Nov 9, 2024 · 2 comments

Comments

@em1ter
Copy link

em1ter commented Nov 9, 2024

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?

@bri3d
Copy link
Owner

bri3d commented Nov 9, 2024

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.

@em1ter
Copy link
Author

em1ter commented Nov 10, 2024

@bri3d ,
Thank you for clarification. Flashing on the bench makes a lot of sense rather than using ODIS with ECU behind the gateway. I was just obeying instructions provided in readme to this project which tell to use ODIS. Might be worth updating the readme to indicate that VW_Flash should be used instead.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants