Unable to full flash 3501 racks

[dkiiv]

We are unable to full flash 3501 racks. Says invalid key, or cantDownloadToSpecifiedAddress

We tried using bri3d's SA2 script with the SA2 tape pulled from a SGO file, but it resulted in an invalidKey error. If we use the key generator currently in the script we receive a 0x42, cantDownloadToSpecifiedAddress

We have located the function responsible for negativeKWP codes in the 3501 firmware, but are unable to decode why, or how we are getting returned a 0x42 when the provided key satisfies a function earlier in the negativeKWP function

https://github.com/actuallylemoncurd/pq-flasher/blob/3501sa2/03_flasher.py#L17-L21

Firmware can be provided upon request for investigation

We currently do not have a log of how genuine tools auth into the rack, it is something we have been meaning to collect but simply havent had time to do it.

[dkiiv]

This occurs on any rack with a 3305 bootloader, so far we know it affects FW versions 3305 and 3501

[MIGINC]

I get the cantDownloadToSpecifiedAddress via the factory tool when trying to flash firmware to parts of modules that look to be set to read-only (example, trying to flash data to the EEPROM area of the 3AA ABS units) Parts of the ECU, maybe EEPROM zones, are marked off-limits to write.

It would be great if we could find a workaround for this.

[dkiiv]

Except we can full flash fw 2501 racks.

The EEPROM is a seperate bit of memory this does not touch

                                    EEPROM 1k x 8
                                          \/

CAN <--> | <--> CL220 <--> | <--> Phonix FL 384k Flash @ 64MHz <--> | <--> TLE7189 <--> motor driver

[dkiiv]

To add to this, I just retested VCP flashing my rack and successfully flashed A000 to 5FFFF. A full flash with a genuine tool

Attached is a CSV file of all the messages used to put the rack into bootloader, auth in, erase, then write

VCPauthExport.csv

[dkiiv]

hex    dec
0x200  512
0x209  521
0x300  768
0x7a8  1960

[dkiiv]

so, quick update on this issue. i think i found something to fix this.

i unpacked the 3501 update SGO file from VW, and noticed some data being written to the rack outside of the ASW. i made a simple routine in a file "recover.py" so mimic this behavior i saw, perhaps it works, maybe it doesn't

it is untested. i have yet to have the time to go test it, perhaps someone else can for me

https://github.com/dkiiv/pq-flasher/blob/cf69e6d9ad18684ae1a96551ba4c70a8b06da6ae/recover.py