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

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

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.

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.

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.

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

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.