Logging interval data into flash memory. FDS or fstorage? Wear levelling?

[coyodha]

Hi Nordic DevTeam,

I am using nRF52840 (1MB Flash, 256kB RAM). I would like to store a log data to flash memory that I can extract them to my Android phone later on when connected. I have concern about the 10,000 write cycle of the nrRF52, I have to write this frequently to the flash.

Let's say after I allocate bootloader, SD s140 library and application (total : ~250kB in flash).  I expect the device to last 5-6 years and I allocate 500kB just for logging purposes and continuously log data every 1 minute when the device is on in csv format : eg. "time, voltage, current, etc." (let's say 40 Bytes each minute). Before I save to flash, I will allocate this data in RAM first (maybe fixed-sized array of 50kB), and whenever the allocated RAM is almost full or the device is about to be turned off. I will write this RAM data into the flash page, using the FDS library provided it has the wear-levelling mechanism in the background. My understanding is the bigger the flash allocated to it, wear-levelling will be more effective as there are more probability to use unused space to store data.

Does my implementation make sense in this case considering the write cycle of the flash?

Would it be recommended to log and save logged data into internal flash memory or would I really need external flash memory like SD Card?

[coyodha]

Hi Einar,

I also learned about this amounts of block allowed to be written in between erase -> nWrite = 181 or is it 2 (based on this data sheet) ?

https://devzone.nordicsemi.com/f/nordic-q-a/11357/nrf52-flash-programming-writes-in-a-block-between-erase

https://devzone.noricsemi.com/f/nordic-q-a/15798/flash-endurance-on-nrf52

Should I be worried about this? Is this handled by the nrf_fstorage_sd ?

My plan right now is I will allocate 500kB of flash memory (128 virtual pages) and write 3 types of data file :

1. 0x01 (CONFIG_FILE_ID) -> write 4B + 12B (header) with same key ID every 5 minutes (maybe I will write this data under flash reserved page so it doesn't get deleted and just perform fds_gc on this flash page)

2. 0x02 (DATA_FILE_ID_1) -> write 240B + 12B (header) with new key ID every 20 minutes

3. 0x03 (DATA_FILE_ID_2) -> write 6B + 12B (header) with new key ID every 15 minutes

Just let all these keep writing until the flash amount has no space, then perform erase flash for the entire allocated flash.

Would this be a reasonable approach if I expect the device to run for at least 5-6 years assuming it runs all the time until flash reach 10,000 erase/write cycles?

[Einar Thorsrud]

Hi,

This is handled by FDS, which does not write more than 2 times to the same word.  (And the only that is written to more than once is the record header when it is invalidated, which would be the second write).

The limitation to the number of writes per block is also not an issue, as each page is split in 8 blocks, and you can write up to 181 times per block (so per 0x1000 words / 8 = 512 words. Given that you have 3 words overhead per record it is not a limit it is possible to reach in practice.

The approach you describe here is sensible and will give a minimal flash wear.