battery-backed SRAM

Solve all your problems simultaneously: look for FeRAM. It's available serial and parallel, in all sizes.

It can be operated (R/W cycle) more times than the chip can see in its lifetime.

TI even makes MSPs with the stuff onboard!

Tim

-- Seven Transistor Labs, LLC Electrical Engineering Consultation and Contract Design Website:

Had a similar problem years ago with limited write cycles on a serial EEPRO M. The 'solution' on that one was to start a timer when a control was chang ed and keep resetting the timer while controls changed. 60 seconds after th e last change it used a write cycle. Of course you have 60 seconds of possi ble loss of the settings if a power failure happens.

There is, or at least used to be, NVRAM, needs no battery... in the days of my interest ~40 years ago at OmniComp/GenRad, was used to store cash register (NCR) data in case of power failure.

(I actually didn't "use" the NVRAM, NCR had me design a tester for NVRAM that would insure that the parts were good. They came back whining a month after the first breadboard was submitted for their evaluation that it didn't work... turned out that it worked very well, their NVRAM was bad >:-} ...Jim Thompson

That's interesting.

Available, affordable, 1e10 write cycles. We could still rotate a few copies of the setup, in case anything goes wrong.

Why is that scary? If this is a manual setup situation, you are set (worst case) for three setups per day for the next 90 years.

And, that's not a 'write cycle' when you store your 100 bytes of setup, it's only a 'write cycle' when you fill 32kbytes with setup records, and start rewriting over the old blocks. CAT32C256

is cheaper than a battery and socket, rated for 1M operations.

The chip is hugely oversized, in this case, for the records you are storing, and isn't erased each time. Append a serial-number to each setup, and at startup time scan for the highest serial number.

What do you see as missing from this one:

It seems terse but complete to me -- don't let the battery input go below

You might take a look at the super capacitors. 1 farad will buy you about

Hul

John Lark> I'm designing a benchtop gadget that will uses a 7020 ZINQ SOC chip,

FRAM (Tim beat me to it...).

Cheers, James Arthur

That's nice; the battery switch stuff is built in. But it's sounding like the fram parts are better... no battery required.

Is your equipment expected to last longer than that?

Vbat support

Some how the Battery replacement seems more professional for high quality gear. Cheers

I designed some in when I was fresh out of school. They certainly seemed to work at the time.

MRAM. New and allegedly improved replacement for FeRAM. Sorry, but no personal exprience with either FeRAM or MRAM.

What's wrong with EEPROM?

Speed and, usually more importantly, there is a lifetime maxaximum number of write cycles.

In the 1980s, many cartridges for the original 6502-based Nintendo Entertainment System used battery backed SRAM for save game states.

I plugged in my old copy of The Legend of Zelda a couple years ago, and all my saved games from when I were a kid were still there, just as I had left them.

The last time I played the game was around 1989.

If we had a power fail during a write, the saved setup could be corrupted. May as well save a few copies with checksums.

Batteries are big and expensive. An SO8 serial nvram is ideal.

But this is about a procedure only done occasionally (manual change of settings, or cold power-up), so speed doesn't matter. A hundred bytes, plus overhead, at 400 kHz serial, only takes a few milliseconds.

It's not 'write', but 'erase' that matters. A change of settings DOES write, but it isn't a 'write cycle' because you can make hundreds to thousands of records before anything has to be erased. It's limited how many erasures can be done before error rate bites ya.

But then you need complicated wear-leveling methods. By far the most common technique will be: reading and writing (where "write" means "unconditional erase of these bytes, followed by writing the bits needed") a constant range of addresses, covering the offset and size of the struct being recorded.

It's definitely not something you can do for logging purposes (say, recording a timer or event counter, every update, so that no data is lost on power-down), not for any length of time. That's historically where NVRAM* was used (RTCs and such), and it's precisely where FRAM and MRAM fit today.

Tim

Also batteries are subject to arbitrary and ever-changing transport restrictions, e.g. after various laptop fires, many couriers here won't take (or charge extra to take) equipement containing coin cells, even though they were considered fine since the 80's or before, and the laptop / hoverboard batteries that cought fire were totally different kinds of battery.