Hi all,

I've a application working that uses a RTCC on the I2C bus, it checks the time on a regular basis, it runs from the mains and I would like to code in some protection against power cuts.

I've had a quick read through the data sheet for the 18f2523 I'm using and the HLVD (high/low voltage detection) module looks just the job?

Basicaly I would like the PIC to save the current time in the internal eeprom before the power goes! Has anyone got experience using the HLVD module to do a task like this? Are then any pits I might fall in?! Or is there a better way?

I did consider a battery backup RTCC but its better if my application starts up where it left off when the power went time wise.

Thanks Geoff

 

You will want to detect the power fail early, waiting for the Vcc to fall leaves little time for much- can you directly sense mains failure? A zero crossing detector works good for early warning for mains fail.

 

Split the DC supply in your device and section off the portion that supplies the PIC. Give this a large cap so it is still a perfectly good and valid voltage some time after the rest has died.

Note there may be no "rest" of the device so give that a cap and large resistor so when power goes this dies fast.

Then take 1 standard logic I/O pin from your micro and use that to monitor the other power section as a power fail indicator. Interrupt pins are surprisingly useful here.

 

Doesn't your RTCC have battery backup? That is standard, and even a 3v button cell will run the real time clock device for a long time when mains is absent.

You can buy a RTC module from ebay for a couple of dollars, complete with battery holder for the button cell.

And if you are not going to use the battery backup to keep the clock running, why bother with an external RTCC? If the clock stops when the power fails, why not just use the PIC to generate a real time clock in software?

 

Thanks for the replies, I was hoping I could use a bit of code to get around this,?! The pcb is already made .

I've been thinking about it, if I pop my osciliscope on the 5v power rail I could see how long it takes to 'die', the time is already stored in three ram files as the programme runs. If I set the hvld to trigger at say 4.5v there might be time to interrupt and save three files in eeprom? I shall try to do it today!

I decided battery backup wouldn't be suitable as its best time is 'stopped' while the power is out. I then know the powers been out and can reset the clock at a suitable time.

My pic is already pretty busy, I'm using two of the timers at the mo with a interrupt on one some of the time, I thought about trying to programme it in, a better proggrammer than me would be able to do it I expect! From my point of view the rtcc was 90 pence well spent!

Cheers Geoff

 

The problem using EEPROM is it takes several milliseconds to complete a write cycle, and if the power goes down during the write you may get corrupted data.

I'd say how long this takes but the PIC18f2523data sheet is quite abbreviated and the page doesn't like to any other docs.

 

Thanks for the reply,
I was worried about a corrupted eeprom write, I've been thinking about it, would it be better to turn things around and use the hvld moudle to stop a write to eeprom if it detects a low voltage? I could use one byte to represent the time, 15mins accuracy is acceptable if it has to restart after a power down?
Cheers Geoff

 

If you can accept 15 minutes resolution of the stored time, why not just write the time to EEPROM every 15 minutes?

Modern PICs have the ability to write to EEPROM about 1 million times (if I remember right), so that gives you about 28 years before the EEPROM gets too worn out.

If that bothers you, you can keep multiple EEPROM bytes for the hours:mins storage, and rotate them in use (giving many times longer than 28 years before it gets worn out).

 

Thanks for the reply,
I was worried about a corrupted eeprom write, I've been thinking about it, would it be better to turn things around and use the hvld moudle to stop a write to eeprom if it detects a low voltage? I could use one byte to represent the time, 15mins accuracy is acceptable if it has to restart after a power down?
Cheers Geoff

That had occurred to me too...the thing is if the power fails just as the write is taking place. Bam, corrupt data. Plus EEPROM has a finite number of write cycles, something around 10K. With a write every 15 minutes you'll hit that limit in about 4 months.

Someone has an EEPROM killer webcam once, counting how many correct write cycles something was doing.

Apparently that's a popular thing to do: http://www.youtube.com/watch?v=t8X0zip7TvU

 

The 18F2523 datasheet clearly states "1,000,000 erase/write cycles, data EEPROM". It's been a LOT of years since the EEPROMS only did 10k endurance!

And like I said, hours and minutes can be 1 byte each, and since the EEPROM has 256 bytes you can store multiple copies of hours:mins, for error checking and/or for increasing the total number of writes to 1 million * X rotations.

As an example, if you write the hours:mins every 15 mins, to 11 different storage pairs that only takes 22 bytes of the 256 byte EEPROM. Then when reading the time back, you can error-correct by checking those 11 records and go with the most common value within the 11 records (which will be accurate, even if a power down during writing damaged one or two records).

Also if you are happy with 15 minute resolution you can store both hours:mins in ONE byte, as hours 0-23 will fit fine in 5 bits, and mins 0,15,30,45 only needs 2 bits.

That gives you the possibility of 256 stored records if you really want reliability.

 

Thanks for the suggestions!
I think I will probably us the RB's suggestion of writing to eeprom pairs and then error checking on power up?

I guess the theory being if on power up any of the pairs don't match you can identify when any write error may have occured? You would then use the pair before to set the time? So at the worst the time could be 15mins behind when the power went? This is acceptable for my application, its more important its not ahead!

I realise this is belt and braces, the chances of a power down catching a eeprom write are slim! But you just know it will happen !

Cheers Geoff

 

If you write a large number of copies every 15 minutes, let's say 11 copies (writing one copy each second) the power down can only kill one or maybe two copies.

Error correction is as easy as finding the most common value in those 11 copies which is why you use an odd number.

In the worst case situation the error will occur during the start of the next write, so the most common value will be from 15 minutes before (max error 15 mins).

If the write error occurs near the end of the write, the most common value will be the new value.

Alternatively, you could write to one EEPROM location every minute, using 60 locations. On power up you scan through those 60 locations and find the last valid time. That gives better resolution (down to a couple of minutes) AND only writes to each location once per 60mins, so you get very long EEPROM life.

 

Thanks for the suggestions,

I'm scribbling down flow chats and thinking at the moment! I'm going to use your many copies method and am going for ten min intervals, many because its easy! As you said 0-23 hrs needs 5 bits, so that gives me 3 left to do 0-10.

I was thinking about the error correction, I was going with the suggestion of 11 copies, there's probably something I've missed but doesn't a odd number of copies have a middle? ie with 11 copies if it goes down on number 6 (slim chance I know) there could be 5 copies of the 'new' time and 5 of the 'old' with one anomoly. I was going to compare each file to the next and run a accumulator for the number of matching files. If they all match the accumulator would get to 11 and so use the first file, when it finds a missmatch it would stop checking, less than 6 use the last file, more than 6 use the first? As I write this I think I've answered my own question?

Is this how you would go about it?

Cheers Geoff

Cheers Geoff

 

Yeah I think you have it down pretty good.

Either you can use the most common value as the "correct" value, or if there are two equally common values (say 5 of one, 5 of the other) that situation can only occur if the two sets are 10 mins apart.

So if that happens, I would just go with the highest time out of the two options (that will be 10 minutes after the other time).