Saving Critical data, How to avoid mistake?

jaikumar · Joined: 15 Dec 2006 Posts: 109

Hi All,

I have code like this:

mdemuth · Joined: 16 Apr 2007 Posts: 71 Location: Stuttgart, Germany

One option is to append a checksum (e.g. CRC16) to your critical data.
The other idea is to add a flag "SavedOK". The SavedOK flag is erased before writing new critical data program. It is set (and saved) after successful write (and read back) your critical data.

Ttelmah · Joined: 11 Mar 2010 Posts: 19504

This is where having more than one copy becomes worthwhile.

You have a 'count' flag with the data.
Two copies.
Then when you go to write, find the _lowest_ count.
Write to the record with this, verify it, and _then_ update the count to one more than the count on the other set.

Reading, you look for the higher count, and read this.

If the write is interrupted, the 'count' won't be updated, so you get the older copy.

This is the concept used in 'journalled writing' (how file systems like NTFS work), with the directory entry always being updated as the 'last thing' done. So the new data is written and verified _before_ the directory updates to say 'data ready'. If the write is interrupted, the previous version is unchanged.

Obviously you can have checksums as well.

Best Wishes

dyeatman · Joined: 06 Sep 2003 Posts: 1933 Location: Norman, OK

Sense the power failure and have a large capacitor on the power supply.
This should give you plenty of time to get the value written before losing all
power.
_________________
Google and Forum Search are some of your best tools!!!!

temtronic · Posted: Fri Jun 28, 2013 6:18 am

another idea...

add an RTC like the DS1307 with a coin cell battery.
save a copy of your data to the RTC's internal RAM.

hth
jay

ezflyr · Joined: 25 Oct 2010 Posts: 1019 Location: Tewksbury, MA

Hey Jay,

Pssst, have a look at the code comments in the OP's first post Wink

John

temtronic · Posted: Fri Jun 28, 2013 8:13 am

Man I gotta get better bifocals!

Sounds like a better 'power failure' hardware scheme is in order.

10,000 mfd primary cap, 'loss of ac' ISR, maybe a supercap or battery backup scheme ?
Hard to believe a PIC with this couldn't xfer a few bytes via I2C to the DS1307 ( that I didn't see the first time...sigh).

All my remote energy systems have this hardware and I've never loss data so I 'assume' everyone else has 'robust' hardware.

jay

Ttelmah · Joined: 11 Mar 2010 Posts: 19504

I'd have to agree that whatever software strategy is used, the hardware _must_ be built to ensure that writes are always able to complete.
Power fail detection on the incoming rail, and enough capacitance to 'cover' the worst case write time. Many memories can become corrupted if power is removed in the middle of a write.
Good hardware design as a start.

Best Wishes

jaikumar · Joined: 15 Dec 2006 Posts: 109

Hi,

Thanks to everyone for your information.

I have had problems with large filter capacitor in the supply rail.
I found that on power off, If the supply does not go below 4 volt (on board brownout @ 4V) soon. then many errors pop up. for example relay getting on and off etc..

Has someone had similar problems..

Regards,
Jai.

Ttelmah · Joined: 11 Mar 2010 Posts: 19504

'Large', doesn't have to be that large.
It depends totally on your loads.

Key things are
1) Time. Actual size if not a measure here. If (for instance), writing a byte takes 1mSec, the loads on the rail correspond to 100mA, and the supply needs to maintain 4v, from an original 5v, then to write ten bytes, only needs:

10E-3 * 1v * 0.1A = 0.001F

= 1000uF

2) Detection. The earlier you can detect a failure, the less capacitance is needed. If (for instance), the supply is coming in through an AC rectifier, and generates 9v, that then feeds a 5v regulator, if you can detect a power fail on the _incoming_ rail, this can drop to perhaps 6.5v, without any degradation to the 5v rail at all. This links to:

3) Design. There are critical things that need to be remembered. For instance, if you have a standard 7805 regulator, and put significant capacitance on the output, then you should also have a reverse biased diode across the regulator to prevent it being damaged if the input rail drops faster than the output rail. Your comments about problems with relays, suggests you are relying on the the 5v rail as your detection point _wrong_. Brownout is a 'last ditch' recovery detection, when the supply has already dropped, and recovers. Power detection should be at the earliest possible point.

You need to actually think about the power supply design, before the code.

Best Wishes