Detecting Power faliure and saving to EEPROM.

Go To Last Post
31 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi!

I am working on a project where I am monitoring 12 events and simply keeping a count of each.

What I want to do is that, this count gets saved to eeprom. If I use EEPROM too often then I might run out of eeprom read/wr cycles!

So what I want to do is, write to EEPROM only if I see the power dying and maybe write to EEPROM every 15 minutes.

Do you guys have any idea how I can write to eeprom on power faliure detection? I can detect power faliure, but how do I "keep it on" just long enough to write 12-15 bytes of data to EEPROM?

Thanka ton!

Edit: I read this https://www.avrfreaks.net/index.p...

and that is where I got this idea., but cant understand how can I keep it running enough to write my state to eeprom. i.e. How to do this:
[Power faliure is easy to detect and you can save the machine state without any problems with a large capacitor on the input and output of the regulator.]

SG

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tell us more what´s unclear:
* Detect power failure?
* use of capacitor?
* write the software?
* something else?

Klaus
********************************
Look at: www.megausb.de (German)
********************************

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey,

Thanks for the quick reply.

Use of a capacitor is unclear.

I can detect power failure with ADC or Comparator, write code to read/write internal EEPROM, but cant seem to understand how to pump up cap so it can give me a few seconds of power.

Thanks.

SG

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I can detect power failure with ADC or Comparator, write code to read/write internal EEPROM, but cant seem to understand how to pump up cap so it can give me a few seconds of power.

The capacitor is charged all the time as long as power is available.
The "power_fail" should react as fast as possible and should trigger an interrupt.
Power down all unnecessary loads.
Usually some tens of ms should be enough.

example:
* detecting mains power failure is the earliest.
* detecting power failure by low_voltage of a capacitor in front of a regulator is second best.
* the difficultiest is power failure of avr_VCC itself.
but not impossible.
running an AVR with 5V you can detect power failure at a voltage level of 4.5V or even higher.
most of the AVRs will run down to VCC = 2.7V.
so there is 4.5V-2.7V=1.8V left.
with a load of 15mA and a capacitance of 1000uF you can run your AVR 120ms.
this should be enough to store some tens of bytes.
You can improve this by using power_saving within the AVR: put the AVR into IDLE state until each "write EEPROM byte" has finished.

Klaus
********************************
Look at: www.megausb.de (German)
********************************

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok,

I will put a resistor voltage divider on mains to detect power failure.

And is this how I should connect the cap?

Vout-------uC
|
=== cap
|
---
- Gnd

Such that, when Vout dies, my uC can draw power from the cap. Right?

Thanks a ton!

SG

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes.
You should already have CAPs on VCC and GND: 100nF close to each VCC pin and one global tantal.
Now the value of the tantal should be larger. Maybe an electrolytic one or even a goldcap may be necessary.

Klaus
********************************
Look at: www.megausb.de (German)
********************************

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

HMmm... perhaps something more like:

                              +---------+
                 D1           |   uC    |
                 |\ |  Vprot  |         |
Vreg  -----+-----| >|---+--+--+ Vcc     |
           |     |/ |   |  |  |         |
           |            |  +--+ Aref    |
           /           ---    |         |
           \ R1      C ---    |         |
           /            |     |         |
           |            |     |         |
           |           GND    |         |
           |                  |         |
           +------------------+ Ain     |
           |                  |         |
           /                  |         |
           \ R2               +---------+
           /
           |
          GND

You want to be sure that when Vreg drops that the capacitor isn't drained back into the regulator.

The down side is that you'll be running the processor at a diode drop below Vreg. Using a Shottky or germanium diode would keep the diode drop to less than 0.7V - there may be other solutions. (I've suggested Shottky diodes for this before and someone came up with a real good reason not to use it -- just can't remember the reason right now :? )

Note that running Vreg into Ain is a Bad Idea (tm), unless the diode drop is significantly less than 0.7V!

One other item: in the above solution, the ADC would be dedicated full-time to watching the power supply. This is perhaps not the best use of the ADC, AND the best rate you can get from the ADC is about 9K samples/sec. Another option would be to have Vreg run to a comparator external to the CPU (powered from Vprot) which can then condition a "Power OK" signal to an interrupt pin on the CPU. That way, all your CPU resources except one interrupt are now yours. A small comparator would be cheap to add, and a little signal conditioning would be easy and good to add. Don't want to respond to just any old glitch on the power supply, eh?

Have fun!

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

good circuit. simple and good solution.

Quote:
(I've suggested Shottky diodes for this before and someone came up with a real good reason not to use it -- just can't remember the reason right now)

My two reasons:
* they are more expensive than standard silicon diodes. Onthe other hand it´s only a few euro cent.
* the reverse current is much higher than with standard silicon diodes. true - especially with high temperature. On the other hand i use the BAT54(or -A, -S or -C...) I´ve tested the reverse current of some, it is much lower than 1 uA at room temperature. So it´s neglegible.

