Re: Firmware over the air (FOTA) and FCB support in 1.11.0
Hi,toggle quoted messageShow quoted text
As the author of NVS (PR6391
https://github.com/zephyrproject-rtos/zephyr/pull/6391) I am probably
a bit biased. NVS as is can be used directly for managing persistent
data. I am looking into adding NVS as a backend to the configuration
system, but the configuration system comes with a major drawback:
I did a little calculation to compare the configuration system with
FCB as backend to direct use of NVS. Lets make the following
assumptions: Device is nrf51822, flash erase size is 1k, flash erase
cycles is 20000. Flash available for storage is 2k (2 pages). Data
without the sequence number takes up 512 bytes so 512 bytes is
available to store the sequence number.
Now lets see what happens when storing the sequence number, we will
only store it after 8192 messages (this means we only need to store a
11 bit number). This number can be increased but will reduce the
number of reboots that are allowed (to keep the IV index from changing
to fast). The worst case scenario is 24.3 messages/s (see nordicsemi
Calculation for the config system: each store of the sequence number
is a string looking like:
"bt/btmesh/seq=XXXX" which takes up 18 bytes. FCB overhead takes
another 8 bytes, so in total 26 bytes for a write of the sequence
number. After 19 (512/26) writes a sector is full and it will be
erased (using a 1K scratch sector). So with the worst case of 24.3
messages/s: after 19 * 8192 /24.3 s a sector will be erased. Or every
1.78 h. With the erase cycles of 20000 flash will be worn out after
about 4 years.
Calculation for NVS: the sequence number is given an id for storage.
This id is used to differentiate between other data that is stored
(and is part of the NVS overhead). The sequence number takes up only 2
bytes. NVS overhead takes up 8 bytes, so in total 10 bytes for a
write. After 51 (512/10) messages the first page (1k) is full and the
second page is taken into use. After 51 messages the second sector is
full and the first page is erased. So after 102 messages the same page
is erased. With the erase cycle of 20000 flash will be worn out after
about 21.5 years.
Modifying the above assumptions should allow you to get an estimate of
the expected life of your specific application.
To summarize: the configuration system comes at a price, the use of
human readable strings as storage items takes up more space, and
reduces the life of the device.
I am currently working on a solution for the configuration system that
would use NVS as a backend but would also allow some data to be
directly written to NVS. This would allow combination of human
readability for some data with reduced flash wear for other. But the
human readability will always take up more space.