piclist 1997\08\23\023356a >
Thread: Smart cards
face BY : John Payson email (remove spam text)

> 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...
<199708230633.BAA22381@Kitten.mcs.com> 7BIT

See also: www.piclist.com/techref/index.htm?key=smart+cards
Reply You must be a member of the piclist mailing list (not only a www.piclist.com member) to post to the piclist. This form requires JavaScript and a browser/email client that can handle form mailto: posts.
Subject (change) Smart cards

month overview.

new search...