Quote:
in the above solution, the ADC would be dedicated full-time to watching the power supply.

You don´t have to use the ADC, just use the Analog Comparator and the internal reference as "early power fail".
--> no processing time.

Klaus
********************************
Look at: www.megausb.de (German)
********************************

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Quote:
in the above solution, the ADC would be dedicated full-time to watching the power supply.

You don´t have to use the ADC, just use the Analog Comparator and the internal reference as "early power fail".
--> no processing time.


Now, let's hold on here a second. (Well, a number of milliseconds anyway).

I don't know if there is a "typical" AVR power supply. The raw voltage could be anything from, say, mains AC to more modest raw DC levels like 24V or 12V or 9V or 5V nominal.

It is going to take a number of ms. to save the required bytes to EEPROM. My approach is to determine how many bytes of critical data there are, assume that worst-case each byte has to be written (not normally the case; high-order bytes are often unchanged and my compiler's primitives do a read-before-erase/write to save that), and then double that to be "safe". I test that by detecting my powerfail, then enter a loop that writes 1-2-3-etc. to the same EEPROM location. After the app dies when the brownout detector kicks in, I read back the EEPROM to see how many bytes were written. As expected, with 2ms write times and 50ms to 100ms of grace time several dozen bytes are "safe".

Now, on to the "trip". I don't like to trip too fast, to avoid tripping on very short glitches in the raw supply. E.g., if zero-cross detection is used than I don't want to trip on just one miss.

One of my "normal" ways with interrupt-driven ADC conversions running continually on all used channels is to use a simple rolling average of the ADC counts. This seems to work well for not false-triggering. In other cases, I turn the level into a yes/no boolean, and debounce with my other switches and such. Again, at least several ms. before I "trip".

The "raw" DC level, from AC or DC, has a sizable cap on it. It doesn't drop that fast anyway, and is almost always much higher than the 5V or 3V regulated of my AVR. 37V off 24VAC for example. Or maybe raw 24VDC. there is also a decent sized cap on the regulated Vcc. And brownout level is like 20% below normal Vcc anyway.

All in all, though it is a race, you don't need to be the hare. "Normal" sized caps will give you about 100ms before AVR brownout unless your app really sucks down the 12V or whatever. As mentioned, after trip and before saving critical info, shut off power suckers such as backlights and you should have all the time you need. Most apps have like 4 bytes or 8 bytes of critical info. No biggie.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey Lee, Stu and Klaus!

Thanks a ton guys for such an insight into this. I will try it out and let you guys know! :)

You guys rock!

@Klaus Cool, I will add the two caps.
@Lee Thats a very good way to approach the problem.
@Stu Thanks for the circuit

Thanks a ton.

SG

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
I don't know if there is a "typical" AVR power supply. The raw voltage could be anything from, say, mains AC to more modest raw DC levels like 24V or 12V or 9V or 5V nominal.
Sorry, my verbage did not go well with the picture. I was implying the "regulated" voltage into my circuit (Vreg, get it?) so the variability shouldn't be so much. On the other hand, watching the unregulated source would give far more warning.
theusch wrote:
One of my "normal" ways with interrupt-driven ADC conversions running continually on all used channels is to use a simple rolling average of the ADC counts.
Yup. And you're dedicating at least some of your ADC "bandwidth" to watching power. That's okay in most applications, but I was offering an approach that allowed the OP to watch the power AND use the ADC for something totally different.

BTW, I completely agree with qualifying the power supply "drop-out" - being too quick to cry wolf would be a problem!

Oh, and you're welcome Sidhant. :D

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

On the other hand, watching the unregulated source would give far more warning.

I wouldn't even TRY to race the regulated supply.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Backing to this subject...
I was looking for a way to saving to EEPROM before the power goes off.
You propouse two ways:

- ADC, i don't like to let the uC checking the ADC channel it will consume uC processing...

- Analog Comparator, good choice for me, because it generate an interrupt, letting the uC free to do others stuffs, but i'm already using the pins for Analog Comparator.

So need other aproach, why not use the INT pins?
So i make some tests and let me able to use INT on falling edge to detect the power going off.
Using a AC/DC transformer and when the power goes off, it goes off "slow". Using a network resistor before the regulator (my case lm7805) giving me about 3,5V (Power On) you are able to detect when the power is off and let at least 100ms for the AVR (osciloscope result).
3,5V?? Yes, once that Atmega162 high level is 0,6xVcc = 3V, so 3,5 is ok. Other thing, how close you let the network resistor close the Vcc less time you will have on AVR to save values on EEPROM.

Bruno

Regards,

Bruno Muswieck

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
ADC, i don't like to let the uC checking the ADC channel it will consume uC processing...

