I tired to delete all old files and use the complete new pull. But same result as in my last image

Hi,

thanks for your help. Now the Output is that:




VCP still says the old ECU number.

Hi!

Sent. X13 as ECU Variant is shown. H13 I can't see but i attached the Image from VCP in the DM.

If X13 is shown the in-memory patch is working and the car is now in a fake Sample Mode CBOOT. So, you should be able to flash a patched set of blocks now. There is an issue I just thought of though with not having a patched CBOOT to flash (don't worry, you can always go back to stock!). Read along:


This would work, except for something I just thought of which prevents it. Without flashing a patched CBOOT first, this actually won't work, unfortunately. Here's why:

Your car is now loading an ASW which loads up a fake Sample Mode CBOOT in RAM. This fake Sample Mode CBOOT will accept _any_ block, and will mark it as Valid in the ECU memory. But, the next block that's flashed actually has to be a CBOOT with the Sample Mode patch applied, in order to flash a custom CAL. Here's why:

When the ECU writes CBOOT, it actually does it by downloading the data into the CAL block and then copying it into the CBOOT area if it passes all checks. Next, it instantly and immediately reboots into the new CBOOT.

This means that the ASW-based CBOOT patcher will be instantly removed across this reboot - and the now-running CBOOT will not accept patched blocks, unless it is in Sample Mode.

And, when I wasn't thinking right before, I had thought "well, just write CAL first, it will be marked as valid and the rebooted CBOOT won't care" - but this isn't true, because flashing a new CBOOT erases CAL, inherently, because the CAL area is where the temporary CBOOT is written.

So in short - vt1111, you need a patched-into-Sample Mode CBOOT to flash over the top. Right now, your ECU was patched successfully, and it is in fake Sample Mode each time it boots up (that's the X13 identifier you see). Right now, it will write unsigned blocks. But, unfortunately, the unsigned blocks you write need to be a full-time patched CBOOT, for the reasons listed above.

8V is nothing to do with it - CBOOT and ASW versions are independent of brand and product and are shared across all product lines, which is convenient as for USDM MQB cars there is actually a shared CBOOT and ASW (I0 CBOOT and S50 ASW) which has a calibration for almost all models: GTI/A3 2.0 5G 259L__0002, R/S3 8V 259K__0003, Golf/Sportwagen/A3 1.8 8V 264K__0003, and TT-S 8S 259C__0004 all have an I0 S50 calibration for USDM.

Anyway, I added an automated patcher. It is incredibly naive and just patches a hex string, which I am not particularly proud of as it is generally a horrible practice (vs. writing a disassembler and doing it right). However, amazingly, I automated the FRF/ODX extraction process and tested my patcher on every single CBOOT sample I have for all Simos MQB ECUs, and the naive hex patching actually seems to be OK on all known CBOOTs.

So the new process is:

* Flash 8V0906259H__0001 with patch.bin, as you have done. Double check this by looking - Hardware Number should now read X13 (as yours did).

* `python3 VW_Flash.py --action flash_frf --frf yourcar.frf --patch-cboot` . This will apply the FRF to your car but with a patched CBOOT, which will allow unsigned code and CAL blocks for your boxcode going forward.

* Extract the FRF/ODX for your boxcode. FD_4 will be the CAL. To flash a new CAL in the future, you can do `python3 VW_Flash.py --action flash_cal --infile FD_4 --block CAL` to flash a new CAL with whatever changes you want. flash_cal has also been updated to correct both the CRC32 and ECM3->ECM2 summation checksums.

* You can also flash new ASW patches using `python3 VW_Flash.py --action flash_bin --infile FD_1 --block ASW1` for example. Be aware that doing this without having very well-tested patches or ready access to bench/boot tooling (Raspberry Pi with 5V level shifters and CAN hat to use my open-source stuff, or commercial tools), is rather hazardous and can easily result in a brick.

I tested this whole process on my bench ECU using the latest VW_Flash `master` branch and `FL_5G0906259___0009.frf`, I didn't have ___0010 handy. Everything worked great.

The most dangerous part of this process is that you _must_ make sure that the FRF you flash is for the correct vehicle. If the IMO_idxTun0X_C_VW table does not contain a match for the adapted PClass in the ImoDat, the ECU will happily flash the file, boot up, and not find a PClass. Then you will get stuck in "IMMO brick" which requires bench tools to restore.

https://github.com/bri3d/VW_Flash/blob/master/VW_Flash.py#L384 - thanks, but it's been in there for many months now - when using flash_cal to update a calibration, there's no chance for an easy mistake.

Users really only need to watch out when they're flashing initially - and this is in no small part my own fault because I encourage USDM users to cross-flash to specific versions in https://github.com/bri3d/VW_Flash#getting-started to avoid the endless hunt for definition files. Unfortunately, this means any warning added to the "full flash" handler would probably be zombie-accepted anyway.

I think I'll manually generate a table of calibration names with known matching idxTun tables in a bit, and match using a CSV. For now, people should just pay attention to what they're flashing when they're not using flash_cal

Hello

3. Flash FL_5G0906259___0010 Block 1-4

How can i do that?

After flashing the frf for the car, I didn`t see the X13 and my cal block is overwritten.

Thank you.

Best regards
keine Ahnung