Non-Volatile High Write Endurance Storage for PIC24

[xquercus]

I've built a direct digital synthesis based VFO around an AD9851 and PIC24F.  It has an LCD display, rotary encoder based control knob and a number of configuration options which I would like to store (tuning step, frequency, lcd contrast, backlight brightness, etc).  This is a hobby project which I intend to use to drive homebrew transceivers. Frequency is the tricky one.  Because this changes so frequently I don't think it's a candidate for storing in flash or eeprom due to write endurance limitations.  I've thought of workarounds such as only saving the frequency if it hasn't changed in 5 seconds, to cut down on writes, but this isn't how any other device I've used works and it would just be strange.  What should I do?

Like my commercial transceivers, the device is intended to be run from mains power -- which might complicate things a bit.  I'm thinking along the lines of two options, neither of which I've explored much, and am hoping for some input.  All of my commercial transceivers with digital tuning have have a button cell which powers some sort of non volatile storage mechanism.  I'm thinking of something along the same lines.  Option one might be to put the PIC into sleep mode (which preserves the internal SRAM) when mains power is turned off and run it off a battery.  I've looked into this a little bit and the main issue for me would be designing a system where the PIC can be driven by both a button battery and mains power.  I also haven't done a precise calculations of battery life so I don't even know if this would be an option.  A second option I've thought of (the one which first came to mind) is to use some sort of external serial SRAM device which refreshes itself using power from the battery alone.  Some looking online has sort of indicated that such devices exist but I haven't been able to find any specifics.

So which track should I follow?  If it's the latter, can someone suggest a particular product/part number to look into?

Thanks!

[SeanB]

Look at I2c clock devices, as these often have a couple of bytes of ram in them as well, backed up by the lithium cell you attach to the device. Generally they will retain data and the clock will runh for 10 years ( battery shelf life) and the cells are CR2032 coin cells in a holder. Only need 2 pins, and you probably already are using an I2C device so will have the appropriate code already. It adds an extra feature of a clock in the display as well.

[Rufus]

I've thought of workarounds such as only saving the frequency if it hasn't changed in 5 seconds, to cut down on writes, but this isn't how any other device I've used works and it would just be strange.

Why would it be strange? The only time you would be aware of the 'feature' is if you remove power within 5 seconds of the last frequency change. Why would you want to change frequency when you are going to power down in less than 5 seconds?

[mariush]

Have you considered using a super capacitor to store enough charge to keep the controller in (deep) sleep mode for about 1-2 days, which should be plenty of time to have it running again?

Or maybe just enough so that if it's powered down for 10-20 minutes, it writes the data to internal eprom?

[xquercus]

Look at I2c clock devices, as these often have a couple of bytes of ram in them as well, backed up by the lithium cell you attach to the device.

That's a very interesting idea.  Looking on Mouser I see that Microchip makes an RTC with 64 bytes of battery backed SRAM for a whopping 98 cents in quantity 1.  The chip includes a separate input for the battery and voltage sensing logic.  Just add a 32kHz watch crystal, the battery, and holder...

Why would it be strange? The only time you would be aware of the 'feature' is if you remove power within 5 seconds of the last frequency change. Why would you want to change frequency when you are going to power down in less than 5 seconds?

The only reason it would be strange is that it's different than this type of gear usually operates. 

Or maybe just enough so that if it's powered down for 10-20 minutes, it writes the data to internal eprom?

Hmm... I haven't used a super cap before but that sounds like a fairly elegant solution.  Maybe I could simply have one of the I/O pins detect when Vdd drops (on the supply side of the cap) and have it kick in a save to eeprom routine as soon as power is cut.

I also found an interesting alternative from Cypress:

http://www.cypress.com/?id=3489

Basically it's eeprom backed sram and comes in various serial and parallel interfaces.  It's pretty similar to the idea above about detecting Vdd failure and writing to eeprom when that occurs.  I think the only external part required is storage cap which provides the power to do the eeprom write.  If I recall, the 32kBit modules are $3 from Mouser (not in stock) and the 64kBit modules are $4.  I think that's more than the micro costs but it's an interesting and possible solution.

[nctnico]

Don't mess with batteries and SRAM. Look for FRAM from Ramtron. The newer devices have infinite write endurance.

[xquercus]

Don't mess with batteries and SRAM. Look for FRAM from Ramtron. The newer devices have infinite write endurance.

Wow, that looks very interesting.  With a claimed endurance of 10^14 writes, even if I left the VFO on scanning at 4 writes per second I could expect the module to function for 793,000 years -- if it didn't fail for some other reason.  Only $1.48 for 16Kb.

What alien civilization developed this technology?

[XynxNet]

This chip seems to do the trick:
http://www.digikey.com/scripts/dksearch/dksus.dll?vendor=0&keywords=CY14MB064J2-SXI-ND

But for 5$ i would propably just buffer the pic with a coin cell.

Edit: The FRAM looks even better. Didn't know they were out of the labs...and for 10 years X_x

[codeboy2k]

