7

I am designing an energy meter for electricity billing purposes by converting an analogue energy meter and counting the number of pulses given by the analogue meter's LED. Since power may be cut off any time, the number of pulses has to be stored in non-volatile memory. I saw the data sheets of Atmel EEPROM AT24C0X and inbuilt EEPROMS of ATmega328 and PIC16F877A, and found all have READ/WRITE endurance of maximum 1000000.

In this context, how is the problem of EEPROM life endurance tackled in commercial energy meters?

JYelton
  • 32,302
  • 33
  • 134
  • 249
Debidutta Pattanaik
  • 119
  • 11
  • 2
    couldn't you use some other sort of sram? http://datasheets.maximintegrated.com/en/ds/DS1350W.pdf boasts unlimited read/write cycles and 10 years retention... of course there are simpler chips, that use spi/other serial connections with very small pin counts – Grady Player Sep 14 '14 at 15:58
  • 1
    [EEPROM Wear Leveling](http://electronics.stackexchange.com/questions/60342/wear-leveling-on-a-microcontrollers-eeprom) – jippie Sep 14 '14 at 19:49

5 Answers5

16

I would not write every event to EEPROM. Most of the time you will have power, so keep the live count in RAM.

The amount of energy it takes to save the live value from RAM to EEPROM is pretty minimal. Use a capacitor to store enough energy to run the micro long enough after power fail is detected to copy the live data into EEPROM, then shut down cleanly. You should only need a few 10s of ms at most, maybe just a few ms. You also need to be able to detect power fail early enough so that there is still energy in the cap to perform the clean shutdown sequence. This should not be hard though.

For example, let's say the micro requires 20 mA at 3.3 V (that is actually quite high for this kind of application) and that shutdown takes 20 ms. That's (20 mA)(3.3 V)(20 ms) = 1.3 mJ. A 470 µF cap charged to 12 V holds 34 mJ, for example. Let's say you normally keep the cap charged to 12 V, and detect power fail when it gets down to 11 V. At that point it has 28 mJ left. To get 2 more mJ out only requires draining it to 10.6 V.

These are just numbers I pulled out of the air as example. A 470 µF 16 V cap wouldn't be a big deal to add to the device, but even that is clearly more than necessary in this case. The point is to show this method is quite feasible.

Olin Lathrop
  • 310,974
  • 36
  • 428
  • 915
  • 2
    +1, micros are quick and can respond in a flash. The hard part in my mind is ironically because you're dealing with a slow 60 Hz power signal there'd need to be enough headroom between charge/discharge and whatever your LDO input is to reliably trigger off of. – Nick T Sep 14 '14 at 20:48
  • +1; that was my immediate reaction and I started to post it as a comment; then I saw yours. For anyone who's having trouble visualizing this, think of the cap and power-detection as a "micro UPS" which signals the "computer" (the meter) that it should shut down cleanly before the UPS runs out. – keshlam Sep 14 '14 at 23:10
8

The solution to the problem is relatively simple. You accumulate the pulse count to a regular RAM location. Then once each 10 minutes you the copy the current value of the RAM based counter to EEPROM. Using this strategy an EEPROM with a one million cycle count endurance will last about 19 years. For most products this is a good comparison to the expected product life cycle.

If you do have sudden power loss then at most you are going to lose 10 minutes worth of pulse count accumulation.

There is an additional strategy that should be taken into account for this type of application of EEPROM. Due to the possibility of sudden power loss and possible corruption of the EEPROM writing operation you should always store the data to the EEPROM with a simple one byte XOR type check code so that you can validate the EEPROM data as good. Then when you go to store the data each 10 minutes you store TWO copies of the data & check code. Make sure that one copy is completely stored before beginning on the second copy. The reason for storing the two copies is so that if a power loss occurs whilst writing one copy the other copy is still there. In the case it is the first store operation that gets corrupted the second copy will retain the data from the previous 10 minute store operation.

Whenever your micro controller starts up read the first copy of the data from the EEPROM into the RAM working location and validate its check code. If the check is OK then proceed onto normal product operation. If the first check is bad then read in the second copy of the data from the EEPROM and check it. If that copy checks out OK then you are good to proceed with normal operation. For the unlikely case the both check codes are bad you have to reset your counter value to zero and then notify the home office that there was a problem.

If your product has a normal user initiated turn on / turn off process then as part of your normal power down sequence you can store the data to the EEPROM in that case. For this to be effective the power down request must come as a signal to the microcontroller so that it can perform any last second details like this and then a separate firmware controlled output from the microcontroller actually makes the action to turn off the power.

I've used this scheme in multiple commercial products to good success. It is a bit beyond the scope of this answer to discuss the simple one byte XOR check code that is used to check the data validity from the EEPROM. That said I can share that algorithm with anyone who is interested.

Michael Karas
  • 56,889
  • 3
  • 70
  • 138
  • The energy meter is powered by electricity supply .There is no certainty when the electricity goes off .In case of power failure how do i tackle the situation ? – Debidutta Pattanaik Sep 14 '14 at 15:24
  • 1
    You handle it as I described in detail in my answer. If the power goes off at most you lose the pulse count accumulation since the last EEPROM store operation. This scheme may seem unacceptable to some folks because you can loose some counts but you have to weigh that against how often the power loss occurs. – Michael Karas Sep 14 '14 at 15:30
  • 2
    If the simple EEPROM scheme that I describe is "not good enough" then you have to resort to an external serial RAM that is backed up from a battery cell or super-cap. Since many products has an RTC function it can be advantageous to select the RTC chip that has some RAM cells that can be used for this type of parameter storage. – Michael Karas Sep 14 '14 at 15:32
  • For commercial billing losses multiply into thousand devics and will be resulting revenue loss – Debidutta Pattanaik Sep 14 '14 at 15:36
  • 1
    Yes you are right - IF you have 1000's of sudden power losses. Typically that is not the case however and the small loss is easily justified over the costs of more complex product designs that use a battery or supercap type backup strategy for a RAM. Supercaps are expensive and finniky and batteries require replacement - both of which are negatives for a product like you are developing. – Michael Karas Sep 14 '14 at 15:42
  • It can be exploited by interrupting the power shortly befrore the persistent write. It it writes every 10 minutes, just interrupt 9 minutes after the last startup - every 9 minutes. – Volker Siegel Sep 14 '14 at 17:14
  • 1
    As a consumer, not being billed for the last 10 minutes of power is not going to alleviate the fact that you just shut off my power, period. – Nick T Sep 14 '14 at 20:50
  • What OP needs to do is cost analysis: How much will be the average cost of potentially unbilled energy over X years? How much will be the cost of extra circuitry to count every blip? And then ask business planners because they'll may chose $2 to be paid over X years rather than $1 paid upfront. – Agent_L Sep 15 '14 at 13:14
3

I remember remotely to have read an Atmel Application Note covering that topic. See AVR101 about the technique of High Endurance EEPROM Storage using a circular buffer and providing reset protection.

Ghanima
  • 738
  • 9
  • 22
3

1,000,000 erase cycles is a lot, but you can burn that out quickly as you realized. For once-a-second readings, that would be met in 11.6 days.

As already mentioned, storing in RAM then writing to EEPROM only occasionally is one way.

Another way is to use FLASH EEPROM. With FLASH it's only the erase count that matters. You can write many times turning 1s into 0s without penalty. If you only have a few readings and relatively large amounts of FLASH space, you can use records.

Erase the data, leaving it all 0xFFs.

For writes: Write sequentially into the EEPROM space. When you're full, erase it all and start over. If your data value is all 0xFFs, you've got to change it by one LSB to avoid looking like a blank record. In your case, that'd be an overflow condition anyway.

For reads: Look for the all-0xFFs record, and back up one. If you reach the end and there's no all-0xFFs record, the last position is it.

FLASH endurance is usually lower... say 100,000. However, a simple 1Mbit FLASH would have enough space for nearly 104 years of storage using this method.

For a commercial product like this, you should have power failure safety on EEPROM writes. Either add power failure detection and enough backup power (supercap, whatever) to complete a write operation... or perform the writes in a fail-safe manner. To do this, you could divide the EEPROM into two halves, alternate between halves on writes, and write a CRC with the data record. The read would look for the latest record in either page with a valid CRC. The halves must be erase-block aligned for safety.

Utilities usually want more than just the total used power, though. Consider keeping track of how many counts/second you get and store these numbers as well. Most utilities charge commercial customers based on the maximum power they need in any given 15 minute or so interval as well.

darron
  • 3,491
  • 2
  • 29
  • 42
3

I had similar problem when I need store runtime status data. I use I2C ferromagnetic RAM F-RAM (http://uk.farnell.com/ramtron/fm24c04b-g/fram-4k-i2c-8soic/dp/2077745?Ntt=2077745). Endurance is defacto unlimited (10^14 read/writes). Price is higher than normal EEPROM but still convenient.

TMa
  • 1,100
  • 1
  • 7
  • 16