carlossus
Sr. Member
Karma: +38/-0
Offline
Posts: 394
Leon Curpa Stg1+
|
|
« on: January 17, 2011, 01:46:30 PM »
|
|
|
So, I just tried to flash a purchased tuned file to my 06A906032HN (2002 Seat Leon 1.8t). This ECU is listed as compatible by ArgDub. It failed at 4% as shown below.
17/Jan/2011 05:29:38.342: LOG: Checksum is incorrect. 17/Jan/2011 05:29:38.343: USER: Flash checksum does not match new data, flashing is necessary. 17/Jan/2011 05:29:38.350: USER: Requesting download to ECU for address range 0x00810000 to 0x0081FFFF. 17/Jan/2011 05:29:38.354: LOG: Sent message with service ID RequestDownload 17/Jan/2011 05:29:38.368: LOG: Received message with service ID RequestDownloadPositiveResponse 17/Jan/2011 05:29:38.370: USER: Request download to ECU succeeded. 17/Jan/2011 05:29:38.373: USER: Requesting flash memory erase for address range 0x00810000 to 0x0081FFFF. 17/Jan/2011 05:29:38.378: LOG: Sent message with service ID StartRoutineByLocalIdentifier 17/Jan/2011 05:29:38.394: LOG: Received message with service ID StartRoutineByLocalIdentifierPositiveResponse 17/Jan/2011 05:29:38.400: LOG: Sent message with service ID RequestRoutineResultsByLocalIdentifier 17/Jan/2011 05:29:38.419: LOG: Received message with service ID NegativeResponse 17/Jan/2011 05:29:38.421: LOG: Received negative response for service ID: RequestRoutineResultsByLocalIdentifier, with response code: GeneralReject 17/Jan/2011 05:29:38.422: USER: Failed to erase flash memory. You may be using the wrong memory layout. 17/Jan/2011 05:29:38.429: USER: 100% complete.
This happened for 2/2 attempts.
Obviously, because of the incomplete flash the car wouldn't start. Selecting the original BIN, cycling the ignition and repeating with the same settings flashed first time with no problem and started fine.
My question is whether the contents of the file can possibly affect the writing success?
I'll try it again later once the laptop battery is charged again.
Cheers, C.
|
|
|
Logged
|
|
|
|
Tony@NefMoto
Administrator
Hero Member
Karma: +132/-4
Offline
Posts: 1389
2001.5 Audi S4 Stage 3
|
|
« Reply #1 on: January 17, 2011, 01:57:03 PM »
|
|
|
Contents of the flash file will not affect flashing. Even if the checksums in the file are wrong, that won't matter until you try to start the car.
I have never seen a GeneralReject response to the RequestRoutineResultsByLocalIdentifier before.
If you could do some more testing to determine if it is only the modified file that causes this that would be great.
|
|
|
Logged
|
|
|
|
carlossus
Sr. Member
Karma: +38/-0
Offline
Posts: 394
Leon Curpa Stg1+
|
|
« Reply #2 on: January 17, 2011, 02:23:02 PM »
|
|
|
OK, when the car's back I'll try a few more attempts. Thanks for your support.
|
|
|
Logged
|
|
|
|
carlossus
Sr. Member
Karma: +38/-0
Offline
Posts: 394
Leon Curpa Stg1+
|
|
« Reply #3 on: January 17, 2011, 03:46:07 PM »
|
|
|
OK, i'm in the car and 4 attempts to program the tuned file failed.
Always at the same block shown above. Also, once a partial flash has taken place the software is unable to validate memory layout. The Traction control light comes on after 1st failed flash.
It's flashing back to original now (1st try worked no problem)- that'll take 12 mins, then i'll start a new log and do the following: -
-Connect and attempt to flash .mod -Cycle ignition -Attempt a 2nd time (as response changes 2nd time) - Cycle ignition - Flash back to Original.
C.
|
|
|
Logged
|
|
|
|
carlossus
Sr. Member
Karma: +38/-0
Offline
Posts: 394
Leon Curpa Stg1+
|
|
« Reply #4 on: January 17, 2011, 04:21:16 PM »
|
|
|
Done.
Same as before, log is attached. At least it's repeatable.
Cheers, C.
|
|
|
Logged
|
|
|
|
Tony@NefMoto
Administrator
Hero Member
Karma: +132/-4
Offline
Posts: 1389
2001.5 Audi S4 Stage 3
|
|
« Reply #5 on: January 18, 2011, 12:55:01 AM »
|
|
|
Thanks for the log files. I have a test release that you can try out. Hopefully it will help us solve the issue. Please send me an email so that I can send you the test release.
|
|
|
Logged
|
|
|
|
carlossus
Sr. Member
Karma: +38/-0
Offline
Posts: 394
Leon Curpa Stg1+
|
|
« Reply #6 on: January 18, 2011, 01:18:22 PM »
|
|
|
The test version failed in exactly the same way, although it took noticeably longer to get to that block.
File is attached.
C
|
|
|
Logged
|
|
|
|
Tony@NefMoto
Administrator
Hero Member
Karma: +132/-4
Offline
Posts: 1389
2001.5 Audi S4 Stage 3
|
|
« Reply #7 on: January 18, 2011, 06:11:35 PM »
|
|
|
This is very strange. I don't know why you can write your original file to the ECU but not the modified file. All I can think is that there is some sort of timing issue with requesting the results of the sector erase before the ECU has started the sector erase.
I will send you another test release with some more timing changes.
|
|
|
Logged
|
|
|
|
setzi62
Full Member
Karma: +142/-0
Offline
Posts: 249
|
|
« Reply #8 on: January 19, 2011, 02:43:09 AM »
|
|
|
This is very interesting, I'm really keen to finally know what is the root cause of the problem here.
One additional fact came up to my mind when viewing the logfile. It's not causing the flashing problem discussed here, but I think worth to be mentioned. I saw in the flashtool's logfile that it erases and rewrites also the first blocks of the flash. The ME7.5 flash contains the bootrom code in range 80'0000 - 80'7FFF. I am nearly 100% shure that the CPU in the ME7.5 does NOT contain an internal bootrom like the one in the ME7.1, but the first 32kB of the flash are used when the cpu reads addresses between 00'0000 and 00'7FFF. Why else should there be a copy of the bootrom code in the flash? Maybe someone can confirm this from practical tests.
Therefore I think it should be absolutely avoided to erase and rewrite the first 32kB of the flash for a ME7.5. For tuning purposes there should be no need to change the bootrom code. And, if the ECU looses power or the ram image gets stuck while you have erased the bootrom code, then goodbye ecu ... You can revive the ECU in this case only with bootmode or with desoldering and external flashing.
|
|
|
Logged
|
|
|
|
carlossus
Sr. Member
Karma: +38/-0
Offline
Posts: 394
Leon Curpa Stg1+
|
|
« Reply #9 on: January 19, 2011, 02:52:00 AM »
|
|
|
My initial thought was something similar, but I am ignorant of the low level operation of the ME7.5. I just can't understand why one bin should be any different to another to flash unless the contents of the flash are used at any point during the process (I assume my tuned file has NOREAD protection and potentially anything else).
Tony, I tried your latest test version and sorry to say the results seem the same (log attached).
Does anyone else have a compatible file for this ECU / SW version that I can try?
Also, it might be worth considering putting a note on the compatible ECU list until this is understood.
|
|
|
Logged
|
|
|
|
setzi62
Full Member
Karma: +142/-0
Offline
Posts: 249
|
|
« Reply #10 on: January 19, 2011, 03:09:14 AM »
|
|
|
Carlossus, would you post the first 64kB of your new file? I know it is purchased one and you normally should not publish it, but I was thinking the flashing of range 80'8000-80'FFFF changes some data that maybe the ramprog uses, which could have influence on the further flashing process. I wonder why this area changed in your tuned file compared to the original, so could check what are the changes there and what influence they have. The ME7.5 makes also a "backup" copy of the ram program when a sector erase for 80'8000-80'FFFF is requested: - first the sector 83'0000-83'FFFF gets erased - then 80'8000-80'FFFF gets copied to 83'8000-83'FFFF - finally 80'8000-80'FFFF gets erased.
|
|
|
Logged
|
|
|
|
carlossus
Sr. Member
Karma: +38/-0
Offline
Posts: 394
Leon Curpa Stg1+
|
|
« Reply #11 on: January 19, 2011, 05:21:36 AM »
|
|
|
I can post the changes from stock (assume 0x008000xxxx)...
0881D: 00 -> 0F 0FC32-0FC38: FF FF FF FF FF FF FF -> 4E 4F 52 45 41 44 20 ('NOREAD ')
The next change isn't until 1124D which is the Tuner's ID string
The behaviour is that it flashes the block with the protection, then this effects further blocks. This, I think is what you are suggesting is happening when it's copied and run from the ram copy?
Edit: It should be possible for me to test this by creating a hybrid file with the first 64kb of the original, flash that with the remainder of the tuned file (obviously car is dead), then flash the first 64kb of the tuned file - letting it fail to finish flashing.
Hmm, lunch time coming up...
|
|
« Last Edit: January 19, 2011, 05:34:15 AM by carlossus »
|
Logged
|
|
|
|
setzi62
Full Member
Karma: +142/-0
Offline
Posts: 249
|
|
« Reply #12 on: January 19, 2011, 06:24:10 AM »
|
|
|
The first change at 881D should be in the reverse direction: 0F (stock) -> 00 (tune). This disables the flash reading function, but is not relevant to the flashing problem you have.
The second change offset you mentioned is FC32-FC38. Can you check again if this is not probably at FC12-FC18? Then it would match with the idea I have why flashing fails.
If you make the hybrid with first 64kB from your stock file, then you just need to fix the checksums again and it will work fine plus allow flash reading again.
|
|
|
Logged
|
|
|
|
carlossus
Sr. Member
Karma: +38/-0
Offline
Posts: 394
Leon Curpa Stg1+
|
|
« Reply #13 on: January 19, 2011, 06:38:23 AM »
|
|
|
To be clear, both files opened with HxD hex editor.
Ori 881D = 0F Mod 881D = 00
FC12-FC18 = FF FF FF FF FF FF FF in both files.
I can't correct checksums here, so may try the 2 pass hybrid file approach anyway as I have some time.
|
|
|
Logged
|
|
|
|
setzi62
Full Member
Karma: +142/-0
Offline
Posts: 249
|
|
« Reply #14 on: January 19, 2011, 06:56:43 AM »
|
|
|
Just under the prerequisite that the only differences between stock and tuned in range 0000-FFFF are at 881D and FC32-FC38: If you use the first 64kB from your stock file and change 881D from 0F to 00 inside it, the use this as the first 64kB of your tuned file you won't need to update any checksums. Or simpler: replace the "NOREAD " with FF's again in the tuned file. Only thing is that flash reading functionality will not work with the tuned image.
|
|
|
Logged
|
|
|
|
|