Re: How to protect DoC 2000 from power fail?

[Charles Manning <manningc2@actrix.gen.nz>]

On Tue, 19 Mar 2002 01:10, David Woodhouse wrote:
> wil@wtms.nl said:
> >  I am looking for some rigid means of power fail protection for a DoC
> > 2000 based embedded system. From what I have read so far I understand
> > that almost any brand of journalling file system should do well but,
> > then again, those readings also mention raw FLASH and not DoC, in
> > other words, I think I am lost. Would someone be so kind to enlighten
> > me?
>[snip]
> CompactFlash also uses such a pseudo-filesystem, but does it completely
> internally. Electrically, it behaves just like an IDE drive. Reportedly CF
> devices are very bad w.r.t to power failure and wear levelling though, but
> the concept is similar.


CF should have at least 15ms of good power after the last write. This is 
required to complete the write internally.

Dunno what goes on in a DOC, but basically it needs some power to complete 
the last write. Dunno how clever it is at fixing itself. Maybe read the 
msystems www. They have some good application notes - maybe one covers these 
issues.

Hard disks get around the power issue by using the inertia of the spinning 
disk to generate sufficient power (well that's what I believe anyway). No 
such luxury with flash. You either need a resiliant file system - preferably 
one designed specifically for flash - or some way to guarantee power to 
complete a shutdown.

I've done both in various situations.

One way to guarantee good power into the FS is to do something like follows:
* Have the hardware report an early warning of imminent power failure. eg. if 
you have a two-stage switchmode, detecting the regulation loss flag on the 
first stage might do the job.
* Protect all critical FS entry points with power checks:
   write_func()
   {
      while(power is bad) { /* spin */}
      rest of function
   }
*  If you've done this right, you never go into a critical section with bad 
power. If power turns bad during the run of the function then hopefully the 
residual energy in the rail etc will be enough to power the system through 
the rest of the function call.

This can work well if your hardware supports this kind of detection and has 
sufficient residual energy. Dunno how long you need for a DOC, but I would 
hunch that 100ms would be enough.


> If you want to be able to write to it then the correct solution, IMO, is to
> write a _real_ file system which operates on flash directly instead of
> operating on a block device. Build in the wear levelling, journalling, etc.

Too right!

-- Charles