8
\$\begingroup\$

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.

\$\endgroup\$
  • 4
    \$\begingroup\$ Use a big eprom and do wear levelling? \$\endgroup\$ – PlasmaHH Jan 26 '18 at 16:32
  • 5
    \$\begingroup\$ Possible duplicate of Wear leveling on a microcontroller's EEPROM \$\endgroup\$ – PlasmaHH Jan 26 '18 at 16:34
  • 6
    \$\begingroup\$ Can you use RAM + power loss detection? That's what's usually done. \$\endgroup\$ – Bryan Boettcher Jan 26 '18 at 16:34
  • 1
    \$\begingroup\$ 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.) \$\endgroup\$ – Eugene Sh. Jan 26 '18 at 16:35
  • 2
    \$\begingroup\$ 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. \$\endgroup\$ – Turbo J Jan 26 '18 at 18:05
12
\$\begingroup\$

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

\$\endgroup\$
  • \$\begingroup\$ 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? \$\endgroup\$ – ultimA Jan 26 '18 at 16:53
  • 1
    \$\begingroup\$ @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. \$\endgroup\$ – John D Jan 26 '18 at 17:24
  • 5
    \$\begingroup\$ 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. \$\endgroup\$ – Michael Karas Jan 26 '18 at 19:13
  • \$\begingroup\$ 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. \$\endgroup\$ – Michael Karas Jan 26 '18 at 19:20
  • 1
    \$\begingroup\$ 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. \$\endgroup\$ – supercat Jan 27 '18 at 1:05
11
\$\begingroup\$

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.

\$\endgroup\$
4
\$\begingroup\$

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.

\$\endgroup\$
  • 2
    \$\begingroup\$ An even older solution is magnetic core memory. \$\endgroup\$ – glen_geek Jan 26 '18 at 16:45
  • \$\begingroup\$ Just wanted to answer the same :) Here's the device to use datasheets.maximintegrated.com/en/ds/DS1307.pdf \$\endgroup\$ – Anonymous Jan 26 '18 at 16:46
  • 1
    \$\begingroup\$ @glen_geek Even I don't remember using that.:) \$\endgroup\$ – RoyC Jan 26 '18 at 16:47
4
\$\begingroup\$

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.

\$\endgroup\$
3
\$\begingroup\$

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.

\$\endgroup\$
3
\$\begingroup\$

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

\$\endgroup\$
  • \$\begingroup\$ 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. \$\endgroup\$ – Jules Jan 27 '18 at 21:51
1
\$\begingroup\$

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

\$\endgroup\$
0
\$\begingroup\$

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.

\$\endgroup\$
  • 1
    \$\begingroup\$ 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? \$\endgroup\$ – user72833 Jan 26 '18 at 21:43
0
\$\begingroup\$

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.

\$\endgroup\$
  • 1
    \$\begingroup\$ Can you even still buy core memory? \$\endgroup\$ – BeB00 Jan 26 '18 at 17:11
  • \$\begingroup\$ @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. \$\endgroup\$ – Harry Svensson Jan 26 '18 at 17:49
  • \$\begingroup\$ 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 \$\endgroup\$ – BeB00 Jan 26 '18 at 17:55
  • \$\begingroup\$ @BeB00 ebay.com/bhp/vintage-core-memory Oh well, looks like it exists in case someone wants the high quality stuff. \$\endgroup\$ – Harry Svensson Jan 26 '18 at 17:59
  • \$\begingroup\$ :P I'm not sure it's warrantied for 60 years \$\endgroup\$ – BeB00 Jan 26 '18 at 18:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.