Non-volatile counter implementation

Hi all,

I'm thinking of ways to implement a nearly non-volatile counter using flash and RAM. Idea is to count events in a RAM counter and write the count to flash every n times. At first I thought I'd just use successive locations in flash until I need to reformat the entire sector but I'm thinking it may be better to flip single bits from 1 to 0 with each bit indicating n events. That way I don't waste an entire DWORD for each update.

Does anybody know of a ready-made solution for this kind of thing?

Thanks, Andrew

Reply to
andrew queisser
Loading thread data ...

There have been earlier threads along this line. With flash, there are hidden, undocumented details to watch out for:

  • What block size is _actually_ erased during a byte-write ?
  • Does write of increasing 0's save degradation, or not ? ( eg if you choose to write 1,2,3,4, lows in the LSB, to give a 8:1 saving in erase, does that actually make it to the silicon ? )
  • How do cells actually fail - can you read-back to catch a failure, or it is a power-removed leakage failure ?

Probably the best way, is to take your chosen chip, and thrash a few in the corner of the lab, to failure.

-jg

Reply to
Jim Granville

Good points, thanks. Not sure I understand your second comment, though. Are you saying that degradation might not be localised to a single bit? In that case I could save myself the trouble of separating out the bits.

Andrew

Reply to
andrew queisser

I would use a small, low cost micro (PIC maybe) and save the count in the EEPROM. Single chip solution.

Thomas

Reply to
Thomas Magma

Oh, I should have mentioned that we already have flash, RAM, etc. available in our system so this is just a software question. Is there an advantage of EEPROM over flash in terms of erase cycles?

Andrew

Reply to
andrew queisser

Look into ferroelectric ram. It is fast writing, reading and is non-volatile.

Don

Reply to
Donald Harris

Here is a quote from Wikipedia:

"While RAM has no limitations on rewrites to memory, EEPROMs are limited in that repeated write and erase cycles eventually damage the thin insulating layer, a process called 'wear out'. Some early EEPROMs could only perform about 100 erase-write cycles but new models specify 100,000 erase-write cycles or more. Flash memory is cheaper than EEPROM but will wear out faster, typically after 10,000 erase-write cycles. Another reason why EEPROM is more effective for storing configuration data is that Flash memory has to erase multiple memory locations at a time. Changing a single byte is only possible by rewriting a whole block, which causes the flash memory to wear out more quickly than one might otherwise expect."

Thomas

Reply to
Thomas Magma

Look at the data sheets, commonly EEPROM's are designed to be cycled, whilst FLASH, expecially uC flash, is not. Often EEPROMs use hidden Error correction bits, to get the cycle counts up.

The best separate-chip technology for non volatile counters would be Ramtron's FRAM devices. Zero write delays, and no life cycle limits

My point is, you will need to test this, to be really sure.

Reply to
Jim Granville

Depending on what your counting the best alternative would be good supply supervision and one of the Ramtrom Ferroelectric RAM chips, minimal hassle and very high write cycles.

If counting time you might be able to use some of their other chips.

Almost single chip solution, as power supply supervision to disable accesses will be necessary on ANY solution.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Click to see the full signature
Reply to
Paul Carpenter

Yes Look up FRAM from Ramtron. 8pin chips like EEprom. 10E14 writes, with no write delay.

Reply to
Neil

If count only [m/n] , can you live with the fault between successive runs ?

E.g. a zero-bit means 8 runs, so

0xfe => 1..8 runs 0xfc => 8..16 etc.

But the main problem stays, you have to erase the flash at a time in the future.

But why not realy storing the 32bit value (btw. DWORD on an ARM CPU would mean 64bit :-)

Assume an (flash) array of 128 elements, all initialized to 0xff, if an element is 0 => take next if an element is > 0 && < 0xffffffff => last count stored if an element is 0xffffffff => free (Note: count of 0xffffffff cannot be stored, special handling is needed.)

If you no free element, erase all and start with first.

After storing a new count, clear all bits of the last.

Sound fairly easy to implement.

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
 Click to see the full signature
Reply to
42Bastian Schick

I use a "power going down" interrupt, and save off counters (and other things) as the power is going down.

-Hershel

Reply to
Hershel Roberson

That's exactly what I had in mind. I would flip a bit every 10 cycles. If the power goes down between cycles I lose 10 events. My flash is good for about 1 million erase cycles so I really don't need to worry about erase cycles as much as the time hit to erase a sector. The events happen about every second so I could really afford to flip a bit after every single cycle but then I might have to worry about having to erase the sector while I'm doing a time-critical operation instead of waiting for the next power cycle which would happen when the battery gets disconnected for recharge.

Andrew

Reply to
andrew queisser

Hmm, I don't have one of those but maybe we should add something like that.

Thanks, Andrew

Reply to
andrew queisser

I think to be (power)fail-safe you'll need 3 sectors, two management sectors and one data sector.

Only one data sector, as you are only flipping bits, you might store the actual count in a management sector while erasing.

Two management sectors, since you sometimes have to erase one.

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
 Click to see the full signature
Reply to
42Bastian Schick

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.