NefMoto

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.

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.

OK, when the car's back I'll try a few more attempts. Thanks for your support.

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.

Done.

Same as before, log is attached. At least it's repeatable.

Cheers,
C.

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.

The test version failed in exactly the same way, although it took noticeably longer to get to that block.

File is attached.

C

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.

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.

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.

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.

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...

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.

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.

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.

I now can explain the observed behaviour thanks to simulation results.
First you must know what internal steps the ME7 normally does when erase of sector 81'0000-81'FFFF is requested:
1. copy the data from 81'8000-81'818F (persistent data) to 80'FC00-80'FD8F (also in flash!)
   if the copying fails, the following steps 2 and 3 will NOT be executed.
2. it will erase the sector 81'0000-81'FFFF.
3. it will copy back the persistent data from 80'FC00-80'FD8F to 81'8000-81'818F.

Two things about this are remarkable:
- step 1 above is a flash programming step and yes, it is tried without erasing the target sector before.
  That means, the ecu can only copy the persistent data successfully if source and target are identical or
  if bits have to change only from 1 to 0 (writing a flash bit 0 to 1 is not possible).
- step 3 means, that you do NOT have a really empty sector after erasing 81'0000-81'FFFF, it
  will normally again contain it's old persistent data.

This can cause two different problems during flashing:
- in the case of Carlossus' image, the tuner has changed the persistent data at 80'FC00.
  After programming the complete sector 80'8000-80'FFFF with the contents of the new image,
  the persistent data at 80'FC00 does not match the one at 81'8000.
  Now when the flasher tries to erase 81'0000-81'FFFF, the internal step 1 fails and sector erasing is rejected
  (as seen in the flashtool logfile)!
- if the tuner did not change the persistent data at 80'FC00, but the ones at 81'8000, then following can happen:
  The flasher erases 81'0000-81'FFFF, the ecu stores back internally the original persistent data.
  Then the flasher programs the changed sector, this will be successful until at address 81'8000
  the changed persistent data can't be programmed because the flash contains non-matching data.

Possible solutions:
=> Erasing complete flash in one step helps to circumvent these problems, because then the ecu does not perform
   the persistent data backup steps. But it's not really good to do this!!
=> Erasing sector 81'0000, then 80'8000 and then again 81'0000 before programming both sectors
   helps in both situations. The ecu will not backup persistent data for the 2nd erase of 81'0000.
=> don't try to flash files where tuners have changed areas that better should not be changed
   or know what you do and revert these changes.


Two additional remarks:
- Both persistent data areas 80'FC00-80'FD8F and 81'8000-81'81DF are NOT included in checksums.
  So you can edit these areas without checksum updates needed, but normally you should keep them as they are!
- When writing to the flash in range 81'8000-81'81DF, the ecu will ignore FF's in the write data and keep what
  is in the flash (even if there is something not equal to FF).

I successfully flashed a version of the tuned file and it works fine. I flashed using the latest standard release of the flasher.

Differences between tuned file that wont flash and tuned file that will flash?

I removed 4 instances of 'NOREAD ' and tuners sig at the end of the file, then corrected checksums. that's it. I'll reinstate the tuners sig later and see if it still works as it's not my desire to remove it.

In both cases 881D = 0x00 I haven't tried to read over ODB2 because I don't care about it.

EDIT: Just ready setz62's lastest update.. This doesn't correlate to your info because in my working tuned file the data in the "persistent" area is non standard and it still works OK. The changed data is at FC30.

Fascinating this.

Happy days for me though :)

Tony, this problem will be present also for ME7.1.

You could make one simple test with the flasher:
- Read the current image out of the ecu.
- Take this image and change file offset 0x00FC30 from FF to something else.
- Try to flash the changed image again using "Write Entire Flash" and see what happens  :o!
 
Furtheron, this sequence will show you ME7's internal behaviour:
- start with ecu running clean image
- erase sector 80'8000(32kB), then read this sector and read sector 83'0000(64kB)
   -> see that 80'8000(32kB) is clear and see what contents sector 83'0000(64kB) now has!!
- now erase sector 81'0000(64kB), then read this sector and read sector 80'8000(32kB)
   -> see what contents both sectors now have!!

Good discussion of some of the intricacies of flashing the ME7 here. :D

Setzi62 you are quite right about the flash backups between sectors 808000 and 830000. I had found that backup while erasing code in the ECU a long time ago and had forgotten about it. You are also right that erasing the entire flash chip at once prevents the backup from occuring. I have not confirmed for myself that changing the values in these memory sectors from what is already on the ECU causes a problem though. I will try to confirm that myself in the next few days.

