8

I am currently working on one embedded project in which I have one counter which will be active all the time. If the power goes down then also I have to store last counter status and load it back in next startup. So that I was planning to use EEPROM in which I will continuously write my counter value. But I have read somewhere that EEPROM has read/write endurance at about 100,000 and I will be updating that counter probably 120,000 per 24 hours. So I am finding alternatives to accomplish this task. please give me your suggestion for doing the same.

Nick Alexeev
  • 37,739
  • 17
  • 97
  • 230
  • 5
    Use a big eprom and do wear levelling? – PlasmaHH Jan 26 '18 at 16:32
  • 6
    Possible duplicate of [Wear leveling on a microcontroller's EEPROM](https://electronics.stackexchange.com/questions/60342/wear-leveling-on-a-microcontrollers-eeprom) – PlasmaHH Jan 26 '18 at 16:34
  • 6
    Can you use RAM + power loss detection? That's what's usually done. – Bryan Boettcher Jan 26 '18 at 16:34
  • 1
    EEPROM is probably is not a most suitable solution. Other than that you can try lowering the frequency of writing if your requirements allow this. Also you might want to perform the writes to random/running addresses instead of the same one (surely you will have to come up with some data structure able to retrieve that afterwards.) – Eugene Sh. Jan 26 '18 at 16:35
  • Re close votes. Question is not about wear levelling. – RoyC Jan 26 '18 at 17:20
  • 2
    There are other types of NVRAM than EEPROM or flash. Try searching for FRAM or MRAM chips - these have several orders of magnitude higher endurance. – Turbo J Jan 26 '18 at 18:05
  • I would use an ESP8266's SPIFFS for this: 3mb of space, wear-leveled automatically. w/o wifi, ESP uses about 15ma. – dandavis Jan 26 '18 at 20:14

9 Answers9

12

Another solution could be to use a microcontroller with non-volatile FRAM. FRAM doesn't suffer from the same limitations on write cycles as EEPROM.

Some of the MSP430 products from TI are available with FRAM, here's a link to an application similar to what you describe:

MSP430 with FRAM save state on power failure

Here's the Wikipedia article on FRAM: FRAM

John D
  • 22,677
  • 1
  • 39
  • 56
  • That's no solution at all, because multi-byte writes will still be corrupted upon a power failure. Or are you suggesting the OP to limit himself to a single byte? – ultimA Jan 26 '18 at 16:53
  • 1
    @ultimA The NVS library guarantees 16 bit writes, the OP doesn't say how big his counter is. This is just an example, other techniques may allow storage of larger data structures: Non-Volatile Storage (NVS): Library that makes handling of non-volatile data easy and robust against intermittent power loss or asynchronous device resets. MSP430 devices with FRAM non-volatile memory guarantee 16-bit writes in all scenarios. Often the data being stored is a larger structure. the NVS contains functions that store data in a way that is guaranteed to recover the last valid entry without corruption. – John D Jan 26 '18 at 17:24
  • 5
    FRAM is an excellent solution for this problem. I am glad to see an answer here suggesting its use. If there had not been one I was going to write a similar answer. My solutions using FRAM always store two copies of the data sequentially. Only one of those are possibly going to get corrupted. FRAM also writes way faster than EEPROM. Each copy of the data needs a way to validate that it is correct. That can be done using a simple XOR CRC or for small data set you can simply store data and its complement in each data set. At startup you just check which copy of the stored data validates. – Michael Karas Jan 26 '18 at 19:13
  • Incidentally some folks were jokingly suggesting the use of core memory. FRAM is a modern version of technology that works similar to the way core memory operated. – Michael Karas Jan 26 '18 at 19:20
  • @MichaelKaras Right, it is sort of the modern version of core memory. I think I read a while back that the last true magnetic core memory manufacturer finally stopped making it. It was used up until fairly recently in specific applications because nothing else was as radiation tolerant. – John D Jan 26 '18 at 19:59
  • 1
    If adequate space is available, keeping a counter in a way that can be updated safely can be done in a number of straightforward ways. One simple way is to have two copies of the counter as well as an indicator for which copy is valid; if the indicator is only changed when both copies are valid, and before changing either copy code sets the indicator to indicate the other copy is valid (and after writing sets the indicator to show both are valid), then it won't matter what value gets read from something that was being written during a power-down. – supercat Jan 27 '18 at 01:05
  • what will be a price of FRAM? because here cost is a real issue. Additionally, I just want to write 20 bytes only. – Nishant Kathiriya Jan 27 '18 at 14:09
  • An MSP430 microcontroller with FRAM costs about $3 or so in 1K unit quantities. Much less in high volume. You can get samples for free. I'm sure there are examples from other companies and maybe even stand-alone FRAM devices. – John D Jan 27 '18 at 18:54
  • You can also get FRAM devices as either I2C or parallel external chips. I can find 16Kbit serial FRAM chips from chinese suppliers in the region of $1 each (in quantities of 100). I've found european suppliers tend to want *much* more for them, though. – Jules Jan 27 '18 at 21:22
  • ... actually perhaps not as much as I thought. I see Mouser UK has the FM24CL16B chips I was looking at for £1.22 each (= ~$1.80) on reels of 3,000, and digikey will do them for not much more than that on a single chip price. – Jules Jan 27 '18 at 21:29
  • @Michael Karas: Yes the technique that you describe is great but it is a software technique and has nothing to do with using FRAM. That solution would work just as well using traditional EEPROM. Hence the solution to the OPs problem is not using FRAM but to use corresponding techniques in the software (or backup power as others have suggested). Using FRAM can still be beneficial for other reasons (speed etc.) ofc, but in general it does not help with safety against power failures, except in that you have less time to bridge if you are using backup power. – ultimA Jan 27 '18 at 22:18
  • @ultimA That's true, though if you are expecting a lot of power failures or interruptions over a long lifetime FRAM does have the advantage of many more write cycles. – John D Jan 28 '18 at 03:02
11

I have this issue in a current project.

The way I'm dealing with it is to keep the live value of the counter in RAM. I added a little bit of hardware so that the microcontroller can detect that the raw input power voltage is low. If so, it stops what it's doing, saves the live counter value in EEPROM, then waits watching the raw power voltage. If it goes back up, with some hysteresis, then the micro essentially restarts. Otherwise, if power continues to go down, the micro will eventually get stopped. On the next restart, the counter value is loaded from EEPROM, then used live in RAM again until the next power-down.

It doesn't take long to write a small value to EEPROM. Most likely your existing power supply system has enough energy storage that you can detect the voltage going low, and still have enough guaranteed run time before power to the micro goes below the operating or EEPROM write threshold.

In my case, the only additional hardware was a Schottky diode to prevent the DC power supply from sucking charge from the local reservoir on the way down, and two resistors as a voltage divider so that the micro can read the raw input voltage. The rest is firmware.

It's important to note that you should be watching the voltage on the input to whatever final supply powers the micro, not the micro's power voltage directly. By the time the latter goes low, it may be too late. Hopefully there is a voltage range that is below the worst case when everything is operating correctly, and above what the micro's power supply needs to guarantee regulated voltage to the micro. In my case, the micro's supply was a buck regulator fed from 48 V, so there is a large range that is below normal but where the micro can still operate reliably.

Olin Lathrop
  • 310,974
  • 36
  • 428
  • 915
4

Old old old solution, cmos counter + lithium battery or Ram + lithium battery.

The power supply for the storage element comes from the normal power supply when it is available or the battery when it is not.

A lot of modern micros in sleep will maintain their state with a very low current supply. So you can use this technique with power down detect to go to sleep then use a battery to maintain state during the sleep period while the main supply is off.

RoyC
  • 8,418
  • 6
  • 25
  • 40
4

Microchip has a series of I2C "EERAM" parts which will allow data to be stored in SRAM, then write it to EEPROM (using energy stored in a capacitor) when power is lost, to be loaded when power returns. This seems like it would be perfect for your application.

A representative example of these parts is the 47L04.

3

Another solution.

Detect power down and use a supercap or non super cap to keep power up for a few milliseconds. Use this time to write your counter value to EPROM. Only write to EPROM at power down. Number of EPROM cycles = no of power down cycles.

RoyC
  • 8,418
  • 6
  • 25
  • 40
3

Use a FRAM chip such as the FM24C04B. They have very high write endurance and are non-volatile.

https://www.mouser.com/ds/2/100/001-84446_FM24C04B_4_KBIT_512_X_8_SERIAL_I2C_F-RAM-477782.pdf

You could also use a battery backed SRAM (NVRAM) module. For example M48Z02-150PC1

https://www.mouser.com/ds/2/389/m48z02-955115.pdf

user4574
  • 11,816
  • 17
  • 30
  • I'm not sure about in other regions, but here in the UK digikey is *much* cheaper than mouser for FRAM parts. And as always, as long as you can find a supplier you can rely on (or if you only need a small run and can live with the chance of dealing with a potentially untrustworthy supplier) there are plenty of chinese suppliers who can substantially improve on both prices. – Jules Jan 27 '18 at 21:51
1

I decided to go with "ds1307 RTC". Because it has 54byte of power-backed SRAM. which allows infinite read/write cycle.

0

If your embedded project has NIC on it send your counter to remote computer/server. It seems 120,000 iterations in 24 hours is about one iteration in 0.72 seconds, should be OK for network traffic.

Server will always have last value of the counter stored. No counter value corruption on power loss because valid packet needs to be issued to update value on the server; however requires constant connectivity, or special time-out protocol must be designed. In addition, as a bonus, you will be able to control your device from remote if it is needed.

Anonymous
  • 6,908
  • 1
  • 14
  • 41
  • 1
    If the requirement is to implement a frame counter to prevent replay attacks and otherwise guarantee protocol compliance, how are you going to send the value to the device? –  Jan 26 '18 at 21:43
0

A) Use a 100 µF capacitor (or larger) to power up the counter during the off time. Or whatever logic that is required to hold the counter value.

