Most datasheets I've read in the past specified a retention time of 10 years, with a limit of 100,000 write/erase cycles. (More recent technology guarantees a 20 year retention period)

The write/erase cycles are easy to understand, but I'm not sure about the retention time. Does this mean that the device will retain said data for at least 10 years without it ever been applied power to?

I'm sure that's exactly what it means... but what if the device were to be used constantly, and power were applied at all (most) times? Will said data still be lost after 10 years? Will that 10-year period be reset when power is re-applied to the device, or will the device need to be re-programmed sporadically to make sure that the data is never lost?

 

This might help -

https://www.micron.com/~/media/docu...or_flash_cycling_endurance_data_retention.pdf

Regards, Dana.

 

This might help -

https://www.micron.com/~/media/docu...or_flash_cycling_endurance_data_retention.pdf

Regards, Dana.

It does help... and it more or less answers my question:

The dominant wear mechanism for charge loss and gain in NOR Flash memory occurs through electron trapping in the tunnel oxide of the Flash cell. This results in leakage through the insulator, and the damage primarily occurs during the ERASE/WRITE operations of a cell.

What I understand from that statement is that data will be corrupted after a 10 year average time from the moment it was recorded in the device.

 

You get one bit change maybe after some years. If it is within the program memory used, the firmware may crash.

Failures pretty much follow a bath thub curve.

At first from day zero you get failures from bad quality. After some time, this decreases.
Then after a long time (years) increasing again from aging.

This can be many things, bonding wire junctions fail, marginal structures fail, ionizing radiation.
Typically with 20 to 30 years old IC which are new old stock (quality wasnt as great for the bonding) you get some defective ICs (as new and never used). A few out of a thousand typically.

Then theres kinds such as old DRAM which are known to fail after a few years using (powered on).

Modern IC are mostly much better quality, even the cheap chinese kinds. Gold bonding is no longer used, firstly this looks great as gold is inert and a noble metal but in fact intermetal junctions with gold arent so great.

CDIP also has much higher failure rate than PDIP this was the main reason why they stopped making CDIP.

FLASH memory, when it is a brand new IC or brand new revision, the first of them always will be quite on the margin, while later parts will be more stable. The IC may be totally fine and work for 50 years, just statistically theres more defective ICs, when the process is just brand new.
They are often some 10s nanometres only so you can imagine.

You should use CRC and reundancy, at least be able to detect failures and bit errors as such. You dont want a large heater or pump to turn on at random, or some rocket to launch at a random point of time, so of course many efforts are made to deal with failing silicon.

As well in code, if it is critical normally a script is used, on which errors can be detected easily, it is not programmed with code as such.
The firmware then has an interpreter / parser for the script.

 

Electron drift change one or more bits and the rest is history.

 

You get one bit change maybe after some years. If it is within the program memory used, the firmware may crash.

Failures pretty much follow a bath thub curve.

At first from day zero you get failures from bad quality. After some time, this decreases.
Then after a long time (years) increasing again from aging.

This can be many things, bonding wire junctions fail, marginal structures fail, ionizing radiation.
Typically with 20 to 30 years old IC which are new old stock (quality wasnt as great for the bonding) you get some defective ICs (as new and never used). A few out of a thousand typically.

Then theres kinds such as old DRAM which are known to fail after a few years using (powered on).

Modern IC are mostly much better quality, even the cheap chinese kinds. Gold bonding is no longer used, firstly this looks great as gold is inert and a noble metal but in fact intermetal junctions with gold arent so great.

CDIP also has much higher failure rate than PDIP this was the main reason why they stopped making CDIP.

FLASH memory, when it is a brand new IC or brand new revision, the first of them always will be quite on the margin, while later parts will be more stable. The IC may be totally fine and work for 50 years, just statistically theres more defective ICs, when the process is just brand new.
They are often some 10s nanometres only so you can imagine.