To see if this is the issue that carlossus was running into I have sent him another test release. The latest test release now supports out of order sector flashing when retrying failed sectors. It will attempt to flash the sectors in order, but if one fails it will flash the next sector before retrying the current sector. I think this should allow us to work around this sector backup issue without adding to much complexity to the flashing software. At the same time this should allow the flashing software to more fault tolerant in case of errors. Even though this release can reorder the sector flashing, it always ensures that the last sector is flashed last just before attempting to end the programming session. The ME7 ECU appears to require that the last sector in the flash is the last one programmed for it to consider the programming complete.

I really don't want to provide the option to erase the entire ECU flash. From my testing a year or so ago, I found that if the flashing failed after erasing the entire flash, you could only recover the ECU using boot mode. The ECU is much more fault tolerant when flashing individual sectors. If the flashing fails with individual sectors, then the ECU remembers that it is corrupt and boots directly into programming mode.

I don't agree with you about not flashing the first memory sectors where you think the boot up code is located. I would consider the risk of having incompatible versions of code mixed between the different flash sectors to be too high. I know that the ME7.1 has internal flash ROM on the processor that contains all of the necessary code for programming the ECU if it is corrupt. I am not sure if the processor in the ME7.5 has an internal flash ROM or not though.

I fear that writing the next sector and the coming back to the failed one will not work in this situation:
Erase 80'8000 -> OK
Write 80'8000 -> OK    (with changed persistent data)
Erase 81'0000 -> FAILS (because copy step 1 not working)
Erase 82'0000 -> OK
Write 82'0000 -> OK
Erase 81'0000 -> FAILS (still copy step 1 not working)

For ME7.5, I will never erase the first 32kB, this contains really the bootrom. I would not load a tune that makes changes in the bootcode into my ecu (if I did not make the changes myself  :)).
For ME7.1 the situation is clearly different since the bootcode is not in the flash.

For the record I confirm that simply changing addresses FC32 though FC38 back to FF and nothing else in the failing file enables successful flash.

Are we sure that the ME7.5 doesn't have any internal boot rom in the processor? The only way I was able to confirm that the ME7.1 processor has internal boot rom was to read it out in boot mode using MiniMon.

As for finding a way to write different data to the flash sectors with persistent data, I can reproduce it, but I don't have a fix yet. I changed a stock file I had to have some of the FF data at 0x80FC30 set to 00. After making that change I was not able to flash the file to my B5 S4 ME7.1 ECU, and it failed the same way carlossus saw.

I tried flashing the sectors from highest to lowest, and that would not allow me to change the persitent data either. I also tried skipping sectors that wouldn't allow me to erase and retrying them after flashing the next sector, but that doesn't work either because once you start to program a sector the ECU will not let you program a different one until you complete the current one. I also tried erasing a memory range covering multiple sectors that contained all of the location fo the persistent data, but the ECU won't let me erase a memory range covering more than one sector.

I am going to spend some time going through the assembler code that handles the persistent data backup, but the only solution may be to flash the entire chip at once in this situation. If that is the case then I will see if there is any way to prevent the ECU from getting bricked in the case of a failed flash of the entire chip.

I could completely erase the 80'8000 and 81000 by erasing  first sector 81'0000, then
sector 80'8000 and finally again sector 81'0000 before programming both sectors in
sequence. The ecu will not backup persistent data for the 2nd erase of 81'0000.
Maybe this sequence works also for you.

To see that ME7.5 has no internal bootrom, someone could erase the complete flash,
then reboot the ecu and check if the boot code is running or not.
If internal bootrom would be present, then a fast init to address 0x11 is possible and
ecuid(0x94) will return the bootromversion. Sadly I don't have a spare ecu and the
bootmode tools for recovery available to show this myself.

What messages did you send to the ECU to do this? Did you send a RequestDownload before each erase request?


From my testing with the ME7.1 if you erase the complete flash the ECU will not boot. This is something I am going to test again soon, because it is possible I did something wrong before since I did it a long time ago.

I did some further testing on programming sector combinations on the ME7.1. I found that the ECU will allow you to erase and program a range of sectors at once, as long as that range of sectors does not cover the two areas where persistent data is stored. So we cannot use this to change the persistent data areas, but it does mean we don't have to use separate memory layouts for the 29F800BB and 29F800BT chips. We can just have one memory layout that programs the chips with 64k sector sizes and that will work with the BB and BT chips.

My plan is to do some more testing with erasing and programming the complete chip. If this method can be made fault tolerant, then it is also the method that is likely to work with the most ECU types.

