> Which is EXACTLY why we DON'T rely on EEPROM; we use FRAM!  Ferroelectric
> RAM (there's nothing magnetic about it, folks, the ``ferro'' moniker is
> historical accident) is batteryless nonvolatile RAM which writes and reads
> as fast and low power as SRAM.  Inevitably (even with a contacted card in
> a slot) you still have to cope with abrupt ``tear-out'' transaction
> interruption, but when you can complete a transaction in 100 msec, it
> becomes a rare event, not a common one.  (And one that any competent
> database-aware computer scientist knows how to handle reliably.)

Unfortunately, Ramtron's two-wire FRAM products are more succeptible than
two-wire EEPROMs to a particular type of glitch that has caused much
annoyance: if the clock wire starts thrashing during a the "write" part of
a transaction, data in the device may be erased (WILL be erased if the
clock thrashes enough times).  Given that all read operations must be
preceded by a "write" to set the address, it's possible for this to happen
even if no code in the processor deliberately tries to write the data in
the chip.

The problem with FRAMs that makes them prone to this failure is that there
is no checking to ensure that a command is terminated properly.  On many
of the EEPROM devices, failure to receive a proper "stop" condition
following a byte-write or page-write command will result in the entire
command being ignored.  Since it's unlikely that a flailing CPU would
generate a valid stop condition at just the right time, the glitched
command would most likely not disrupt anything.  Unfortunately, the FRAM
has no "page-write" structure; every byte received is written to the chip
immediately.  Since it is perfectly legal for the CPU to hold the data
line low continuously while sending zero bytes(*) the FRAM will write all
the zeroes it receives to memory without realizing anything is wrong.  By
the time the FRAM receives an improper start/stop sequence, bad data will
have already been written and undoing the command will be impossible.

(*) The FRAM could, I suppose, look for the CPU to let the data line float
    after clocking out the LSB of a byte.  I think normal I2C behavior,
    however, suggests that the FRAM should assert its data line as soon as
    it sees the clock go low following the LSB; consequently it would have
    no way of knowing that the CPU was also holding it low.  Perhaps it
    could let the line float and pull it low once it's been observed to
    float, but this would introduce some additional timing complexities
    and is not, as far as I recall, part of the I2C specification.

Unless/until Ramtron remedies this defect, I would not recommend the use
of an FRAM in applications where reliability is important(**).

(**) In the particular application which failed, unexpected disconnection
     of CPU power would have about a 0.5% chance of disrupting memory
     contents.  Not terribly common, but if you plugged/unplugged the
     thing a lot it would fail.  Although the addition of a CPU/power
     monitor chip solved the problem, I'm still leery of the device for
     having that failure mode.

(***) This particular project used an 8x51-style processor, with the
      FRAM's data tied to P3.6; the stuff on port 0 happened to produce
      a "MOVX A,@R1" opcode.  Those familiar with the 8x51 can probably
      see what this means.  For those unfamiliar with the 8x51, it will
      attempt to fetch code from any address; addresses inside the chip
      are mapped internally.  For those outside the chip, it outputs the
      address on some port pins and then tries to read the data from port
      0.  The "MOVX A,@R1" command, as part of its functioning, briefly
      asserts P3.6 [which doubles as /RD for external memory].  Since P0
      always has the "MOVX A,@R1" code on it, the 8x51 will do nothing but
      flail P3.6 repeatedly.  Oops...

Anyway, I'm sure many people have used FRAMs without problem, but given
the above experience I'm a bit reluctant to do so... after all, there's
never "just one" bug lurking in the corner...