This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nrf52840 flash endurance in long life span

Hello, 

I am working on a project that is using nrf52840 chip as a peripheral and the product is supposed to last and run for 25 years. During that period the device will receive connections at least once every day that results in about 25 x 365 = 9125 times. Total up time of the device during the life span is around 300 hours.

We are using bonding and coded phy for the communications. I have questions regarding flash endurance during this period:

1. We are using FDS library to write to data to flash. If we write the same value (32-bit word) to the same memory location will it get through and result in a word erase? Which then reducing the life time of the flash? Or will it test and if the same value resides in memory it will skip writing it again?

2. Does softdevice write to flash during connection / events / disconnection phase that may wear out flash during its 9125+ communication periods?

3. Is there any guideline / best practice on preventing problems related to flash endurance in long run?

Kind regards,

Thank you!

Parents
  • Hi,

    This should not be a problem.

    1. We are using FDS library to write to data to flash. If we write the same value (32-bit word) to the same memory location will it get through and result in a word erase? Which then reducing the life time of the flash? Or will it test and if the same value resides in memory it will skip writing it again?

    FDS is a simple file system, so you cannot use it to write to a specific memory location. That is a good thing in this context. You refer to the data by a file ID and record key, instead of the location. If you update a record, then in practice the old is flagged as dirty/deleted and a new record is written at a different location. In order to reuse the same location again the flash page need to be erased, and that happens when you do a garbage collection, which is typically something you only do when needed.

    I am working on a project that is using nrf52840 chip as a peripheral and the product is supposed to last and run for 25 years. During that period the device will receive connections at least once every day that results in about 25 x 365 = 9125 times. Total up time of the device during the life span is around 300 hours.

    If you only plan to write up to 9125 times that is even within the 10,000 write/erase cycles that is specified for the nRF52840 flash. That said, using FDS you will get a much lower value. FDS has 3 words (12 bytes) overhead per record and 2 (8 bytes) words overhead per page. So if the data is a 32 bit word, the effective number of bytes you can fit in a FDS page (1024 - 2 = 1022 wors) is 1022 / (1+3) = words 505 times per page erase. And if you use more pages for FDS this number becomes even larger.

    2. Does softdevice write to flash during connection / events / disconnection phase that may wear out flash during its 9125+ communication periods?

    The SoftDevice itself never writes to flash. But the peer manager library might write to flash, for instance when pairing or bonding, or when a bonded peer reconnected etc. It uses FDS which has wear leveling as explained above, so I cannot imagine it will be a practical problem.

    3. Is there any guideline / best practice on preventing problems related to flash endurance in long run?

    Avoid writing to flash directly if you can. Using FDS for all persistent storage is a good idea in most cases. Don't do FDS garbage collection unless you need to, particularly don't do it after every reset in case it could happen that your device ends up in a loop where it constantly resets (which is of course usually a bad sign for other reasons).

Reply
  • Hi,

    This should not be a problem.

    1. We are using FDS library to write to data to flash. If we write the same value (32-bit word) to the same memory location will it get through and result in a word erase? Which then reducing the life time of the flash? Or will it test and if the same value resides in memory it will skip writing it again?

    FDS is a simple file system, so you cannot use it to write to a specific memory location. That is a good thing in this context. You refer to the data by a file ID and record key, instead of the location. If you update a record, then in practice the old is flagged as dirty/deleted and a new record is written at a different location. In order to reuse the same location again the flash page need to be erased, and that happens when you do a garbage collection, which is typically something you only do when needed.

    I am working on a project that is using nrf52840 chip as a peripheral and the product is supposed to last and run for 25 years. During that period the device will receive connections at least once every day that results in about 25 x 365 = 9125 times. Total up time of the device during the life span is around 300 hours.

    If you only plan to write up to 9125 times that is even within the 10,000 write/erase cycles that is specified for the nRF52840 flash. That said, using FDS you will get a much lower value. FDS has 3 words (12 bytes) overhead per record and 2 (8 bytes) words overhead per page. So if the data is a 32 bit word, the effective number of bytes you can fit in a FDS page (1024 - 2 = 1022 wors) is 1022 / (1+3) = words 505 times per page erase. And if you use more pages for FDS this number becomes even larger.

    2. Does softdevice write to flash during connection / events / disconnection phase that may wear out flash during its 9125+ communication periods?

    The SoftDevice itself never writes to flash. But the peer manager library might write to flash, for instance when pairing or bonding, or when a bonded peer reconnected etc. It uses FDS which has wear leveling as explained above, so I cannot imagine it will be a practical problem.

    3. Is there any guideline / best practice on preventing problems related to flash endurance in long run?

    Avoid writing to flash directly if you can. Using FDS for all persistent storage is a good idea in most cases. Don't do FDS garbage collection unless you need to, particularly don't do it after every reset in case it could happen that your device ends up in a loop where it constantly resets (which is of course usually a bad sign for other reasons).

Children
No Data
Related