Internal VCC measurement to trigger EEPROM write at shutdown

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

I came across some techniques for measuring the internal Vcc without the need for a precious pin:

http://provideyourown.com/2012/s...

I was wondering if anyone had tried using this measurement to trigger an EEPROM write during shutdown (to save active parameters). Probably a dozen bytes or so.

I'm running at 5V, and could probably set brownout to 2.7V to allow some time (or even 1.8V?) I can add a cap, within reason, to prop up the VCC as needed, and obviously switch off LED's and other things that could consume power.

I'm just not sure if this technique is accurate/reliable enough to ensure safe eeprom storage; I would have expected this to be a common method if it was.

Currently designing for ATMega88.

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

Quote:

I'm just not sure if this technique is accurate/reliable enough to ensure safe eeprom storage; I would have expected this to be a common method if it was.

Currently designing for ATMega88.


Where does the 5V come from? In order to race shutdown, you want to monitor for power loss as far up the power chain as practical.

My speculation would be that monitoring a drop on the 5V might be too late to do much useful. Remember that it takes a couple milliseconds per byte. You can cut it in half with a pre-erased section.

https://www.avrfreaks.net/index.p... and entire thread
https://www.avrfreaks.net/index.p...
https://www.avrfreaks.net/index.p...
https://www.avrfreaks.net/index.p...
https://www.avrfreaks.net/index.p...

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

Thanks.

The 5V is coming from a buck (24V), possibly a regulator. Of course the safest design is to monitor the 24V and trigger from that, but it requires a pin. I was hoping that for a dozen bytes of EEPROM I'd be able to get away with the 5V-2.7V decay time, and not consume a precious pin.

From the threads it does sound like this has been done:

https://www.avrfreaks.net/index.p...

... but it's unclear how reliable it was, or how much capacitance they needed. It doesn't seem to be done often though.

Last Edited: Wed. Jan 2, 2013 - 04:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I was hoping that for a dozen bytes of EEPROM I'd be able to get away with the 5V-2.7V decay time.

Well, then you need to do what I described in the links: Find out your "number".

I'll re-iterate that it IMO will be tough once the 5V drops enough to be a valid trip. It depends a lot on the app draw, how much storage of the 5V, and similar.

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

IIRC not every AVR model supports erase-only. I'm too lazy to find out if this applies to the m88.

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

Yep, I was hoping to draw on others' experiences first before doing this kind of experiment. I do have control of the 5V cap, and the app needs to do nothing but write EEPROM when VCC starts falling.

But I think if it were easy and reliable it would be more commonly done.

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

Quote:

IIRC not every AVR model supports erase-only. I'm too lazy to find out if this applies to the m88.

LOL--so much for >>that<< New Year's resolution, eh?

The Mega88 family is where I first noticed the EEPROM erase-only feature. I did open a rev. B "preliminary" datasheet from 2004 and the feature is listed there.

I don't know if this is the first AVR model/family with the feature, or not. Mega640 family and Mega406 (a specialty model) have it in 2005 datasheets. Perhaps AT90PWM2/3 were a hair earlier?

Does it matter? :twisted:

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

Tiny13 and Tiny2313 datasheet versions dated 2003 have the feature. All models introduced after that?

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

You could also back up Vcc at a low but operational voltage using a battery and series diode. The diode would prevent charging of the battery from Vcc (actually there would be some leakage so a small coin cell might need a 10 megohm shunt to keep it from overcharging). A configuration I have used is one LiFePO4 cell or two alkaline cells kept at 3.2 volts by three silicon diode drops from USB power, which then backs up the MCU at 3.0 volts through a Schottky drop.

A large capacitor connected to the 3.2 volt point of a high impedance resistive divider would work similarly, beginning to supply power when the external supply drops to 3 volts.

Measuring the bandgap using Vcc gives consistent results and is relatively insensitive to temperature, but does need one-time calibration for better than 200 mv accuracy. If you use a known Vcc during programming the program can store the calibration factor in EEPROM during the first startup.

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

Thanks DAK. I could calibrate on startup with a known supply.

If it comes to a battery and such it's worth using up a pin, or at least a big cap. I'll have to experiment as suggested and see how much I can write reliably, and how much current doing so draws. Then I can calc the size cap needed and see if it's at all reasonable.

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

I just did a simple test - wrote 0x00 and then 0xff to all 64 EEPROM locations, repeating a few times for stability, and measured current as approx 16mA. (I used the eeprom_write_byte() routine.)

