Peter L. Peres wrote:
>
> On Fri, 11 Sep 1998, Joe McCauley wrote:
>
> > Does anyone know how the e2prom fails if wou continously write to the same
> > bytes?
> > Do the bytes being written to not work any more or is the entire e2prom
> > wrecked?
>
> Bits get stuck of become flakey. They get flakey before they get stuck for
> which reason using a CRC or hash on the contents of a saved block is
> highly recommended if it is to survive the end-of-life test. A succeded
> write near end of life is not a guarantee for read back in 2 hours or so.
> The rest of the device keeps working as before but I have seen the Idd
> current increase on some devices that were destruction-tested when the
> flakey bit problem appeared.
>
> You can devise a small program to run a cheap 93C46 to destruction on 2-3
> words in a reasonably short time and find out. (say 1M writes x 2 msec
> write + 2 msec other duties = 4000 seconds). I find running this kind of
> test very confidence-boosting. Obviously the successive writes use
> complemented bit patterns (5555h/AAAAh f.ex.). Provide a chip protector
> fuse in the Vdd to the device TBT just in case (I never blew one).
>
> Peter

  I've been thinking about this;  On one project, I am using the Atmel
AT45D041 4 megabit (1/2 megabyte) flash RAM, it's about $10 in singles.

  This chip uses several lines for control purposes, it's not a 1-wire
interface, takes more like 7 or 8;  But, it has 2048 pages of 264 bytes
per page, and has 2 scratch RAM pages inside.  10 MBit/sec serial clock
rate so it's fairly fast to pass data to/from.  Room for a checksum if
desired <G>  (The reset can be tied to ~MClr, as a thought.)

  The thought comes to me, that you could use a smaller Atmel part (see
http://www.atmel.com/atmel/products/select15.htm for options) such as
their AT45D011 1 Megabit (512 pages, 264 bytes/page, only 1 RAM buffer
here though) part, keep a background task writing data to the scratch
RAM buffer occasionally, and only write on through to the Flash on a
power-down occuring (7 mS typical per page, the 2.7V part data sheet
says.  SOIC-8 or TSSOP-14 or PLCC-32 part, Marshall has the AT45D021 for
$5ish qty. 1, in stock, min buy 32, FWIW.)

  If you set the chip up as a "ring buffer" with a few "0xFF" pages as a
terminator, then reading in the whole chip circularly until you found a
page of valid data followed by a page of all FF's would keep the chip's
life long, and should allow a good startup reliably.  Just write a "FF"
page on valid data load, if there are not two there already, to blank
the oldest data present.  (i.e. always keep a spare fence there, just in
case.  Move fences during startup so there're three, maybe, to make sure
you don't run out!)

  quick pseudo-code:

  index = 0;         //  Which Flash page to load.
  Good = False;      //  Found good checksummed data page.
  Done = False;      //  Found good FF terminator.
  SecondPass=False;  //  (We needed to loop around for a second pass -
                     //  case where last data page IS the good data &
FFs
                     //  are in first cell.
  While ((not Good) or (not Done)) {
    GoodLoad = load_flash_page(index);  // Test checksum for the page!
    if (page_all_FFs()) {
      if (Good)
        Done = True;  //  We found a good page followed by terminator.
                      //  Jump out of the While loop;
                      //  Fall through if the first page is all FF's.
    } else            //  Else non-FF; test:
    if GoodLoad {     // don't "pay for" an invalid page!
      Keep_Latest_Page();  // This page may be the latest greatest.
      Good = True;         //  Keep it for now.
    }
    index++;
    if (index > max_index) {
      index = 0;
      SecondPass = True;
    } else
      if (SecondPass and index > 5)
        break;  //  Part's all FFs.  Don't keep looping forever, exit
                //  with Done = Good = False.
  }

  Something like that anyways <G>  That's "Quick Dirty HackWare", I
don't guarantee it's perfect.  Don't use it for life-support without
reworking it! <G>