B) Use magnetic-core memories, they might be a bit iffy to set up.

C) Make a motor controlled potentiometer (like a servo), at some point your counter will overflow, right? Map that to 360 degrees. Then make a feedback loop so you can set the value of the potentiometer digitally and read it digitally.

D) Send your counter value once every minute to some server, or servers, and let them remember the value for you during the off time. Then once power comes back up retrieve the counter value back.

Harry Svensson
  • 8,139
  • 3
  • 33
  • 53
  • 1
    Can you even still buy core memory? – BeB00 Jan 26 '18 at 17:11
  • @BeB00 I don't know, that's before my time. But I'd use a hex nut for 2 mm threaded rods with some wires wound through it like a toroidal coil. - And then back to whatever circuitry that is commonly used with the core memory. I assume just an ADC would be good enough to read, when the hysteresis of the core goes the other way and releases energy. – Harry Svensson Jan 26 '18 at 17:49
  • I mean... maybe as an experiment it would be fun, but I would definitely not ever use that in a system that I needed to work – BeB00 Jan 26 '18 at 17:55
  • @BeB00 http://www.ebay.com/bhp/vintage-core-memory Oh well, looks like it exists in case someone wants the high quality stuff. – Harry Svensson Jan 26 '18 at 17:59
  • :P I'm not sure it's warrantied for 60 years – BeB00 Jan 26 '18 at 18:00