Haldex Flashing struggles #144
Comments
|
Could you send over the files you're trying to flash? Preferably the first file you tried to flash? The log is showing as every single checksum being incorrect which doesn't sound right... |
|
Hi Connor, Here is the files, it gives the same checksum errors when flashing the mod. My plan was to flash the frf which is the same version on the controller currently to ensure a complete flash and then the mod. Thanks |
|
I also tried removing the checksum checks as @threepotMR2 did in the bin.py file as both the odx and mod file dont need any checksum corrections i need it to flash untouched. I tried again with all normal code in place and it gets stuck even sooner here is logs |
|
udsoncan.log |
|
It will not flash for me either, it fully completes the write, but then the module is bricked (party time!) |
|
Thanks for extracting it! Thats odd it actually fully flashed for you but bricked, did you leave checksum alone? Also ive just realised you will have the mod file please keep that to yourself as it was super expensive to obtain :) I just need to figure out a way to flash it which is my main obstacle. The only reason i wanted to flash the odx was to insure it could complete the process. |
|
I will have a play either later tonight or tomorrow. |
|
My two units are soft bricked because the last block of data has not been written. I've messed with alot of these Gen 5 haldex files, and this file is the only one I've seen so far with data after that 0x4DBF0 line with the checksum at the end. |
|
I think that what's going on here is twofold:
Connor's going to look into fixing up the flasher to support variable-length blocks; no other control unit really does this thing where different versions are flashed as different sizes. |
|
There is only 1 table that has actually been modified in this file, and its a DTC/fault code table that's has some codes deleted out of it. So I'd say that is almost certainly correct that its the RS3 file fudged to run on the MQB's golf/a3/tt etc. |
Yep this is definitely it, noticed that earlier! These are all U112200 codes so almost certainly just to facilitate the cross flash onto an RS3 file |
|
@threepotMR2 @KiethBurton69 I've just done some really hacky changes to make it use variable lengths for the ASW & VERSION blocks on my fork (https://github.com/connorhowell/vw_flash) Passing a bin file to either the CLI or GUI will now take the block lengths from the checksum header instead of assuming a fixed length. |
|
@ConnorHowell I'll give it a blast now and see how many more I can brick today. |
|
@threepotMR2 how did you get on? I still cant get it to flash it does not even attempt the first block now just fails. Here are the logs. Im using this prompt in the cli python VW_Flash.py --action flash_bin --input_bin "INSERT FILE" --interface J2534 --unsafe_haldex Tried using the gui also but it rejects the file as not being a valid bin or frf, does it make a difference that the mod file is saved in hex? I tried converting to bin also but thats the same outcome |
Yep absolutely matters that it's a .hex, even converting that to a bin file won't put the data in the places that VW_Flash expects, I'll email you over your files in the correct format shortly. |
|
exactly this ^^^^ It will never write with vw_flash because its file size and formatting isn't correct. But worry not, this is 100% flash-able with a bit of playing. I faied to write it last night as at the same time I went to my lab at 11pm last night Github had some problem and was down. But at some point later today I will have a play and get it working - but its two stages to get it working. Firstly we have to hope @ConnorHowell's testing purposes fixes to the flash tool which have been aptly called "[haldex hack]" actually work, and then that the file correctly checksums when it is written as your mod file has the checksums missing. |
|
Did you dump this hex file yourself from a control unit? |
|
@threepotMR2 how are you un bricking modules, using Odis or the miniwriggler? |
Only the miniwiggler will allow you to unbrick (it's what you'd usually call a boot mode on commercial tools), you should just be able to flash the .hex file you have to get it back to a working state. |
|
If they are "soft bricked" as I call them, as in it will no longer comm but it will still talk to miniwiggler, then you can write the broken blocks with miniwiggler. But if they cannot be communicated to with miniwigger I just chuck them in the drawer for parts... a person more clever than me will be able to unbrick them with the infineon CAN bootloader but I've not invested the time to get that working yet. Just figuring out the miniwiggler stuff that I shared on nefmoto took many many nights. |
|
@threepotMR2 I think you're going to need a bigger drawer soon lol Interesting those aren't recoverable with a miniwiggler though... |
|
If mess with some of the earlier memory blocks then the Jtag bootloader doesn't work. So be very very careful which blocks you choose to write with miniwiggler/memtool. Not all those boards were bricked, some are just too badly corroded or burnt out. If you are writing using vw_flash then you cannot hard brick a Haldex controller, it can only be soft bricked, because it seems like it stays away from erasing those blocks. |
|
You are better doing a full read, in both hex and bin format.... then post it here, then I'll direct you to only write those broken blocks |
|
You need to write just the area C0B400 to C0EFFF It still has the data between C0B410 to C0EFFF from the old "mod" flash. e.g. FLASHDATA_Addr_0002.bin section never was written. |
|
I've always wondered why if I try to erase/write the full chip with Memtool then it always stops connecting via JTAG.
"DBGPRR value in Flash addr. C001F0 H" When I erase the block 0 being c00000 to c00FFF it fills that whole area with 00 bytes which means the DBGPRR value is 0000h being "Debug Interface = not available" Block 0 upto end of to Block 8 being C08FFF contain the same data in every Gen 5 VAG haldex or VAQ ediff controller, it is the start of the internal program, its some kind of boot loader or something. So I would guess NEVER NEVER NEVER try to erase Block 0 = C00000 to C00FFF |
|
Also found this late last night in the document (xc27x4X_Errata_Sheet_v1.7.pdf) :-
|
|
Here is a video showing how to program only a selection of blocks at a time. |
|
Is there any public pinout diagram for the haldex connection with miniwiggler ? |
Well thats made me feel stupid the second i saw you select the sections it clicked, thank you! Only issue im having now is that it wont begin erasing and fails. Reads out fine and the first 8 bytes are intact so should flash fine.
|
|
@threepotMR2 Thank you. |
Have you tried using the HWCFG pins to pull the device into CAN or UART Bootstrap Loader mode rather than using debug (JTAG) to access Flash? Bootstrap Loader should always work regardless of the state of Flash, and should allow these "hard bricked" units to be recovered. |
|
I am confident the CAN bootstrap loader is still accessible, and will probably be a more straight forward method to manipulate the flash, as looking at the PCB config resistors its setup to be in CAN BSL from the factory. With a good tool we should be able to just plug in to the external haldex connector and do the CAN BSL. If there is some easy to use software and some supported CAN interface you suggest I will happily buy it and play. I do not have any software tools or hardware to try the CAN bootstrap method. |
For CAN development I use a Raspberry Pi with a CAN hat and SocketCAN, programmed in Python. I believe https://github.com/bri3d/TC1791_CAN_BSL/blob/main/bootloader.py#L303 is the same protocol for XC2000 as Tricore (XC2000 is basically our good enemy C167 with Tricore peripherals synthesized onto it). But, of course, a C167-compatible BSL binary will need to be compiled. https://www.infineon.com/dgdl/ap1616410_XE16x_FlashViaCANBSL.pdf?fileId=db3a3043243b5f1701245769271d09cc covers this in depth. It sounds like the Hitex debug tool HiTOP53-UConnect-XE164 can also do this using provided software, but it is probably more of an expensive pain in the ass to find all of this stuff than to write a little BSL binary like I did for Tricore (famous last words... C167 is so evil...). |
|
I have been hunting for an Infineon Uconnect for about 2 years on and off. There is a proper infineon CAN flashing file driver for minimon that I found years ago, but the Uconnect usb dongle eludes me! The dutch guy who is vd Veer Engineering I think has managed to do CAN BSL stuff on these. But again he is good at programming like yourself - I am just a mere bodger. |
We had only problems with his controller though... DTCS, Burnt clutches etc.. |
|
The controller isn't perfect, it is a man in the middle attack. But he is a very clever guy to get as far as he has with that project! PCB design, embedded software, reverses engineering all the CAN analytics, and the phone app - that's pretty good going for one guy as a side project. The clutches will always get nailed if you use them outside of OEM application, Haldex is really designed to get a Yeti or a Tiguan out of the snow. Haldex is not a real 4wd system, if people want to play with high power 4wd they need a central differential not a clutched PTO. |
|
Hello @ConnorHowell There is some other issue with VW_Flash that is a slight problem, so when you have an unsuccessful flash that correctly writes the C10000 area OK but there is an error in the C0B400 area, the haldex ECU will connect via UDS, it'll give you its part number, but it will not reply with fault codes or anything else. When you try to do a flash, it always checks for fault codes, and when they are partially corrupted like this you cannot recover it with VW_Flash..... but I can write them with VCP instead luckily. I think we need VW_Flash fixing so it does not check the fault code status first. @KiethBurton69 Also can you please email me the files formatted by Connor as I can't seem to get this file flashed with the files formatted by myself and its driving me nuts! I'm obviously doing something stupid. |
|
Hi @threepotMR2 I see! Recovery with VW Flash would be super handy as its a pain getting the module setup on the bench. |
|
I am experimenting with xprog which is has support for this micro and I think it works over CAN. |
|
Interesting, I believe it's only trying to erase codes but is probably causing the issue. Erasing codes is usually a prerequisite to flashing some ECUs which is why VW_Flash will try to do it. I'll push a commit to my branch shortly to skip that step for the Haldex; then once it's all confirmed working I just need to fix all my hacky code lol! Regarding the RS3 file, an sgo file is what you'd normally have for pre-uds control modules. FRFs are what is used for anything modern, these are essentially encrypted zip files that contain an ODX file which contains the flash procedure and everything required to perform the flash (data, encryption/compression identifiers, checksums etc.) To be honest it would be trivial to fix the checksums in a haldex file, update the flash checksums & data in the ODX and use that with VCP to flash a modded file. |
|
This is killing me! It will not flash the modded.bin or stock.bin. I always get the partial brick problem... comms but not properly....
here are my logs.... help!! flash.log Its always that FD_3Data area, something isn't playing ball. But this does go to show, that as long as FD_2Data writes OK you always end up with functioning comm's with the unit - e.g. you can screw up FD_1 or FD_3 then it still recovers OK with VCP. |
|
Try changing STMin_TX |
|
@KiethBurton69 Yes, it never works for me... (do you have VCP too?) @bri3d I've just changed STMIN_TX to 200 and its done the same. I'll try it at 400 instead. But I don't think its a hardware issue, I think its something screwed up with the variable size block 4 data. @ConnorHowell I've just packed an SGO file as you suggested and VCP has wrote it first time. |
|
Wasn't an stmin issue, I was only half overriding the block lengths. @threepotMR2 try the latest change on my fork. |
|
@ConnorHowell It works! |
Hi,
I cant get the Haldex flasher to flash past block 1 using CLI in vs code python v3.11.
I have a complete modified dump i need to flash but also cant get any FRF's to flash. The driver block 0 will flash fine but it then gives up, have you got any ideas? I have a "dashing module not loaded" message at the top of the terminal however all other functions are working as intended i have comms with interface and controller.
flash.log
flash_details.log
Please find logs attached
Thanks
The text was updated successfully, but these errors were encountered: