Battery backed RAM or CF for Data Persistence

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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

Re: Battery backed RAM or CF for Data Persistence
...
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

Re: Battery backed RAM or CF for Data Persistence
Quoted text here. Click to load it

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

Re: Battery backed RAM or CF for Data Persistence
Michael Schnell schrieb:
Quoted text here. Click to load it

even better:

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

-Michael

Re: Battery backed RAM or CF for Data Persistence
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

Re: Battery backed RAM or CF for Data Persistence
Quoted text here. Click to load it

Add seperate partition on CF card, say 12MB.
Quoted text here. Click to load it

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.
Quoted text here. Click to load it

Re: Battery backed RAM or CF for Data Persistence
Quoted text here. Click to load it

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

Re: Battery backed RAM or CF for Data Persistence
Quoted text here. Click to load it

Never seen this.
Quoted text here. Click to load it

Yes, and after only 240 years.
Quoted text here. Click to load it

Re: Battery backed RAM or CF for Data Persistence
Quoted text here. Click to load it

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

Re: Battery backed RAM or CF for Data Persistence
Quoted text here. Click to load it

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.

Re: Battery backed RAM or CF for Data Persistence
Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Re: Battery backed RAM or CF for Data Persistence
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

Re: Battery backed RAM or CF for Data Persistence
Quoted text here. Click to load it
failure.
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

Re: Battery backed RAM or CF for Data Persistence
Quoted text here. Click to load it
failure.
Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.

Re: Battery backed RAM or CF for Data Persistence
Quoted text here. Click to load it

There are mainly two failure possibilities during a power down if a
write is active:
1. between CPU and CF
2. in the CF

1. This is depending on the file system. In the worst case you have a
fat file system and re-write a file which needs new more sectors. In
that case the hole fat table is corrupt and the disk no longer
accessible. A way to minimize that is to not change the file size, in
that case you just have a corrupted file. With an mirror file you can
handle that. There are other file systems which protect you from that
(ext3, etc.). That is a general problem, you will have it with hard
disks as well. But hard disks are faster and it's less likely to hit a
write procedure.

2. Problem of the CF. They have an own processor inside which handle
the sector utilisation ratio etc. . If this logic has an uncontrolled
shutdown it can loos information's. There are no information's about
what's inside... depending on the marked the price is more important
than the security. Some CF brands have industrial versions which have
this problem solved (more expensive, more secure)

I hope this helps a little bit in making your system more secure.
Chris

RE: Battery backed RAM or CF for Data Persistence
Quoted text here. Click to load it

Can you supply a link ?

-Michael





Re: Battery backed RAM or CF for Data Persistence
Hi Michael

There are some good links:

CompactFlash Association, http://www.compactflash.org

Application Note: ‘Optimisation of CF Host Operation', SanDisk
(AppNoteCFHostv1.0.pdf, Document No. 80-36-00233),
http://www.sandisk.com

SanDisk Industrial Grade ATA –CompactFlash, PC Card and FlashDrive-
Manual, Document No. 80-36-00208, http://www.sandisk.com

Man page for fs, http://www.doc.ic.ac.uk/lab/labman/lookup-man.cgi?fs (5)

File Systems (FAT, HTPFS, NTFS), http://www.yale.edu/pclt/BOOT/IFS.HTM

Transaction-Save FAT File System, http://msdn.microsoft.com

Re: Battery backed RAM or CF for Data Persistence
Thanks, I'll take a look.

-Michael

Re: Battery backed RAM or CF for Data Persistence
I don't find a spec about a max time for a write to be completed
_when_reassignment_ occurs_.


Ian quoted in another post:

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

-Michael

Re: Battery backed RAM or CF for Data Persistence
Quoted text here. Click to load it
....

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.

Site Timeline