Not a ton of help but I can confirm with ME7.1.1 there are no issues getting into bootloader mode with a 100% blank flash or even the flash removed altogether.

Tony, some of the issues I have seen trying to program ME7.1.1 are likely due to the issues discussed in this thread. I now have a spare ECU I can torture as much as I want for further testing with new versions.

I did not send DownloadRequest before the erase requests.
To fully erase both of these damned sectors under any circumstances, finnaly the sequence
"Erase 80'8000, Erase 81'0000, Erase 80'8000, Erase 81'0000" did the job for me.

I can confirm this.

I think I used wrong terms when talking about the internal bootrom which might have caused confusion.

• The term special Boot-ROM is used for the ROM containing the bootstraploader that gets into place
    when entering the bootmode (setting P0L.4 to low during hardware reset). This ROM is always present.
• The term internal mask ROM is used for the 32kB rom which can be enabled/disabled by the ROMEN bit in SYSCON.

I was always of the impression that the "internal mask ROM" is switched off for ME7.5 since the flash contains
a copy of the 32kB code. But I must have been wrong, since in my ecu I saw that the ROMEN bit is set.
So the internal mask rom must be active!

The ROMEN bit gets not set/changed by code, so the state of the EA\-pin (pin 99) during reset will be used to
select between builtin rom and external memory. For ME7.5 it should be possible to clear the EA\-pin and use
the code out of flash for testing purposes. Don't know how the EA\-pin is wired on the ecu, e.g. if there even
is a jumper to select or if it is hardwired to 1.

Here are some changes I am testing:
-Erase flash sectors before doing a RequestingDownload so we can skip sectors that we can't erase.
-If a sector erase fails, restart the flashing process doing a full erase and program of the entire chip at once.

The reason I am pursuing the erase and flash the entire chip at once solution, is I believe it is the most portable between ECU types. If I were to put in special logic with regard to what order each sector needs to be erased in, then that would only work as long as the pattern never changed. Also multiple people have reported that erasing the entire flash memory does not brick the ECU.

Currently though, every time I do a complete erase on the ECU, the ECU never responds again after that. All I can think is that I don't have my bench harness setup correctly. Can any one confirm that my bench harness setup is correct?

Here is how my bench harness is setup:
Pin 1 ground
Pin 2 ground
Pin 3 switched ignition 12v power from terminal 15
Pin 43 k-line
Pin 62 constant 12v battery power from terminal 30

My testing involves connecting to the ECU, erasing the entire flash chip at once, starting to program the new flash memory contents, and then pulling the USB cable mid program. Then I turn off the ignition switch in my bench harness, then a few seconds later I turn off the power switch in my bench harness. After all of this is done, the ECU no longer responds to connection attempts.

Yup, what you said is correct. The internal ROM containing the bootstrap loader is always present. The internal mask ROM is optional and is programmed when the processor is manufactured.

If anyone has an ME7.5 ECU to spare, it would be great if we could test what happens when the flash memory is completely blank. Worst case scenario you would just have to reprogram it using bootmode with Galletto or some other tool.

I have a backup ECU but it may beta couple of weeks until I can try this. I should have the switchable flash setup by then so I can boot to a new, blank flash chip to see what happens. It makes recovery easier because I can just switch to a valid image.

All testing would be done in-car.

There are three possibilities:
1. Not yet fully programmed the boot system (first 32kB)
   -> must use bootmode/Galetto to recover
2. Not yet fully programmed the ramprog before the interruption
   -> can connect to the boot system.
      Older boot system versions allow both, slow and fast init while newer versions only
      allow fast init. Need to use address 0x11 to connect and for communication.
3. Programmed already the complete ramprog before the interruption
   -> can connect to ramprog, should work with KWP2000 slow init and address 0x01
       (this will not end up in KWP1285!). Then use headermode2(physical) with address 0x10
       or headermode3(functional) with address 0x01 for further commumication,
       ecu always responds with address 0x10.

I use addresses 0x01 and 0x11 with slow init, and address 0x11 with fast init. I don't think I have tried address 0x10.

One question I have for everyone who has completely erased their ECUs. Can you still connect to the erased ECU after disconnecting power?

I can connect to completely erased ECUs if I just turn the ignition off, but if I later turn the power supply off they never work again after that.

ME7.1 yes, but only in bootmode .. will work with a desoldered chip as well (or chipless socket).

Can anyone connect to their ECU after completely erasing it using KWP2000 or KWP1281?

Version 1.7.0.0 now supports detecting failed sector erases and will switch to erase entire flash mode. This will allow you to overwrite the persistent ECU data that is backed up between sectors.