Does The .TUN (Bin) File Include The Operating System

[Tordne]

Does the .TUN (Bin) file that is read from the PCM include the operating system, or does it only have the calibration data?

I have read a post (http://www.efilive.com/forum/viewtopic.php?t=1381) that talks about achieving a MAFless tune, achieved by changing the high frequency fail value.

If the operating system is included, would flashing a .TUN file (operating system and calibrations) from a PCM which has a factory MAFless configuration (i.e. HSV GTS) disable the MAF in a more natural manner (i.e. at the operating system level)?

Thanks and regards,
Andrew.

[Blacky]

The *.tun file contains the entire 512K (or 1Mb) PCM flash image. However, the reflash process extracts only the 96K of calibration data and sends that to the PCM. That is what is called a calibration reflash - it is non-destructive and will never cause your PCM to fail, since the code that does the comms with EFILive is never deleted.

To change anything in the operating system, requires a full reflash. A full reflash has the potential to cause your PCM to fail if the reflash process is interrupted after erasing the PCM memory (operating system and all) and before the operating system is written back to the PCM. (Everything is operating in RAM during the full reflash process - so a power failure to the PCM can cause a PCM to become unusable).

Workshop and Commercial versions will soon have full reflash capabilities, Personal versions will not. We are not offering full reflash in the Personal version so that we can maintain a 100% safe environment for Personal users.

Personal users who need to perform a full reflash (and who are aware of the dangers of a full reflash and who are willing to peform a potentially damaging operation) will be able to upgrade to the Commercial version - which is simply the Personal version, with full reflash capabilities.

Regards
Paul

[Tordne]

Thanks Paul.

I am very keen to upgrade to the Commercial version when that is available, so I was asking with that in mind (forgot to mention).

Is killing the PCM a common thing, or do you really have to be unlucky?

I have a 2002 Holden Commodore SS and am quite keen to try a MAFless tune, so I was thinking of performing a full reflash using the PCM image of a 2004 HSV GTS.

What is the real risk of failure, and what is the resolution if the PCM does get killed?

What would generally cause the PCM to loose power, flat battery, anything else?

I really appreciate the quality feedback from everyone on this forum, it is a great community.

Cheers,
Andrew.

[Blacky]

On a Commodore the risk is almost zero - even if re-flashed "in vehicle" .

There is a 5 second window during which, if the reflash aborts for any reason then the PCM is commonly referred to as "toast". The only way to recover it is to desolder the flash chip and reprogram the chip using an external flash programmer, then resolder the flash chip.

Once full relfashing is released, we will be officially recommending to remove the PCM from the class-2 network while performing a full relfash. Requires either a special connector from GM that isolates the PCM during the reflash process (which is what GM dealers use when performing a full reflash) or a bench harness if the PCM is completely removed from the vehicle.

The following things can cause a reflash to fail:
1. A vehicle battery failure - removing power from the PCM.
2. The engine fuse blowing - removing power from the PCM.
3. A software bug in EFILive - we have worked hard to make sure that will not happen.

We have built the full reflash to be as robust as possible. Even if the laptop fails, or the connection is physically broken during the reflash, the PCM will continue to wait (forever - or until battery power is removed) for the laptop to be fxed and reconnected and the reflash restarted.

Regards
Paul

[leres]

It seems like full reflash could be fairly safe against power loss if you did it in stages. You'd need some code to write into the calibration data area that can communicate and read/write flash memory. Next update the boot vector to execute this new code on cold start, flash the operating system (except for the boot vector), go back and update the boot vector and then write the calibration data. The only time you'd be vulnerable is when you were updating the boot vector and even then you'd have to write a garbage address to it to be totally boned.

If you lose power during or after writing code to the calibration area, you won't have a config that will run the engine but you can still retry the reflash.

If you lose power while updating the operating system, you can still boot and run out of the calibration area and retry.

(Maybe this is what you guys are already doing and writing the flash is so slow that updating the boot vector takes 5 seconds?)

BTW, does LS1_Edit flash just the calibration data or everything?

[Blacky]

The full reflash is fairly safe against failure and the erase/rewrite procedure is organised (simialr to your suggestion) to reduce the window of failure to an absolute minimum, (about 5 seconds).

Prior to writing data to flash memory, you *must* erase the memory. Flash memory is organised in blocks (usually multiple Kilobytes per block). An entire block must be erased and rewritten. The time between erasing the "boot block" and rewriting it is "the window of failure".

But we need to make people aware that, small as it maybe, the possibility of failure exists.

As far as I know, LS1Edit only reflashes the calibration area. Any PCM that is rendered unusable by LS1Edit should still be able to be reflashed by EFILive FlashScan.

Regards
Paul