Haldex Checksum Issue

[threepotMR2]

Firstly thank you, VW_Flash is awesome, an amazing work which must have consumed a huge amount of time!

I have noticed a small issue with the Haldex, but please excuse my poor description as I am not overly technical.

I have a file with 100% the correct checksum which has at the address:-

4DC08h = 9F 9B 30 30 30 34
4FFFCh = 30 30 30 34

But when I use VW_Flash to write it these values become (read back with miniwiggler after write with VW_Flash):-

4DC08h = 9E 96 30 30 31 39
4FFFCh = 30 30 31 39

I don't really know how this checksum works, but it appears to be increasing the first byte by 1, and the second byte by 5.

Maybe this flash which is for a VW Crafter 0CQ907554F SW7210 has a different checksum calculation, I don't know.

I have Infinion DAP Miniwiggler v3 which is how I read the 0CQ907554F SW7210 firmware because there is no FRF update file released, then I have used your wonderful tool to write it. But then it gave me a weird undocumented fault code which drove me made for weeks! "16725 - ROD - Unknown Error Code". Eventually I noticed when I read back the dump using miniwiggler after it had been wrote with VW_Flash the checksum bytes above had been changed by VW_Flash.

I have manually overwritten the the last three blocks of data to overwrite the checksum with the correct value:-
4D000 to 4D444
4E000 to 4EFFF (blank)
4F000 to 4FFFF

And now this unit it works, I have tried this on 3 of these units, so 100% there is some sort of checksum calculating issue.

I do not ask for you to go down an endless checksum solving solution!

Please can you make an update with a tickbox to simply not calculate the checksum at all and use the checksum already in the file? Like a checksum manual overide option?

Thank you again for the greatness of this project, it has really got me and freinds out of trouble as these 0CQ907554F SW7210 have been on back order with VW + MAN for 2 years now and this has been our wonder solution.

[bri3d]

A manual override is a good option, I'll look into to it.

Meanwhile if you can share these files since there is no FRF, @ConnorHowell and I can probably look at the calculations.

[threepotMR2]

Deep down a days rabbit hole I have been! I installed Python, well 3.12, but that wouldn't install 1 of the requirements, figured out I needed a previous version so dropped to 3.11, and that nearly ran your project but the openport wouldn't work, then figured I needed x86 version instead of 64 bit python. Finally got off the floor and into the project. Spent hours bumbling about messing with the haldex_checksum and haldex_flash_utils - I am not a programmer, this stuff is well over my head.

Looking at the console I was getting "Discarding block FD_3DATA.VERSION.bin because project ID 0004 does not match"

But the correct checksum was in FD_3DATA.VERSION.bin ! It was not using it though.

So I'm guessing maybe the FD_0 driver has something in it that checks validity with the other files.

So I took this part out of the binfile.py:-

if not str.startswith(block_info, flash_info.project_name):
logger.warning(
"Discarding block "
+ filename
+ " because project ID "
+ block_info
+ " does not match "
+ flash_info.project_name
)
remove_blocks.append(filename)

Bingo, writes the modified flash with the correct checksum as per my bin files!

I'm guessing this is total abuse of your function, but it proves its possible.

Also the FRF extraction for the haldex frf's does not work correctly, it makes a file too large, ends up about 329kb bit it should be 320kb, it has pages of 00 00 00 on the end past 4FFFF, and different FRF's end up with different file sizes.

[bri3d]

Also the FRF extraction for the haldex frf's does not work correctly, it makes a file too large, ends up about 329kb bit it should be 320kb, it has pages of 00 00 00 on the end past 4FFFF, and different FRF's end up with different file sizes.

It dumps the raw data out of the ODX which is sent by ODIS (or VCP or iDEX or whatever other tool does ODX-based flashing), so this must be how VW did it for some reason or another, where what is sent over the wire does not exactly match what is in Flash. It is incredibly annoying, regardless, but it's not an incorrect behavior.

Looking at the console I was getting "Discarding block FD_3DATA.VERSION.bin because project ID 0004 does not match"

Ohhhh, this makes more sense. This is a bug that will be fixed. And, well, it's not a checksum, but a version specifier. This is why you got a fault code and not a brick (if the true additive checksums fail, the control unit boot loops).

[threepotMR2]

Thank you for coming back to me :)

When I dump the FRF's with VCP (vagcanpro) that gives the correct file sizes.

Either way I have a work around for the time being, and thank you for doing this open source project, it is amazing that there is a tool for flashing haldex controllers beyond just factory FRF files.

[threepotMR2]

I keep using VW_Flash to write FRF's to Gen 5 units and it seems to work flawlessly. Wrote about 40 unit with it over the last 6 months. Seems very stable.

[KiethBurton69]

I keep using VW_Flash to write FRF's to Gen 5 units and it seems to work flawlessly. Wrote about 40 unit with it over the last 6 months. Seems very stable.

Hi would you be able to share the file for this version please? We are working on a tuning solution and believe this version may have the most control. Thanks