In one of our application we need to log the data for at least 30 min there is a possibility of power failure.so is it possible to resume data logging after power failure?After power up it should log the data from where it stopped logging before power failure(Without overwriting previous data).
Thank you in advance, Regards
--------------------------------------- Posted through
if you start with the flash erased (all 0xFF), you can simply read forward until you reach 0xFF (for as many bytes as you think will not normally occur in your recorded data), then restart recording at that point.
The other alternative is to write a specific location with the last used storage location in flash. However, that can add a lot of wear to that flash sector.
Another alternative is to use something like SPI FRAM to hold the last written location---it can be written quickly for a long time without the wear symptoms of flash, but is non-volatile.
None of these techniques are really robust in the face of power failure----which might occur at a time which messes up a flash write. The robust solution is to have a backup battery than will power the system through an orderly shutdown when it senses a failure of the main power. A diode and supercap might be sufficient for that.a
I think we need to know how big the flash memory is and what the interface (and the speed of that interface) is. Is it onboard flash, or external (ie: USB interface) ?
What length of recovery time is acceptable after power up ?
Does the flash memory have a filesystem on it, or is it been accessed as a sequence of raw data sectors ?
If the flash is of reasonable size, and assuming it's on a relatively slow but randomly accessible interface, then a binary search approach would be more efficient than a sequential read through the flash. This does still assume that the flash was erased before use and you are not going to see more than a certain number of contiguous 0xff characters in your data.
Or alternatively, a number of these index sectors could be defined in flash, say every 16384 sectors for example (reduce or increase distance between index sectors as required), and the last used storage location could be written along with a monotonically increasing timestamp to the next index location in the sequence.
This would allow the recovery routine to quickly find the most recently written index sector but this assumes the flash does not have a filesystem on it however.
I firmly agree with this as been the preferred approach, but you may still wish to implement a recovery procedure on top of this in case the battery backup fails.
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world