I would like a little clarification on the difference between some of the terms used around flashing ECUs.

i.e. When some mention "over OBD" I first thought that meant in-car flashing only. However, I believe it also applies to boot mode.

I also would like to get a little more info on the process that's happening in each instance.
i.e. in-car flashing, I believe, utilizes flash functions in the code you're writing over, right?
vs boot mode utilizes the processor on the board to write the to the eprom?
And how does that differ from desoldering, using a programmer, and resoldering? <- what's that call?

Thanks,
Rey

To answer your question about standalone flashing of the chip, if you remove the flash from the PCB, you can read/write it using something like this:

http://www.mcumall.com/comersus/store/comersus_viewItem.asp?idProduct=4282
http://www.mcumall.com/comersus/store/comersus_viewItem.asp?idProduct=3149

This hardware device reads/writes to the chip in essentially the same way the processor does - using the electronic interface of the chip and sending the appropriate electronic signals.

Note that you can't use a willem programmer read flash contents that are behind an encryption board (note: you can, but you will just be reading the ENCRYPTED contents of the flash), because the encryption chip waits to detect the ECU booting, before it "unlocks" and starts decrypting the contents of the flash.  This "decryption/encryption" process is kind of a misnomer from what I understand, because in most implementations, the encryption chip sits between just jumbles the contents of the flash around - so the data meant to be stored at a particular address is actually intercepted by the encryption chip, and then the chip stores it in a completely different location on the actual flash chip.  When you request to read a location, the encryption chip knows where the byte is that you're looking for, and then reads the alternate location on the flash chip, and sends the data back - the CPU is non the wiser.

Note I am not condoning stealing somebody else's work - but there are some times you many need/want to bypass this "protection" to fix a tune you rightfully own - or - if you're like me, you don't like the idea of lots of mechanical interfaces that could potentially fail over time with corrosion/vibration, etc.  In most cases boot mode can be used to circumvent this "protection".  I have also seen one instance where NefMoto could read it, probably because the tuner didn't think that reading over OBD would be a threat in the future, or didn't know how to disable the function used for reading over KWP. 

I then removed the eeprom from the encryption board, desoldered the encryption board, desoldered the eeprom from the encryption board, soldered it in place of the board back on the ECU's PCB, made the necessary changes to the rom, and then used boot mode to write the decrypted/modified flash to the freshly soldered eeprom that was encrypted. The result was a configuration I think is more reliable, and the flash could be read/changed in the future without any hassle.

In closing, each tool is extremely useful and you will probably find that NefMoto is invaluable along with Galletto.  You probably don't need an eeprom programmer.

An easy way to differentiate between the functions/use can be broken down like this:

NefMoto:

   Pros:
   *Fast flashing by only writing CHANGED data.
   *Fast reading.
   *Convenient because the ECU stays in the car.
   *Tony is awesome and provides awesome support.
   *Future functionality like checksums will be great.

   Cons:
   *Sometimes tuners disable the read function required to read the ECU
   *No recovery if you have an ECU with a flash that won't boot


Galletto:

   Pros:
   *Can recover from a bad flash
   *Can bypass some protection mechanisms

   Cons:
   *Requires physical access to the ECU's PCB to short the boot pin to ground.  This can suck if your ECU is buried below tons of trim pieces.
   *Slow flashing because the ENTIRE flash is written.


Eeprom Programmer:

   Pros:
   *Absolute low-level recovery from a bad flash
   *Eeprom can be tested/zeroed out
   *Can be used with an adapter to read the Serial eeprom (separate from the program eeprom, where DTC's and other parameters are stored separate from the program flash)
   
   Cons:
   *Requires desoldering/resoldering the eeprom from the PCB, which has a risk of damaging the PCB by lifting pads, etc.
   *Even if socketed, you run the risk of PCB damage, or physical connections that come loose over time.