Don't mess with batteries and SRAM. Look for FRAM from Ramtron. The newer devices have infinite write endurance.

Wow, that looks very interesting.  With a claimed endurance of 10^14 writes, even if I left the VFO on scanning at 4 writes per second I could expect the module to function for 793,000 years -- if it didn't fail for some other reason.  Only $1.48 for 16Kb.

What alien civilization developed this technology?

I second the FRAM option. They are awesome, and they are way faster than other solutions. But because they come in relatively large sizes (16k), if you only need a small amount, it always seems like overkill; however the cost is justified in simpler code, no battery, no supercaps, no need to program unnecessary superlow power sleep modes and wake up when the voltage is about to fail, no need to even try to NOT write to the FRAM. Just do it, whenever you want to.
The bigger benefit in FRAM is in embedded data logging, where it's a no-brainer to make a circular buffer, and your last X data events are maintained in FRAM.

I've also used them as multi-ported RAM between multiple CPU's (with a CPLD acting as an arbitrator).  More like message passing mailboxes, with guaranteed data delivery and high-reliability.   If the system ever crashed it can reboot with a recovery procedure to recover what was written from one CPU and never cleared (read) by the other CPU.  A message might get re-delivered after a reboot, and we had to deal with that, but they are never lost.

[TerminalJack505]

Option one might be to put the PIC into sleep mode (which preserves the internal SRAM) when mains power is turned off and run it off a battery.  I've looked into this a little bit and the main issue for me would be designing a system where the PIC can be driven by both a button battery and mains power.

They make ICs that make doing this pretty easy.  They're called OR-ing controllers.  The LTC4412 is one example.  It has an output (STAT) that you can run to the MCU which you can use to bring it into/out of sleep mode.  You'd probably want to write everything to EEPROM when entering sleep mode just in case.  The IC can also switch off power rails that aren't needed during sleep.

See attached for an example of an LTC4412 application.

I'm not advocating this over any other option.  Just giving you more info.

[free_electron]

Fram is indeed the way to go. I2c interface or spi and compatible with 24xx and 25xx devices.
Not only ramtron has these, TI makes them too . Actually ramtron is a fabless company... Ti fabs em ..

[xquercus]

Thank you, everyone, for all of the suggestions on how to skin this cat.  FRAM looks particularly interesting so I have several 4Kb chips coming -- FM25L04B and FM24CL04B -- in SPI and I2C respectively.  They should be fun to play with.

[amyk]

FRAM is also a good replacement for the Dallas battery-backed RAM used for storing calibration constants in older test equipment.

[T4P]

Heck yes, FRAMs are good for lower storage space requirements compared to Flash (which was originally targeted to replace)
lower processor time and less power but comes at a price compared to Flash ... (for a dollar i can get 8megs with flash)

[pkrobot]

Consider using MSP430FR5739. TI has a cheap experimenter board also available. The main limitation is that it only has 16kb FRAM, and 1kb SRAM (you can use FRAM as RAM, its so fast). I have a few applications in mind myself, but am waiting for TI to release a 64k part (MSP430FR58xx, which they've promised to start sampling in June this year; I'm skeptical, though, because originally it was supposed to be released by the end of last year, and still hasn't happened). You might consider dumping the PIC altogether and going with MSP430.

-pk

[free_electron]

TI was giving away free development boards for that CPU at ESC a couple of months ago. i scored one. need to play with it one of these days ..

[poorchava]

You can consider using MRAM (magnetoresistive ram). currently it's only being commercially made by Everspin.In quantity their cost is comparable to Microchip EEPROMs. The bonus is that they are non-volatile like flash, simple like DRAM and fast like SRAM. No inherent fail mechanisms like flash, with theoretically unlimited lifetime. Writes are instant as opposed to being separate cycle which takes some miliseconds in classic EEPROMS. They go over 40MHz of clock speed.

Other elegant solution is to use LARGE cap on the input supply and some sense circuitry to detect power button status. When power button is switched off the controller shuts down everything else than EEPROM and itself and then writes settings. With low power consumption of modern micros it should be able to store settings before capacitor discharges completly.

[T4P]

You can consider using MRAM (magnetoresistive ram). currently it's only being commercially made by Everspin.In quantity their cost is comparable to Microchip EEPROMs. The bonus is that they are non-volatile like flash, simple like DRAM and fast like SRAM. No inherent fail mechanisms like flash, with theoretically unlimited lifetime. Writes are instant as opposed to being separate cycle which takes some miliseconds in classic EEPROMS. They go over 40MHz of clock speed.

Other elegant solution is to use LARGE cap on the input supply and some sense circuitry to detect power button status. When power button is switched off the controller shuts down everything else than EEPROM and itself and then writes settings. With low power consumption of modern micros it should be able to store settings before capacitor discharges completly.

... not comparable in terms of price and there are so much more pins compared to a microchip eeprom and a quick check with RS shows nothing from everspin and element14 : DISCONTINUED !
Anyway, FRAM costs about the same and fujitsu does make FRAM's also ( but i think it's a ... )