Back of the envelope -

Assuming constant current draw, t=C(V0-V1)/I

going from 5V to 2.7V, t=2.3C/I

According to others here, it's about 8.5ms/byte. So for 12 bytes, that's approx 100ms.

This calculates to a 700uF cap. Big, but not ridiculous. 1000uF/6.3V is around $0.10 on Digikey.

Unless I missed something this looks viable, at least enough to prototype.

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

Quote:

Assuming constant current draw...

As I said in one of the links earlier, y'all can calculate amps and coulombs and faradays and such. But the important thing is "the number". How many bytes can you write before the BOD kicks in? Then I cut it in half for the "safe" number.

So I ensure that an area of EEPROM has all 0x0ff values in it--to force the erase/write to be done. Then when the power loss trip is detected, start writing 0x01, 0x02, ... to successive bytes in the buffer until the BOD puts you into reset.

Then use your ISP to read back the EEPROM and see how many bytes are successfully written. Repeat. Test varying conditions if applicable. The result is "the number". It is either satisfactory--or not.

Quote:

According to others here, it's about 8.5ms/byte.

You need a new envelope. What does the datasheet say about EEPROM erase/write times? What does it say about write-only?

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

Well, part of this was determining a "reasonable" capacitor size to start with, which affects BOD time, and whether this seemed viable. So far it looks likely.

According to the datasheet (p.300) erase wait time (for a delay) is 9.0ms, and write is 3.6ms. On p.30 (table 8-1) it says 3.4ms total for an erase/write cycle. (atmega88)

I could conceivably pre-erase any EEPROM locations where a parameter has been changed at my "leisure", since I know it'll need to be written at powerdown (unless it was set back to what it was). If I understand the datasheet correctly (still new at this) it looks like I could estimate 1.8ms per byte.

Looking good so far, especially if I use ~1000uF, but certainly running your test is warranted.

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

Quote:

According to the datasheet (p.300) erase wait time (for a delay) is 9.0ms

Huh? What version (of the datasheet) is this? (as a quick guess, it might be page-erase during ISP--nothing to do with the topic being discussed)

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

9.0ms is twd_erase not twd_eeprom in any case.

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

You're right, p.300 is for programming.

So isn't the correct value the one on table 8-1? This makes the times even shorter; 3.4ms for erase/write, 1.8ms for write only. 8-2 also indicates 3.3ms "typical".

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

Just wanted to follow up with this, in case someone else was looking for an answer.

I experimented with a capacitor connected through a diode (0.3V Schottky). 5V supply, so full Vcc was 4.7V. I set the brownout to 1.8V, and had the ADC measure the pre-diode Vcc (polled), and the EEPROM write was triggered at ~4.2V. This provided about 2.4V of droop before the brownout stopped the chip. The device is an ATMega328.

When the EEPROM write was triggered, it just looped a write (using eeprom_write_byte()).

For 220uF, I got between 8-12 bytes written, and for 100uF, between 4-6. I was hoping to write 4 bytes maximum on power loss, so 220uF fits the bill with a pretty safe buffer I'd think.

Additional tweaking can undoubtedly improve number of bytes written, such as using a lower-drop diode (or higher supply voltage), or reducing the AVR's power draw somehow.

Hope this data is helpful for someone else doing this.

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

To save power, you can use the EEPROM ready interrupt and put the AVR into idle mode during write.

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

Good call, thanks.

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

jrs454 wrote:
Just wanted to follow up with this, in case someone else was looking for an answer.
Always a good idea. It's nice to hear if something actually worked or not. :)

jrs454 wrote:
For 220uF, I got between 8-12 bytes written, and for 100uF, between 4-6. I was hoping to write 4 bytes maximum on power loss, so 220uF fits the bill with a pretty safe buffer I'd think.
I agree that if you got 8 to 12, counting on 4 is reasonably safe. You might check the specs of the capacitor you're using... some electrolytics can have crazy tolerances, like -20% and +80%. Normally tolerances this wide only show up on the big "soup cans" you would use on a power supply, but it's good to check. I Googled up some 220 uF 6.3 V tantalums and even those have a tolerance of +/- 20%. If you lucked out with a +20% one, and production ends up with the -20% one, though... :shock: Unfortunately, tools to measure capacitance are not as common; some multimeters have a "cap test" function.

If your widget has to operate over a temperature range, you might also check cold and hot. The power draw and maybe the capacitance will vary a small amount over temperature.

I hope this helps!