FDS and write/erase flash cycles

[A.P]

Hi!

I've read a bit about the limitation of write/read cycles with the nRF52840. I the ~10,000 write/read cycles limit means after this many erases, the flash is no longer guaranteed to 'work properly'.

I have a few questions regarding this:

1. What does 'work properly' mean? will there be a problem with write operations, read operations or both? What kind of problems can be expected? (will I write 0xAB and sometimes the flash will contain 0xAC, or will the flash most likely contain 0xAB, but my read operation will return 0xAC?)

2. If the problem is with the flash read, rather than the flash write, does the FDS not 'deal' with this in any way? Meaning that if the CRC of the read data mismatches with the CRC of the flash data, will the FDS not -re-read the flash to get the 'correct value'?

3. Is there any way of knowing that my flash has started to deterioration? is there a count of 'erase' cycles kept somewhere which I can read to get an idea of how far I am from 10,000 writes?

4. Does the FDS guarantee a 'reasonably' equal distribution of write/erase cycles throughout the flash? meaning that if one flash segment has reached the 10,000 limit, the other flash segments are very close to the limit as well?

Thank you!

[Vidar Berg]

Hi!

1. I'm not an expert on the physics of NOR flash, but I believe the common failure mode after flash cells has worn out is that single bits can get stuck at  the value  '1'. In other words, data will not get stored correctly if the write operation involves clearing of a stuck bit.

The read operation should return the value as it was stored in flash.

2. You can enable the FDS_CRC_CHECK_ON_READ configuration option to make FDS confirm the integrity of the read data. It will then return FDS_ERR_CRC_CHECK_FAILED back to the application if the readback is incorrect. But, as mentioned in point 1, I believe it's more common for the error to occur during the write, and repeating the read operation will not help in that case. 

3. You can use FDS_CRC_CHECK_ON_WRITE to check if data is stored correctly, and if not, implement a re-try mechanism (FDS will automatically shift to the next available address on next attempt). The CRC check should only start to fail when you are writing to a section of flash that has started to wear out.

There is no HW support to keep track of the number write/erase cycles performed on each flash page.  Please keep in mind that 10 000 cycles is the minimum value according to spec. The typical value might be considerably higher. 

4. It provides basic wear leveling by  distributing the flash usage across several flash pages. The more flash pages you allocate to FDS, the less often you have to run Garbage collection and erase flash.

Best regards,

Vidar

[A.P]

Hi Vidar!

Thank you for the reply!
I understand you can't sign off on this, but I still would like to get an input from you on the following:
Should I want to get some indication of whether or not a specific device flash is near its end of life, will checking the percentage of FDS_CRC_CHECK_ON_WRITE fails out of the total request be a reasonable indication?

Meaning that if I write 100 times to the flash, and get 20% CRC write failed responses, that would be reasonable of me to assume that the flash has reached its end of life? Again, I'm not looking for absolutes, but rather some indication of the state of the flash.

Thanks!

[Vidar Berg]

Hi,

I would not expect to get checksum failures during normal operation before the flash cells are starting to wear out, so I think any percentage is an indication that the flash is nearing its end of life. Maybe you can set up a stress test with FDS to see what actaully happens when you start exceeding 10 000 erase cycles?

[A.P]

Hi!

Thank you for the reply!
I'll set up a test, hopefully in the upcoming days, and see what I get.
If I get interesting results I'll post them here as a reply.

Thanks again!