12
\$\begingroup\$

I need a memory solution which is going to be used to keep track of an accumulated count on a micro-controller based project.

By accumulated count, I mean to say that the micro-controller uses this memory location to keep count of the occurrence of an event. The count needs to be preserved during power outages, hence the need for NON-VOLATILE memory.

Also the occurrence of the count increment event is frequent hence there will be a lot of writes to the memory hence my hesitation to use EEPROM.

The preferred communication interface will be I2C, but other alternatives are welcome.

Off the top of my head, I envision an SRAM low-power volatile memory IC with the option of being powered by a backup battery like a coin cell on power-downs.

\$\endgroup\$
  • 15
    \$\begingroup\$ You want F-RAM. \$\endgroup\$ – Hearth Jul 5 at 13:29
  • 3
    \$\begingroup\$ ...and what is the question? \$\endgroup\$ – Curd Jul 5 at 13:32
  • 2
    \$\begingroup\$ What will you do if the power starts failing in the middle of an I2C write operation? How can you be sure you won't corrupt the count? This problem is more difficult than you think, unless you can detect imminent power loss, and in that case you can just copy your RAM-base counter to a typical EEPROM. \$\endgroup\$ – Elliot Alderson Jul 5 at 15:01
  • 5
    \$\begingroup\$ How 'frequent' is frequent? For a single variable even a small sized EEPROM would have pretty stupidly high endurance. You would also have a back-up of the last x counts in-case your last write failed. \$\endgroup\$ – hekete Jul 5 at 15:06
  • \$\begingroup\$ I recall some old-style non-FLASH EE memories promised 100Million cycles. \$\endgroup\$ – analogsystemsrf Jul 5 at 15:53
21
\$\begingroup\$

Three non-volatile memory types match your needs, in order of available size:

  • Wear leveled EEPROM/FLASH.
  • Battery backup SRAM.
  • FRAM.

In terms of cost, FRAM is best. All you need is inside the chip, including backup capacitors to complete writing. However available sizes are low.
Battery backup SRAM is large and costly in materials.
Wear leveled EEPROM requires firmware to handle the wear leveling.

\$\endgroup\$
  • 1
    \$\begingroup\$ Thanks. I checked out FRAM as suggested by @Hearth and i think it best suits my needs. Just hope i can find an I2C variant. Also the accumulator variable only needs to be 32 bits long. So size is not really a big issue. \$\endgroup\$ – Cerezo Jul 5 at 13:40
  • 3
    \$\begingroup\$ @GH_eng I²C FRAM chips. As memory goes it's fairly expensive (being a relatively new technology), but for what you need the alternatives would probably cost more. \$\endgroup\$ – Hearth Jul 5 at 14:38
  • 3
    \$\begingroup\$ There is also MRAM \$\endgroup\$ – DKNguyen Jul 6 at 4:00
  • 1
    \$\begingroup\$ @GH_eng The TI MSP430FR* have built in FRAM I think. Although you might already be constrained as to your MCU. \$\endgroup\$ – detly Jul 6 at 7:30
21
\$\begingroup\$

Here is what I did on a product that's still in mass production.

  • Keep all the parameters and counters in RAM
  • Hook up an interrupt line to a power supply voltage threshold detector
  • When the interrupt triggers, shut off everything that consumes power (most peripherals, LEDs, etc) and back up all the RAM to flash.

Turns out there was about 10-20ms of time between the low voltage trigger and the time when the power management IC kicked in and shut everything down (in an orderly fashion). Whether this works or not depends on the energy storage in your power supply, but even a small-ish supply can slow this down enough so that you can write a small data set reliably.

\$\endgroup\$
  • 1
    \$\begingroup\$ @Hilmer That's pretty clever! Good to know. Probably a reservoir CAP placed before the inputs of EEPROM and MCU will further increase the time latency. Only downside is probably more components on the PCB. \$\endgroup\$ – Cerezo Jul 5 at 21:35
  • \$\begingroup\$ At the time it was clearly the cheapest solution including PCB real estate. Of course it depends on your specifics: we had a spare had a spare GPIO line, so that was free. The rest was just a few jelly beans (small inexpensive SMD parts) \$\endgroup\$ – Hilmar Jul 7 at 11:55
  • \$\begingroup\$ You can probably stretch that 10-20ms if you really have to by putting an elcap in the supply just big enough to help and not too big to have troublesome side-effects. \$\endgroup\$ – Mast Jul 7 at 18:21
  • \$\begingroup\$ @Mast: that would probably be too expensive and you may be better off with a alternative solution \$\endgroup\$ – Hilmar Jul 8 at 12:11
