Pages: 1 [2] 3
Author Topic: Does Nefmoto care what the contents of the BIN file are?  (Read 26306 times)
setzi62
Full Member
***

Karma: +142/-0
Offline Offline

Posts: 249


« Reply #15 on: January 19, 2011, 08:03:26 AM »

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

Logged
carlossus
Sr. Member
****

Karma: +38/-0
Offline Offline

Posts: 394

Leon Curpa Stg1+


« Reply #16 on: January 19, 2011, 08:10:16 AM »

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 Smiley
Logged
setzi62
Full Member
***

Karma: +142/-0
Offline Offline

Posts: 249


« Reply #17 on: January 20, 2011, 02:33:58 AM »

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

Logged
Tony@NefMoto
Administrator
Hero Member
*****

Karma: +130/-4
Offline Offline

Posts: 1389


2001.5 Audi S4 Stage 3


« Reply #18 on: January 20, 2011, 10:18:24 PM »

Good discussion of some of the intricacies of flashing the ME7 here. Cheesy

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

Remember you have to log in if you want to see the file attachments!
Info or questions, please add to the wiki: http://www.nefariousmotorsports.com/wiki
Follow NefMoto developments on Twitter: http://twitter.com/nefmoto
setzi62
Full Member
***

Karma: +142/-0
Offline Offline

Posts: 249


« Reply #19 on: January 21, 2011, 02:59:25 AM »

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  Smiley).
For ME7.1 the situation is clearly different since the bootcode is not in the flash.

Logged
carlossus
Sr. Member
****

Karma: +38/-0
Offline Offline

Posts: 394

Leon Curpa Stg1+


« Reply #20 on: January 21, 2011, 05:28:02 AM »

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.
Logged
Tony@NefMoto
Administrator
Hero Member
*****

Karma: +130/-4
Offline Offline

Posts: 1389


2001.5 Audi S4 Stage 3


« Reply #21 on: January 21, 2011, 07:49:17 PM »

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

Remember you have to log in if you want to see the file attachments!
Info or questions, please add to the wiki: http://www.nefariousmotorsports.com/wiki
Follow NefMoto developments on Twitter: http://twitter.com/nefmoto
setzi62
Full Member
***

Karma: +142/-0
Offline Offline

Posts: 249


« Reply #22 on: January 22, 2011, 10:05:25 AM »

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.
Logged
Tony@NefMoto
Administrator
Hero Member
*****

Karma: +130/-4
Offline Offline

Posts: 1389


2001.5 Audi S4 Stage 3


« Reply #23 on: January 22, 2011, 03:34:45 PM »

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.

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

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.

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

Remember you have to log in if you want to see the file attachments!
Info or questions, please add to the wiki: http://www.nefariousmotorsports.com/wiki
Follow NefMoto developments on Twitter: http://twitter.com/nefmoto
kls
Full Member
***

Karma: +12/-0
Offline Offline

Posts: 97


« Reply #24 on: January 22, 2011, 04:46:32 PM »

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.
Logged
setzi62
Full Member
***

Karma: +142/-0
Offline Offline

Posts: 249


« Reply #25 on: January 23, 2011, 05:42:56 AM »

What messages did you send to the ECU to do this? Did you send a RequestDownload before each erase request?
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.

Logged
nyet
Administrator
Hero Member
*****

Karma: +604/-166
Offline Offline

Posts: 12232


WWW
« Reply #26 on: January 23, 2011, 04:21:52 PM »

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.

I can confirm this.
Logged

ME7.1 tuning guide (READ FIRST)
ECUx Plot
ME7Sum checksum checker/corrrector for ME7.x

Please do not ask me for tunes. I'm here to help people make their own.

Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your experience.
setzi62
Full Member
***

Karma: +142/-0
Offline Offline

Posts: 249


« Reply #27 on: January 25, 2011, 03:43:43 AM »

Are we sure that the ME7.5 doesn't have any internal boot rom in the processor?
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.
Logged
Tony@NefMoto
Administrator
Hero Member
*****

Karma: +130/-4
Offline Offline

Posts: 1389


2001.5 Audi S4 Stage 3


« Reply #28 on: January 25, 2011, 10:03:34 PM »


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.

Logged

Remember you have to log in if you want to see the file attachments!
Info or questions, please add to the wiki: http://www.nefariousmotorsports.com/wiki
Follow NefMoto developments on Twitter: http://twitter.com/nefmoto
Tony@NefMoto
Administrator
Hero Member
*****

Karma: +130/-4
Offline Offline

Posts: 1389


2001.5 Audi S4 Stage 3


« Reply #29 on: January 25, 2011, 10:10:07 PM »

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

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.
« Last Edit: January 26, 2011, 03:52:16 PM by Tony@NefMoto » Logged

Remember you have to log in if you want to see the file attachments!
Info or questions, please add to the wiki: http://www.nefariousmotorsports.com/wiki
Follow NefMoto developments on Twitter: http://twitter.com/nefmoto
Pages: 1 [2] 3
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.027 seconds with 17 queries. (Pretty URLs adds 0s, 0q)