lol from here. Lessee--if I'm doing continuous conversions on all the used ADC channels anyway, and I run at my modest 57.6kHz ADC clock, then I get an ADC-complete interrupt after 13 ADC clocks or about every 225 microseconds. My ADC-complete ISR takes 34 clocks plus about 8 to get in and get out--42 clocks; say 6 microseconds at 7.3728Mhz. That's the ISR that takes a simple rolling average of each new reading, a few clocks are saved if you just store the latest reading. So my burden to do ALL used ADC channels continuously is less than 3% of an AVR running at a modest clock rate. If you are doing that, then one could say that adding the additional channel for powerfail is FREE--it takes NO additional CPU cycles but rather means that the conversion rate for each of the other channels is a bit slower. I've only found this to be a problem in a couple of apps where I do not/cannot disturb the timing when, say, waiting for an echo. But then I need to supress all my other ISRs also--USARTs, other timers, pin-change, etc.

Let's look at it the other way--when you are done doing all of your "stuff", and getting ready for another pass or whatever, or updating your display, or something else that takes a few hundred microseconds or more, you kick off the A/D conversion on the powerfail channel. That takes like a microsecond. when you get around to it the conversion is done and you peek at the results--another couple microseconds.

If you DO use a logic-level of some sort for power-loss detection, then you need lots more circuitry than I need for the A/D method in order to prevent any kind of a spike or noise from doing a false trigger, as well as to get the signal into the desired logic-level-trip range. You WILL get them in the real world.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lee, there are differents ways to sense the power failure, as you said, your way, using the ADC interrupt is better than the way that i was thinking to use the ADC to sense the power failure.

Quote:
If you DO use a logic-level of some sort for power-loss detection, then you need lots more circuitry than I need for the A/D method in order to prevent any kind of a spike or noise from doing a false trigger, as well as to get the signal into the desired logic-level-trip range.

You don't need to use a lots of circuity, just a resistor network and a zenner diode, even that you have some spikes or noise, the AVR will just save values on EEPROM (as sidhant wants). Other good thing is the time (about 100ms) that enable you to save values on EEPROM and do others "stuffs" if you want.

Bruno

Regards,

Bruno Muswieck

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I usually use a setup similar to Stus except I use the internal voltage ref with the comparator and I have diode and cap before a LDO Reg. which is where I sense power failure through a voltage divider. The input cap is normally 2X that of the output side.

I see people doing ascii art of circuits here, is there a program you use for this?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Backing to this topic...
Like i said using the INT pins could be used to detecting power going off. I was using this saving a float variable in eeprom, but when i need to save 3 float variables, it didn't work anymore..
So i need to go to the analog comparator... But, in my case i'm already using the analog comparator pins, so i just use a lm311 and connected the output to INT2 and i have enought time to same my 3 floats variables in eeprom.

Bruno

Regards,

Bruno Muswieck

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you watching the raw supply or the regulated supply? As I said earlier, I'd never try to race the regulated supply. And watching the raw supply, tripping at about 1/2 nominal usually, gives many, many milliseconds after the trip especially if you react and turn off power suckers such as backlights and LED displays.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm watching both... Using a comparator with both, when the raw supply goes under the regulated the comparator trigger. Both i'm using a resistor network.
Different paths for the same result...

Bruno

Regards,

Bruno Muswieck

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I solved a similar problem without external components.

I measure the internal band gap (1.1V) with VCC as reference.
Then if VCC drops below 4.5V I store the needed data to the EEPROM.
The brownout was set to 2.7V.

So the capacitor must be large enough to discharge from 4.5V not below 2.7V until all bytes are written.

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Using a comparator with both, when the raw supply goes under the regulated the comparator trigger.

No, don't do it that way. Know what your "typical" is for the raw supply. For a 5V regulator it might be 12 or 24 or like 37VDC (from a 24VAC bridge). Turn off the input power and watch the raw and regulated on a 'scope scanning slowly to get an idea of the die-down time. Whith decent-sized power supply caps, the power will need to be off for like 300ms (it depends) for the 12V in to drop to 9V--certainly a signal of power loss. You will have many more milliseconds to put your affairs in order. If your app can indeed watch the raw, the race becomes more of a stroll. Use the AC if you must, or a logic level. As I said earlier if I use 1% of AVR for ADC I don't care, but suit yourself. I can then watch for overload or "brown-out" conditions pulling down the raw, and/or calculate the raw (e.g., backlight run off the raw; various supply voltages could be used; adjust the backlight PWM to get approximately the same brightness with a wide variety of DC supply voltages) and/or error out--I don't want to run a 12V relay app with a 9V raw supply even though all your tests would say it is OK and the 5V regulator and the AVR are quite happy. With a 24VAC "control transformer" I can also back-calculate the "wall" VAC. This can be used to great advantage in certain industrial and commercial apps where performance depends on wall voltage. A well-used 1% of AVR CPU time, all-in-all. Oh, yeah, don't forget to be able to watch for a stable return to "good" power after a glitch.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've been there and tried all this - with no great success as I just couldn't run for long enough to save all I wanted to in the EEPROM before the power ran out.

