You can atually extend what you have written.
If you checksum the code to declare it good you have
a good chance of being able to execute the new code.
Use the watchdog to reexecute the old code if the new
code crashes.  Once you feel good about the new code,
then the old code space can be written over.  Just
don't write over that all important decision making
code thatis typically at the beginning.  This is
an OK schema.  Used something similiar.  It is not
intended that you do this over and over as the code
shouldn't change that often.  Data logging can always
be done to some external memory like an SPI part.
Using 64K bit 25LC640s right now.  Bank select if you
need more.  I keep a checksum of the memory around
and check it every now and then.  If you are really
concerned you can also do real time memory checking
a byte per main loop.

Back to it...-W

-----Original Message-----
From: M. Adam Davis [mailto:adavis@UBASICS.COM]
Sent: Thursday, March 09, 2000 1:28 PM
To: PICLIST@MITVMA.MIT.EDU
Subject: Re: ROMzap


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.