Why not CMOS?

[Rick Law]

With flash and EE-PROM both have wearing down issue when written frequently, I would imagine CMOS memory module of similar capacity with button battery would be very popular for storing stuff like settings, configurations and such.

Why isn't CMOS memory module over the place?  What is the draw back that I am not aware of?

[TerraHertz]

Reasons:
Cost of the battery, and board space for it.
Need to implement power-fail data protection (if using standard CMOS RAM, which doesn't include that.)

But most importantly, probably the primary reason in corporate minds:
CMOS RAM plus easily replacable, no-leak coin cell, does not meet corporate 'planned obsolescence' objectives. They don't want to sell hardware that users can keep operational forever. They want to make and sell stuff that dies after some years, so the user has to buy a new one.

Limited lifetime flash memory is perfect for that. Since few users can diagnose and replace dead SMD chips. Especially if it held the firmware as well as config data.

[james_s]

Nonsense, the reason is cost, and the fact that battery backed RAM has a battery to fail. It is a common thing for people to modify older equipment to eliminate the battery and replace the memory device with flash or FRAM. Batteries are problematic, a large number of arcade and pinball PCBs have been damaged or destroyed by leaking batteries. Also capacity is a factor, flash chips hold much more data than CMOS SRAM.

[ejeffrey]

Standard flash chips have more than enough endurance for those applications.  Wear just isn't an issue in the vast majority of applications.

In addition to the points james_s makes, replaceable batteries suck if the stored information is important because it gets lost when the battery dies or while you replace it.  If the data is important enough to store maybe it's too important to lose.

[David Hess]

Battery backed up CMOS SRAM has been used in various applications in place of EEPROM.  In a low performance design, the CMOS SRAM could even be the main memory for the CPU.  Serial access SRAM is also available which is intended for this sort of application.

[Kim Christensen]

Back in the day that was the way to do it. But as others have said, modern flash is a far better choice.
If needed, a product could write to volatile RAM, sense when power has been removed, and have a capacitor to keep it running long enough to commit the data to flash.

Pic of an obsolete NVRAM chip with built in battery:


https://datasheets.maximintegrated.com/en/ds/DS1225Y.pdf

[srb1954]

But most importantly, probably the primary reason in corporate minds:
CMOS RAM plus easily replacable, no-leak coin cell, does not meet corporate 'planned obsolescence' objectives. They don't want to sell hardware that users can keep operational forever. They want to make and sell stuff that dies after some years, so the user has to buy a new one.

Limited lifetime flash memory is perfect for that. Since few users can diagnose and replace dead SMD chips. Especially if it held the firmware as well as config data.

They had the planned obsolescence objectives pretty well sorted back in the days when they used NiCd batteries for CMOS backup. The NiCds could be relied upon to leak and destroy large areas of a PCB forcing the scrapping of many pieces of equipment.

Unfortunately the introduction of the RoHS rules put paid to that little scheme effectively banning NiCds due to their cadmium content.

[Ian.M]

CMOS SRAM typically uses six^* MOSFETs per memory cell.  FLASH uses one MOSFET, with a regular gate stacked on top of the floating gate that stores the charge that holds the state.  Additionally more than one bit can be stored per FLASH cell (MLC FLASH) by treating the stored charge as an analog quantity and decoding it via a fast two or three bit ADC in the on-chip sense amplifiers.

Therefore FLASH wins over SRAM of the same generation technology, as it typically offers an order of magnitude more memory density.

* Its possible to only use four, using polysilicon pullups at the expense of static power consumption.

[T3sl4co1l]

Incidentally, several other NVRAM technologies are also limited in density.  FeRAM can't be smaller than a ferroelectric domain, feature size ~100nm IIRC.  So the density is comparable to SRAM (at feature size from a couple fab generations ago).  But this also means it's suitable to add onto existing coarse-scale chips like MCUs (e.g., TI's line of MSP430s with FeRAM).

And, I forget what other technologies are current and practical, and how well they scale? (PRAM, MRAM, etc.)

The issues of Flash are largely solved by using metric fucktons of it.  With wear leveling and a few gigs to spare, who cares how many writes it can take, if you just need a few megs?  (Assuming this is a smaller scale application of course.  SRAMs can't be made very big, like, you're never going to get an SD card of it.  You'd normally only use NVRAM for some persistent settings and stuff, totaling maybe, like, a few megs, on something like a whole-ass PC?  Idunno, what would you store that's not on fixed storage (HDD of whatever sort)..?)

As for persistent storage, HDDs and whatnot, it's always been a matter of wear and longevity; no HD lasts forever, whether that's due to failure of the media, electronics, or corruption caused by software.  Backups and regular replacement are just SOP.  You can get lucky, sure, there are half-century old HDDs with good data on them still spinning -- but it's the exception rather than the rule, and they also hold a truly negligible fraction of the data preserved nowadays (MB vs. TB in a single unit!).

Tim

[mawyatt]

Whatever happened to the HP/AG research into the "Memristor"

Best,

[Siwastaja]

Battery-backed SRAM is still a thing. Thanks to EEPROM and flash, not as much as it used to be, but still.

Reason is simple: many applications require real-time clock. To have that, you need to run 32.768kHz crystal and clock at least a few dozen logic gates and registers to keep time, and this will require significant enough power to require a battery cell. Total solution cost and PCB area is already significant.

Once you have all that, adding a kilobyte of SRAM comes for almost free, relatively speaking. Both from price and power perspective.

This battery-backed RAM is available in many microcontrollers that come with RTC peripheral.

Even simple external RTC chips come with a few user accessible registers if not kilobytes of RAM.

Writing to flash quickly at powerdown is problematic. Erase cycles take time and power beyond the capability of small electrolytic or MLCC capacitors. Battery-backed SRAM is trouble-free, at least until the battery finally is drained and then it becomes a trouble generator.

[PlainName]

I have a programmable mains timer which uses a tiny NiCd cell to maintain memory. So long as it's plugged into the mains once a year or something it's fine. Worst case, you shove it in a drawer for so long that the battery actually runs flat, but then you just leave it plugged into the mains for a few hours to recharge, and then you can hide it down the back of the sofa for another year.

Flash is OK, but look at Tesla - writing to flash like it was SRAM with the result that cars were borked after not very long at all. You'd think the designers would know what they're doing, but apparently some of them had never heard of flash wearing out. Result: they were made to recall 158,000 cars to fix...

[Benta]

Battery-backed SRAM is still a thing. Thanks to EEPROM and flash, not as much as it used to be, but still.

Reason is simple: many applications require real-time clock. To have that, you need to run 32.768kHz crystal and clock at least a few dozen logic gates and registers to keep time, and this will require significant enough power to require a battery cell. Total solution cost and PCB area is already significant.

Once you have all that, adding a kilobyte of SRAM comes for almost free, relatively speaking. Both from price and power perspective.

This battery-backed RAM is available in many microcontrollers that come with RTC peripheral.

Even simple external RTC chips come with a few user accessible registers if not kilobytes of RAM.

Absolutely true.
But a cost factor also came into play: the EU RoHS directive.
This banned built-in NiCd cells in RTC/RAM modules (like Dallas used to offer), so a separate cell holder clip is also needed.

[Rick Law]

Reasons:
Cost of the battery, and board space for it.
Need to implement power-fail data protection (if using standard CMOS RAM, which doesn't include that.)

But most importantly, probably the primary reason in corporate minds:
CMOS RAM plus easily replacable, no-leak coin cell, does not meet corporate 'planned obsolescence' objectives. They don't want to sell hardware that users can keep operational forever. They want to make and sell stuff that dies after some years, so the user has to buy a new one.

Limited lifetime flash memory is perfect for that. Since few users can diagnose and replace dead SMD chips. Especially if it held the firmware as well as config data.

I use a cheapo $15 USD B3603 digitally controlled CC/CV as my bench supply.  The thing still "works" except it will no no longer store calibration data.  It still "works" only in the sense that if I ignore the build-in display and use external DMM for V/I display.  After testing it every way I can think of, my conclusion is that the EEPROM or flash base calibration data storage failed.

That is what made me think why not CMOS to begin with.  If only the calibration storage hasn't fail...

I had a few of them.  I am now using another B3603 purchased around the same time.  Perhaps "planned obsolescence" is exactly the reason...      I could replace the MCU, but then I would need to bring the firmware over.  Yeah, not a thing user can easily do.  I am keeping that failed one for part.  I got my money's worth out of it even with "planned obsolescence", but still, it is such a garbage-creation unnecessary waste.

[retiredfeline]

This banned built-in NiCd cells in RTC/RAM modules (like Dallas used to offer), so a separate cell holder clip is also needed.

I have some of those ancient things. They are lithium cells and non-rechargeable.

[David Hess]

CMOS SRAM typically uses six^* MOSFETs per memory cell.  FLASH uses one MOSFET, with a regular gate stacked on top of the floating gate that stores the charge that holds the state.  Additionally more than one bit can be stored per FLASH cell (MLC FLASH) by treating the stored charge as an analog quantity and decoding it via a fast two or three bit ADC in the on-chip sense amplifiers.

Therefore FLASH wins over SRAM of the same generation technology, as it typically offers an order of magnitude more memory density.

That is an apples to oranges comparison because the Flash memory you are describing does not qualify as RAM in the same sense of random access memory that SRAM does.  EEPROM qualifies though and is much more comparable to SRAM.

SRAM could be preferred to EEPROM, and by extension all Flash memory types, for performance and endurance reasons.

[Kim Christensen]

I use a cheapo $15 USD B3603 digitally controlled CC/CV as my bench supply.  The thing still "works" except it will no no longer store calibration data.  It still "works" only in the sense that if I ignore the build-in display and use external DMM for V/I display.  After testing it every way I can think of, my conclusion is that the EEPROM or flash base calibration data storage failed.
That is what made me think why not CMOS to begin with.  If only the calibration storage hasn't fail...

Sounds like a bad design or something. I mean, how often would it need to update the calibration data anyway? Usually the only time it would write to the flash would be when you put it in calibration mode and ran through the calibration procedure. Otherwise, it's just reads the Cal data from the flash which doesn't cause wear...

[Rick Law]

I use a cheapo $15 USD B3603 digitally controlled CC/CV as my bench supply.  The thing still "works" except it will no no longer store calibration data.  It still "works" only in the sense that if I ignore the build-in display and use external DMM for V/I display.  After testing it every way I can think of, my conclusion is that the EEPROM or flash base calibration data storage failed.
That is what made me think why not CMOS to begin with.  If only the calibration storage hasn't fail...

Sounds like a bad design or something. I mean, how often would it need to update the calibration data anyway? Usually the only time it would write to the flash would be when you put it in calibration mode and ran through the calibration procedure. Otherwise, it's just reads the Cal data from the flash which doesn't cause wear...

Bad design - I imagine so as well.  It has other quirks to make me think the design isn't great.  It however did the CC/CV very nice.

It also stores output settings so it can reboot and auto restart the output to prior setting, so there is more EEProm/Flash writes than just calibration.  Even with that, I am very doubtful I changed the output voltage or current limit thousands of times to wear out the non-volatile memory (EEProm or flash) in about 4 to 5 years.

I will see how long my replacement lasts.  For a cheapo, I considered it very durable at 4 to 5 years of regular use.

[T3sl4co1l]

I guess no one's extracted/RE'd the original to tell, but there appears to be a replacement:
https://github.com/baruch/b3603

Question, is the setting persistent, i.e. you set it to 5V 1A, turn it off, come back the next day it's still on 5V 1A?  If so, then that's probably wearing NV memory.

Tim

[Siwastaja]

Bad design - I imagine so as well.  It has other quirks to make me think the design isn't great.  It however did the CC/CV very nice.

Flash works perfectly for storing calibration data. It has to store the firmware, anyway. The very same flash technology then stores calibration data. If the flash fails, you are doomed anyway. But longevity of MCU internal flash is very well tested and though out, it's many many decades at very least if not over a century. There are very little failures in early flash-based MCUs from the 1990's, OTOH nearly 100% of battery based SRAM from the same era have died already. If the SRAM holds factory calibration or other vital data, the units are bricked.

Battery-based SRAM storage is at least an order of magnitude more finicky, easier to get wrong, and even with everything done right, will die in 10-20 years.

Your unit just failed, because crappy design can always fail for whatever reason. Changing to fundamentally more unreliable technology will only make it even less reliable.

[Bassman59]

Back in the day that was the way to do it. But as others have said, modern flash is a far better choice.
If needed, a product could write to volatile RAM, sense when power has been removed, and have a capacitor to keep it running long enough to commit the data to flash.

Pic of an obsolete NVRAM chip with built in battery:


https://datasheets.maximintegrated.com/en/ds/DS1225Y.pdf

Dallas also made the DS5000T, which was an 8051 that used battery-backed SRAM as the program memory. You could also write to the program memory with a PC serial port which was handy back when the alternative in the late 1990s was a windowed EPROM.

It was specified to keep the program valid for at least ten years without power applied, and longer if the system was powered up.

I inherited a project that used this part back in 1997. It worked as expected. I probably should have asked the expected lifetime of the instrument that used the part, as by now the battery is surely dead.

[Berni]

Batteries are horrible, please don't start putting them into products again.

There are non rechargeable cells that once dead render the entire product dead while rechargeable cells have way less capacity while still eventually wearing out and going dead, sometimes even leaking toxic corrosive goo over the board. Okay rechargeable cells can actually live a long happy life, but that is only in a favorable environment of stable temperature and regular consistent use, yet not all products gets used like that (leaving them over discharged can kill).There is test equipment out there using these battery backed Dallas SRAM chips, some of it holds valuable calibration data or even firmware that you really don't want to loose so you have to keep replacing them and keep a backup.

So what to use instead?
EEPROM and NOR Flash can actually live a really long time as long as you are not constantly writing large amount of data every second of every day.

But what if i need to write 10KB every 100ms?
Then just buy some FRAM memory. It writes really fast compared to Flash and has so much write endurance that you might as well treat it like it is SRAM. The thing is that FRAM is more expensive than the cheap high capacity NAND flash that factories are pumping out by the ton for SSDs, memory cards, phones etc.. This kind of flash memory is the crappiest flash out there (it focuses on maximum density) and due to its low cost ends up becoming the main storage memory of embedded systems. Since the embedded system already has lots of flash memory they will tend to also use the same memory chip for configuration. If you are careless with your Linux image then you can end up with the OS writing a lot of unnecessary garbage in flash while running. This not only wears the flash much quicker but can sometimes even cause the filesystem to crap itself on a hard power loss, bricking the device.

[harerod]

...
This battery-backed RAM is available in many microcontrollers that come with RTC peripheral.
...

FULLACK, let me add real quick: The backup battery only needs to deliver power, while all other power is off. I have done designs which can use either a supercap or a CR2032. The latter is cheaper during production and holds more charge, the former may result in a longer design life/service cycle.
https://en.wikipedia.org/wiki/Supercapacitor

Edit 220201: Let me share a story from the glorious days of battery buffered SRAM. We are writing the year 1998. The straddle carrier drivers of a certain Irish port went on strike. To emphasize their demands, they pulled the buffer batteries from all the Siemens S5 PLC's and threw them away. These PLC's were the brains of those machines, located in a locked cabinet in the driver's cabin. Their memory held program data and machine specific calibration data. I can't remember how many machines were standing around, dead in their tracks, blocking access to the container stack. Hunks of 56t of steel, 14m high, 6m wide, 13m long. Some poor bastard had to get out to each one, climb up with a handy 13kg mobile programming device and set things up again. Guess how I know. (The attached pictures were taken at other ports.)

[tom66]

CMOS RAM plus easily replacable, no-leak coin cell, does not meet corporate 'planned obsolescence' objectives. They don't want to sell hardware that users can keep operational forever. They want to make and sell stuff that dies after some years, so the user has to buy a new one.

Limited lifetime flash memory is perfect for that. Since few users can diagnose and replace dead SMD chips. Especially if it held the firmware as well as config data.

Nonsense.  See test equipment with Dallas battery-backed CMOS modules that die after 20 years.  Yet you would never call that "planned obsolescence"

The real reason is flash memory is cheaper than RAM+battery connector+battery. 

Plus good flash memory (most is good now) can last longer than any battery-backed CMOS ever did.  Decades, even if written once a day with wear levelling.  And likely 100 years if never written after factory init.

[Bassman59]

But what if i need to write 10KB every 100ms?
Then just buy some FRAM memory. It writes really fast compared to Flash and has so much write endurance that you might as well treat it like it is SRAM. The thing is that FRAM is more expensive than the cheap high capacity NAND flash that factories are pumping out by the ton for SSDs, memory cards, phones etc..

We use FRAM for non-volatile parameter and calibration storage and it's dead simple to manage and ultra reliable.

As for "expensive," I suppose that it's cheaper than a battery-backed SRAM and its lifetime exceeds ours