On Thu, 18 Aug 2005 08:07:51 +0200, you wrote:

>> Instead of the traditional bootloader approach (where the 
>> loader handles the comms and the
>> programming, and has to be able to recover if the comms 
>> fail), you copy the code into eeprom using
>> the existing application code, verify it back, then call a 
>> small routine at the top of memory to
>> copy the eeprom image to the flash.
>
>I would consider it a big disadvantage that an cooperation of the
>application is required. One erroneous (ill-behaved) application and the
>party is over!

As I said, it's a compromise. You have to decide the risks of failure and costs of recovery versus
code usage.
If it's a choice between not having field upgradability (due to lack of code space) or having a
small risk of failure, then in many cases the benefit would outweight the risk.
 
True, loading bad app code could render the system un-reprogrammable, but this can be controlled by
careful testing and administration.  
The big difference is that the risk of a partially-programmed image is vastly reduced as there are
no comms to go wrong part-way through.

What got me thinking about this was my earlier thread about not being able to bulk-erase chips below
4.5v, and the problem this causes for 3v-only systems. In this situation an ultra-small, but not
necessarily bullet-proof loader, for use only at the factory, would provide a good solution, as any
misprogramming could be recovered relatively easily.. 

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist