Actually, I was even thinking of a more complex program which would 'save' the
flash, so to speak.

The flash is limited by how many times it can be erased/written, so if my app
only takes 2k of code, the first version goes in the first 2k.  If I revise it,
rather than overwriting the first 2k, it will assemble and write it for the
second 2k.  The only location that would need to be reprogramed every time is
the jump to user code, which can be ameliorated by a series of nops followed by
the jump.  Just overwrite closer and closer nops, and when you run out,
overwrite all the jumps with nops and start again.  This requires the program
writing to the chip to know where the old code is, and then assemble (or
reassemble?) the code just before programming it.

This would lend naturally to your bad download situation, since the original
code is not overwritten.  The last location programmed is the jump to user code,
and only after a correct verify.  Of course, if your code takes up the entire
flash, then all bets are off... ;-)

This would be important for products which write to the flash frequently, for
whatever reason.  Chances are the casual hobbyist won't run into a bad code
location even if they reprogrammed their entire flash every week.  It would
still take several years for them to wear it down.  A data-logger which uses the
internal flash for storage should follow such a scheme though.

TI uses a similar approach on their TI-89 and TI-92+ calculators with FLASH.
When a program or code is copied from flash to working memory, changed, then
copied back to flash it doesn't overwrite the old location, it finds the first
non-used location and writes it there.  The old location is marked used-but
empty.  When there aren't enough non-used locations, it performs a 'garbage
collection' which re-allocates some of the flash, and marks everything empty as
non-used.

-Adam

"Quitt, Walter" wrote:
>
> I've done this with other RTUs (Remote Terminal Units.)
> It can get a bit tricky loading and running code on units
> with different configurations.  You must allow for bad
> downloads and allow the old code to run again.  It can get
> tricky.  Utility customers get real pissed if a substation
> goes down because of a software screw up.
>
> GL,
> Walt...
>
> -----Original Message-----
> From: M. Adam Davis [mailto:adavis@UBASICS.COM]
> An even nicer advantage is being able to update the code remotely.