Embedded Linux, Battery backed RAM or CF for Data Persistence

Hi all:

I need some suggestions and pointers regarding a design issue I'm
having. We are building an electronic bingo system (players use
terminals, instead of physical bingo cards).

The core system is being developed around a PC104 linux-based system
(debian). The system has a 128MB CF card on it that contains the OS
which is mounted read-only upon boot.

My question is; I need to provide some level of data persistence in the
event of a power failure. Something along the lines of storing the last
~100 or so 'plays', so that if the power would fail, the user could
resume at their last state.

I've thought about using another CF card strictly for data storage,
however this seems like overkill. Furthermore, I'm concerned about the
'failure rates' related to consecutive writes to CF media.

Typically, players will be making a mark on their bingo card every 10 -
15 seconds, so I need a medium that can:

(a) Deal with frequent updates; and
(b) Be available upon boot up in the event of power failure

I've heard of using battery-backed RAM / CMOS RAM / in these situations...
but I have no experience programming under these types of media.

Any help / pointers / discussion would be appreciated.

-Barry

...

Programming is simple. But building the hardware is the tricky part.
You have to make sure that the battery-backed RAM is isolated from the
main system when power starts to go down.

EEPROM would be a better choice. They need special programming
sequence to write to, unlikely to be corrupted by power failure.

If I were designing it, I would use a microcontroller with Flash &
EEPROM and a serial port as a data server. It would cost $5 to $10 to
build.

Add seperate partition on CF card, say 12MB.

12M/512 byte sector size = 24000 sectors.
Writing a sector every 10 seconds sequentially wraps every 3 days or so
(24 hour a day).
It's really hard to find flashes nowadays with endurances as low as 10000
writes.
So, 30000 days = around 80 years.
If the machine is used 8h/day, then 240 years.

>

Remember that CF cards can get internally corrupted and totally
inaccessible when power goes down while writing to them. Moreover wear
out effects (each sector can only be erased a certain number of times)
can hit.

So IMHO this is not a good idea at all. A physically accessible flash
chip with a flash file system ("FFS") is a better choice. Here only the
sector just written to gets corrupted when power goes down, FFS cares
for this, as it deals with wear-out effects by spreading data cyclically
on the complete area. (BTW it can't help with flash cards as that said
corruption is internally to them.)

Regarding wear out effects an even better choice might be a RAM with a
shaddow-flash, that automatically takes the data on power down. I just
head of a new generation of such devices. Same can be accessed with a
ram file system.

-Michael

>

Why not using a (some 1$) serial flash chip) I do not know about MTD
drivers (to make FFS work) for those, but as they are very common in the
embedded world, I guess such a thing should be available somewhere
(Google found a discussion here:
http://lists.infradead.org/pipermail/linux-mtd/2001-October/003496.html
)

-Michael

Michael Schnell schrieb:

even better:

http://lists.infradead.org/pipermail/linux-mtd/2001-October/003494.html

-Michael

Never seen this.

Yes, and after only 240 years.

> > Remember that CF cards can get internally corrupted and totally

But others have.

It has been discussed here many times (see the backlog). The FC
producers don't give any information on this so there is so guarantee
that it will not happen. You can't sell a device relying on that.

-Michael

Serial flash would be my second choice. But serial flash is still
flash, they are block accessable and subject to wear and tear. It
would not be much better than puting data in the CF flash. EEPROM is
byte accessable and should be 10x more write cycles than flash using
the same fab technology. That's my understanding a few years ago,
unless things have changed.

So you put a slightly larger capacitor on, and don't write if
the power won't last at least 100ms.

Actually, if it's a PC-like system, there may be a few bytes of user-
accessible "CMOS" memory.

Whatever cap he put on will be drained by the main system. A large cap
is for noise filtering, not for power fail protection.


He would need power fail detection (brown out detector) to notify the
processor and isolate the CF power rail from the main system on power failure.


Anyway, he is using PC104. He needs more than a few bytes.

Potentially then, you'r talking of a 10000uf 6.3V capacitor, and a diode.
Not exactly expensive.
Alternatively, say the PC104 system draws 5W.

If using a switched mode power supply, probably the easiest way to
do this is to upgrade the energy storage capacitor, to take the hold-up
from some 6ms to 100ms, and a mains failure detector.

....

Most PC104 boards have sockets for static ram or battery backed static
ram. These can often be set up as solid state disks. Failing that,
PC104 is expandable
http://www.arcom.com/embedded-pc-gx1.htm
http://www.embeddedsys.com/subpages/products/mpc456.shtml


Talk to your PC1004 supplier.

But large, I have not seen any 10Kuf cap. I have seen 1Kuf the size
of an AA battery. If you are using 10Kuf, rechargable battery might
be smaller and cheaper. However, it would take the space (height) of
at least two PC104 boards.


I have seen CF internal activities (from LED) for tens of seconds
after the
last write, while it is shuffing internal sector tables. 100ms is not
enough for engineering safety. For mission critical design (gaming
machine would qualify), I would put in at least 30 seconds after the
main processor received power fail notification. With all these
considerations, I still believe EEPROM to be cheaper and easier.

Actually not.
6800uf 6.3V, 23*16mm.


What LED?

I do note that (for example) sandisks industrial CF say that writes
will complete in 20ms.
"Unless reassignment occurs". Which isn't exactly helpfull.