Flash wear out?

[lpcware]

Content originally posted in LPCWare by micrio on Tue Aug 10 05:57:25 MST 2010
I would like to understand the flash wearout characteristic.

I need to save a structure of about 10 bytes in flash. Since the flash can be written only about 10,000 times before wearout begins I want to minimize wearout failure. I would like to have an array of structures that I would index through.

The question is how to set this up. Flash can only be written in 256 byte blocks. It can only be erased in 4K byte sectors. Writing can only change a bit from a 1 to a 0. Erasing can only change a bit from 0 to a 1, i.e. a sector is erased to all 0xff's.

When I want to save my data I could find the next available array element, write my structure, and mark the old element as invalid. I could repeat this until the entire 4K sector is filled then erase the sector and start again. This raises some questions;

Does writting 0xff to locations that already contain 0xff's wear them out?
Does erasing locations that already contain 0xff's wear them out?
Does this get me past the 10K wear out limit?

Thanks,
Pete.

[lpcware]

Content originally posted in LPCWare by rcazalis on Fri Aug 27 08:09:13 MST 2010
This is how NOR Flash memory works:
A bit cell is by default at state 1. You can only program it to 0 by applying a "high" (>5V) voltage to this cell. So programming FF will not send any high voltage to any cell thus will not wear out the insulating layer.
To erase you need to apply a negative "high" voltage (<-5V) to put it back to 1. Note that erasure is done on entire block so it does wear the entire block.

You can write millions of times FF but you can't erase millions of times even if already erased.

That's why the suggested algorithm works... it has been proven as I have used it by the past.
I was writing a 4-bit information every 15 seconds on two 512B blocks alternatively (one block at a time so could erase one while keeping info on the other). The flash was given for 100k cycles (C8051F330 micro) so if it was wearing each time I wrote it would have lasted 15x100k seconds = 18 days...
I can tell that it has been working for over 5 years now so we're order of magnitude higher and calculations say it should last 100 years.
I don't expect this product to be still active in 100 years but I wanted to be sure.;)

[lpcware]

Content originally posted in LPCWare by kevink on Thu Aug 26 08:19:50 MST 2010
@rcazalis, where did you learn that about the flash?

I've recently done more reading upon the memory technology, and it actually sounds like it is the applied voltage that wears out the dielectric in the floating gate memory cells, not the transfer of charge. In this case, even writing FF to a location that has FF will wear out the cells.

It would be nice if someone who knows for certain (NXP or ARM employee?) could point us in the right direction regarding the endurance of the flash in these micros.

[lpcware]

Content originally posted in LPCWare by rcazalis on Wed Aug 25 08:42:19 MST 2010
OK, minimum write is 256 bytes at a time but if you just want to store only 10 bytes you can : fill the write buffer with all 0xFF except for your 10 bytes bytes.
Writing FFs doesn't wear the flash, only transitions and erasures.

To test you can write 100,000 times FF at the same location, your chip will be as new.

I've done this on a single bit information: At the same address I would first write 0xFE, then 0xFD, then 0xFB... up to 0x7F. This would end up to have 0x00 at that address that I'd have to erase if I wanted to use it again.
All that would be identical to writing 0x00 at the first place in terms of wearing out.

Does that help?

[lpcware]

Content originally posted in LPCWare by kevink on Tue Aug 24 08:18:06 MST 2010
So there are 4096 bytes in a sector, and the minimum write size is 256 bytes (a block) so there are 16 blocks.

My rationale for only using a block once is:

[LIST]
[*] I have read in several places that even writing FF's to a place where there are FF's will wear the flash out
[*]I have less than 256 bytes of data to write at a time, so I don't need to write more than one block at a time
[*]Erasure of a sector is needed If I want to write the block again
[/LIST]
Based on these things I can only write 16 times (16 blocks) before an erasure. So I write each block once, then erase.

I'm not 100% sure if what I have read other places about flash memory is true or not, we would need someone from ARM to know for sure I think.

Also, with this algorithm the 10,000 write/erase cycle should be increased to 160,000.

[lpcware]

Content originally posted in LPCWare by micrio on Mon Aug 23 19:02:21 MST 2010
This sounds like a very good algorithm. I like the part about using the blank check function.

I don't understand your rational for using each block only once. Even if you are wearing the entire block with the writing of only 1 word and the rest being 0xff you are not wearing the rest of the sector.

In other words you are wearing the block 64 times before moving onto the next block. You are only erasing the sector once in 1024 writes vs. erasing the sector every 16 writes. This seems like a gain with respect to minimizing wear.

[lpcware]

Content originally posted in LPCWare by kevink on Tue Aug 17 12:12:09 MST 2010
I had the same requirements (except I was writing 4 bytes, but this is no issue).

Here are my definitions:

[LIST]
[*]Word - 32bits / 4 Bytes of memory
[*]Sector - 4096 Bytes of memory (1024 words)
[*]Block - 256 Bytes of memory (64 words)
[/LIST]

Here are my algorithms for reading/writing. The writing algorithm ensures you only need to erase once every 16 writes. I have done timing on the writing/reading of a sector of flash on the LPC1114, at 40MHz, and the times are around 100ms for erasing, and 1 ms for reading (it increases linearly depending upon how far into the sector your data is).

Writing new Data:

[LIST=1]
[*]Read the flash sector using the blank check function of IAP functions. This will return to you the first non blank word (I think)
[*]Using this returned value, you know in which block (there are 16 blocks in a sector) your data is in.
[*]If the block is the first block, then erase entire sector because you know that all blocks after the block with data in it should have old data in them. write your new data to the last block.
[*]Else, write your new data to the block previous to the one with old data in it.
[/LIST]
Reading Data:


[LIST=1]
[*]Do a blank check of the sector, this will return to you the first word that is not blank.
[*]Read the first 10 bytes (or however long your data is) to get your newest data.
[*]If the sector is all blank, you haven't written any data to it yet.
[/LIST]

The minimum write size is a block of 64 words (as specified in the datasheets of LPC11xxs) and I have read in multiple places that even if you write FF's to the rest of the block, the memory controller will still apply voltage to the memory, so there is no point in trying to write a single block more than once before erasing it.

[lpcware]

Content originally posted in LPCWare by micrio on Tue Aug 10 07:20:51 MST 2010
That is a good idea, it would save one wearout cycle per structure save.

[lpcware]

Content originally posted in LPCWare by igorsk on Tue Aug 10 07:08:14 MST 2010
I don't know the answers but I have a suggestion for your proposed algorithm.
You don't need to mark the old element as invalid. Instead, in your read function keep going until you hit FFs. To make it more robust you can add a checksum at the end of your structure, so that you won't use a partially written entry.