You should use CRC and reundancy, at least be able to detect failures and bit errors as such. You dont want a large heater or pump to turn on at random, or some rocket to launch at a random point of time, so of course many efforts are made to deal with failing silicon.

As well in code, if it is critical normally a script is used, on which errors can be detected easily, it is not programmed with code as such.
The firmware then has an interpreter / parser for the script.

I also use write-leveling, CRCs, and redundancy, even in my "cheap" products. Together, they extend the flash life dramatically.

 

I also use write-leveling, CRCs, and redundancy, even in my "cheap" products. Together, they extend the flash life dramatically.

CRC and redundancy I understand ... but would you mind clarifying what write-leveling means?

 

...clarifying what write-leveling means?

Sorry, the actual term is wear leveling.

For my projects, the EERAM size is typically quite a bit larger than the data I need to store, though I may need to write it frequently. I choose a record size large enough to fit the data + CRC (say 32 bytes, for example). Let's suppose my EERAM size is 512 bytes.

Most will just define the first 32 bytes as the record location, and rewrite it as often as necessary. With a 100,000 write endurance, products will begin to fail after the first 100,000 writes. Only one bit needs to fail to make the product useless.

My EERAM library divides the EERAM into records of equal size spanning the entire EERAM space (16 32 byte blocks in this case). Each block write writes to the next record, reads it back to verify a proper write, then invalidates the prior record (by changing the CRC in a known way). If there is a write error in the current block, the next block is automatically written, and so on until a validation is successful.

In this way, the endurance is extended by at least (EERAM size / block size or 1.6M writes in this case), and a single or multiple byte failure will not brick the product. In actuality, the life is extended much more dramatically, as all the bytes tend not to fail simultaneously.

Finally, if a subsequent read error occurs on a previously written valid block, the code can "back up" in time and load the most recent error free block -- simultaneously alerting the user that the EERAM is having problems and service may soon be required.

Note that in the method above, the CRC bytes get written twice for each data write. This reduces the overall effectiveness by 1/2. While this is not a problem for me, it can be avoided by including an incrementing sequence byte to the record. The latest valid record will be the one with the largest successive sequence byte (modulo 256).

 

Sorry, the actual term is wear leveling.

For my projects, the EERAM size is typically quite a bit larger than the data I need to store, though I may need to write it frequently. I choose a record size large enough to fit the data + CRC (say 32 bytes, for example). Let's suppose my EERAM size is 512 bytes.

Most will just define the first 32 bytes as the record location, and rewrite it as often as necessary. With a 100,000 write endurance, products will begin to fail after the first 100,000 writes. Only one bit needs to fail to make the product useless.

My EERAM library divides the EERAM into records of equal size spanning the entire EERAM space (16 32 byte blocks in this case). Each block write writes to the next record, reads it back to verify a proper write, then invalidates the prior record (by changing the CRC in a known way). If there is a write error in the current block, the next block is automatically written, and so on until a validation is successful.

In this way, the endurance is extended by at least (EERAM size / block size or 1.6M writes in this case), and a single or multiple byte failure will not brick the product. In actuality, the life is extended much more dramatically, as all the bytes tend not to fail simultaneously.

Finally, if a subsequent read error occurs on a previously written valid block, the code can "back up" in time and load the most recent error free block -- simultaneously alerting the user that the EERAM is having problems and service may soon be required.

Note that in the method above, the CRC bytes get written twice for each data write. This reduces the overall effectiveness by 1/2. While this is not a problem for me, it can be avoided by including an incrementing sequence byte to the record. The latest valid record will be the one with the largest successive sequence byte (modulo 256).

Many thanks for the detailed explanation. It'll come in handy in the near future.

Anyway, I'll soon be designing a different circuit requiring the use of external static ram, and I've decided to use fram instead of flash. Fram has far superior endurance and speed characteristics when compared to flash, although it's a bit more expensive.

 

Btw, my previous observation regarding fram concerns the use of memory only. My original question was intended to address the endurance of the code written in a flash mcu.