In the end I just put a SPI-bus Ramtron FRAM into the unit and write all relevant values to it every time they change:
- the write time is effectively zero (it's just how fast you can "SPI-out" the control codes, addresses and data)
- with the ability to write to the same location 10^^12 times, you can write to the FRAM something like 2000 times per second for 15 years
- and the retention time of 8-10 years is probably long enough for most people

...and then noting that I had a FRAM in the circuit I started using it for datalogging :)

The cost is one /CS line, one pull up resistor (and I'm not completely convinced you need that), a small amount of real estate and about $3...and a new pair of glasses to be able to find it after I dropped it on the floor

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Peter, there is no problem of EEPROM Corruption?? Because you're working on 5 V and brownout is set to 2.7V.

Bruno

Regards,

Bruno Muswieck

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lee, sorry i didn't have see your post.
But thanks for your explanation.
My circuit is set to work with a regulated 12V AC/DC, so no concern about the variation.
But i was thinking, using the ADC could be the best choice, less external circuity and how you said it could be used with variation on the raw supply (9v.. 24V).

Bruno

Regards,

Bruno Muswieck

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MartinM57 wrote:
I've been there and tried all this - with no great success as I just couldn't run for long enough to save all I wanted to in the EEPROM before the power ran out.

In the end I just put a SPI-bus Ramtron FRAM into the unit and write all relevant values to it every time they change:
- the write time is effectively zero (it's just how fast you can "SPI-out" the control codes, addresses and data)
- with the ability to write to the same location 10^^12 times, you can write to the FRAM something like 2000 times per second for 15 years
- and the retention time of 8-10 years is probably long enough for most people

...and then noting that I had a FRAM in the circuit I started using it for datalogging :)

The cost is one /CS line, one pull up resistor (and I'm not completely convinced you need that), a small amount of real estate and about $3...and a new pair of glasses to be able to find it after I dropped it on the floor

I did something similar with FRAM on another project, but I had an interrupt firing every few seconds that would dump the whole content of SRAM to serial FRAM, and on bootup it would restore SRAM from FRAM.. Kinda like a state saver...

FRAM is defintiely a better choice than EEPROM in most situations... Can't wait till the capacities go up a bit, it'll replace flash too in time...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

brunomusw wrote:
Peter, there is no problem of EEPROM Corruption?? Because you're working on 5 V and brownout is set to 2.7V.

Bruno

No.

I use the ATtiny25 with 8MHz internal RC clock.

The ATtiny25 was specified for 0-10MHz @ 2.7-5.5V.

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This Ramtron FRAM is same as Atmel's DataFlash, right ?
Any particular reason to use FRAM instead of Dataflash ?

:idea:

won't it be nice if codevision had a "fram char a;" kind of facility ?
Compiler taking care of all the required background operations just like for EEPROM ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

This Ramtron FRAM is same as Atmel's DataFlash, right ?

Wrong. Dead wrong.
Quote:

won't it be nice if codevision had a "fram char a;" kind of facility ?

And it should magically apply to all Ramtron devices containing FRAM, regardless of size/density/address width; I2C/SPI/parallel, or other interface; or addressing layout?

Maybe it should have "gchar" as well to draw a character in any size and any language in any spot on any graphical LCD display regardless of the controller type and interface.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Quote:

And it should magically apply to all Ramtron devices containing FRAM, regardless of size/density/address width; I2C/SPI/parallel, or other interface; or addressing layout?
Lee

Come on Lee. Be reasonable. You can use a suitable #include :wink:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello folks! I know this is very old post, but i have the same problem and need your advise. What my application is doing, is switching some AC loads with relays and a triac to control induction motor,  I want to store the current state of relays on EEPROM. There are three sources of interrupts in my application:

1- Zero Crossing Interrupt.

2- Power failure detection interrupt.

3- Timer compare interrupt for firing Triac.

The user interface uses Atmel's Qtouch Library, as Atmel doesn't recommend any interrupt during charge measurement. 1 and 3 are somehow synchronized interrupts and can be handled safely. Number 2 interrupt is unpredictable and handling this is the main problem, QTouch library automatically disables interrupts during measurement (not too long- around 65 cycles per key). Polling method of detecting power failure may delay my touch responsiveness.

Any help will be appreciated.  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

but i have the same problem and need your advise.

I reviewed the thread, and do not have anything to add to my posts above.  #21 emphasizes watching the "raw".  #9 emphasizes finding "the number".

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.