6
\$\begingroup\$

Toggle MRAM (magnetoresistive RAM) is claimed to have an effectively infinite write endurance (they're not aware of any mechanism that would cause writing to wear it out). I'm not aware of any such chips that speak I2C, though, so you'd have to settle for SPI. Here's one such part: https://www.digikey.com/product-detail/en/everspin-technologies-inc/MR25H256ACDF/819-1064-ND/8286370

\$\endgroup\$
5
\$\begingroup\$

Sounds like you can just use a RTC clock chip or module. These have battery backup, extra SRAM for user data and come with I2C interface.

Or just use a MCU with battery backed SRAM to begin with, so no external components needed.

\$\endgroup\$
  • \$\begingroup\$ For example DS1307, DS1338. \$\endgroup\$ – filo Jul 5 at 15:34
  • 1
    \$\begingroup\$ Unfortunately, the RTCC used on the board is a DS3231M. Same pin configuration as DS1307 RTCC but with no internal spare data registers. Chose this because of its integrated oscillator. I sense a complete circuit review :( ! \$\endgroup\$ – Cerezo Jul 5 at 21:39
5
\$\begingroup\$

Cypress makes what they call Nonvolatile SRAM. It is standard SRAM that automatically backs up when the power fails. Since it only writes to the non-volatile memory on power failure, it has potentially much greater durability. It comes in serial and parallel versions. It might be a bit overkill, since the smallest one is 64Kb.

Under normal operation, nvSRAM behaves like a conventional asynchronous SRAM using standard signals and timing. nvSRAM performs parallel random access reads and writes as fast as 20 ns.

On a power failure, nvSRAM automatically saves a copy of the SRAM data into nonvolatile memory, where the data is protected for over 20 years. The transfer between SRAM and nonvolatile memory is completely parallel, allowing the operation to complete in 8 ms or less, without any user intervention.

On power-up, nvSRAM returns the data back to the SRAM and system operation continues from where it left off. nvSRAM also provides user controlled software STORE and RECALL initiation commands, as well as a user controlled hardware STORE command in most versions.

NVSRAM Block Diagram

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

For a single 4 byte variable, EEPROM would be totally fine.

Let's say you are writing to it once per second and you have a typical 32Kb EEPROM and we go with a conservative endurance of 100,000 write cycles.

You can write your 4 bytes 8000 times before you need to do a clear. So that should be 800 million times that you can write it even using a conservative estimate.

Now there are only 31.5 million seconds in a year, so at one write a second it would take 25 years to reach the low end estimate of EEPROM endurance.

\$\endgroup\$
  • 1
    \$\begingroup\$ Of course, writing to EEPROM is pretty slow (milliseconds) so the OP's "frequent writes" might need a faster solution...you have assumed once per second but OP left us in the dark on that point. And "clearing" the EEPROM will take a very, very long time (seconds) indeed. I suppose you could just overwrite old values instead of erasing, but if the count values are not strictly sequential it would be hard to figure out which value was the last value written. \$\endgroup\$ – Elliot Alderson Jul 5 at 15:49
  • \$\begingroup\$ @ElliotAlderson You could probably assume what ever the highest value was, would be the last one. Obviously no idea if once per second counts as 'frequent' or not in this case. Just pointing out that for write frequencies more than 1 second apart, EEPROM is still entirely viable. \$\endgroup\$ – hekete Jul 6 at 11:36
0
\$\begingroup\$

There are plenty of options here, but the real issue is stopping the data from getting corrupted. Power loss during a write could corrupt the data. I2C is a good option for avoiding this, because e.g. with SPI you could find that a write appears (from the memory's point of view) to complete half way through updating say 4 bytes of a 32 bit word. I2C is a little more robust, but only a little.

My advice would be to store 4 copies of the value. That way even if writing is interrupted, two will always match.

FRAM or similar is probably the best option.

\$\endgroup\$

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.