As per mesh_hw_resources.md (MESH_SDK/doc/introduction)
## Flash lifetime
The flash hardware can withstand a limited number of write/erase cycles. As the mesh stack uses the flash to store state across power failures, the device flash will eventually start failing, resulting in unexpected behavior in the mesh stack. As explained in the [flash manager documentation](@ref md_doc_libraries_flash_manager), the flash manager will write new data to the area by allocating a new entry before invalidating the old one. Because of this, the area must be erased periodically.
The #BluetoothMesh uses flash to store the following states:
- Encryption keys
- Mesh addresses
- Access model composition
- Access model configuration
- Network message sequence number
- Network IV index state
- DFU metadata
Assuming that reconfiguration of keys, addresses, and access configuration is rare, the most likely source of flash write exhaustion is the network states.
The network message sequence number is written to flash continuously, in user-configurable blocks.
##########################################################################################################################
To avoid this, solution is to use Super Capacitor with power failure detection circuit & use it as backup source which will work for 10 to 15 seconds to only power nRF52.
If we could design such circuit, with minimum impact on BoM (it should be very compact too ) then we can save Sequence numbers on nRF52 RAM & as soon as power failure detected then we could transfer those data from RAM to in-built FLASH. This is optimal solution to save flash from continuously changing Network Sequence Number.
Could Nordic Semiconductor help me to design this circuit with standard components ?
Or is it best to go with EEPROM like AT24LCxx which support 1,000,000 erase/write cycles to save Sequence Numbers ?
Thanks !!
