How to manage the data integrity using Settings API when erase/write cycle value is reached?

[Amudhan R]

In our current development we are using NRF52840DK and the external memory MX25R6435F. We are using Settings API to store some configurations on the external memory partition to persist the values (1MB for settings). As per the data sheet of MX25R6435F, the erase/write cycle is 100,000.

In our project we are planning to store a certain values in a interval of lets say 1 minute. In this case the data can be retained upto 1.2 years. If we want this cycle to be every 30 seconds then the data retention reduce to around 7 months.

Currently I don't see any information related to how this erase/program cycle can be handled in Settings API.

Is the Settings API capable of moving the data locations once it is become bad or reached the erase/write cycles reached?

Here is the part of overlay config

/ {
    chosen {
        nordic,pm-ext-flash = &mx25r64_ext;
    };
};




&qspi {
    status = "okay";
    pinctrl-0 = <&qspi_default>;
    pinctrl-1 = <&qspi_sleep>;
    pinctrl-names = "default", "sleep";
    mx25r64_ext: mx25r6435f@0 {
        compatible = "nordic,qspi-nor";
        reg = <0>;
        /* MX25R64 supports only pp and pp4io */
        writeoc = "pp4io";
        /* MX25R64 supports all readoc options */
        readoc = "read4io";
        sck-frequency = <8000000>;
        jedec-id = [ c2 28 17  ];
        size = <67108864>;
    };
};

Here is the prj.conf:

CONFIG_PRINTK=y
CONFIG_LOG=y
CONFIG_CBPRINTF_FP_SUPPORT=y
CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=y

CONFIG_I2C=y
CONFIG_PWM=y
CONFIG_JSON_LIBRARY=y


CONFIG_GPIO=y
CONFIG_BT=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DEVICE_NAME="WIDGET"
CONFIG_BT_EXT_ADV=y
CONFIG_BT_SMP=y
CONFIG_BT_BONDABLE=n
CONFIG_BT_FIXED_PASSKEY=y
CONFIG_MCUMGR_GRP_ZBASIC=y
CONFIG_MCUMGR_GRP_ZBASIC_STORAGE_ERASE=n

CONFIG_BT_BUF_ACL_RX_SIZE=517
CONFIG_BT_L2CAP_TX_MTU= 517
CONFIG_BT_BUF_ACL_TX_SIZE=517
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_RX_STACK_SIZE=2048

CONFIG_SENSOR=y

CONFIG_FLASH=y
CONFIG_NVS=y
CONFIG_SETTINGS=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_SETTINGS_RUNTIME=y
#
# External FLASH as Storage Partition
CONFIG_NORDIC_QSPI_NOR=y
CONFIG_PM_PARTITION_REGION_SETTINGS_STORAGE_EXTERNAL=y
CONFIG_PM_PARTITION_SIZE_SETTINGS_STORAGE=0x100000
CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY=n
#Enable MCUBOOT bootloader build in the application
CONFIG_BOOTLOADER_MCUBOOT=y
#Include MCUMGR and the dependencies in the build
CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y
CONFIG_MCUBOOT_BOOTLOADER_MODE_OVERWRITE_ONLY=y
CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU_VALIDATION=y
CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU_SPEEDUP=y
#Improve read/write performance to/from External flash
CONFIG_SETTINGS_NVS_NAME_CACHE=y
CONFIG_NVS_LOOKUP_CACHE=y
CONFIG_NVS_LOOKUP_CACHE_FOR_SETTINGS=y
CONFIG_NVS_LOOKUP_CACHE_SIZE=1024

[Elfving]

Hello,

First of all, what I mentioned in this previous case might be interesting to you. As well as this case which I just found. 

So the settings API uses NVS by default.

Is the Settings API capable of moving the data locations once it is become bad or reached the erase/write cycles reached?

What you describe here is what I would say is one of the main features of Flash circular buffer (FCB), even though it doesn't move when an area has gone bad per se, it just spreads out the wear. Though as you can see there in the docs, NVS is recommended. I'll look into why that is. 

Regards,

Elfving

[Amudhan R]

So far from the pages you shared, I understood that the data integrity is handled by Settings/NVS and not to worry about the write/erase cycle.

This is a big concern for our project because we need to persist the device total power-on time. This will be a key factor to replace the device after some years let's say 6 years of power on.

I thought of creating multiple partitions (lets say 4 partitions) each have 1 MB on the External flash and dynamically move the Settings partition to next partition once it reached the write/erase cycles (100,000 times). 

I am not seeing any documentation on to move the setting partitions dynamically to different location during boot or on the fly. 

[Elfving]

Amudhan R said:

This is a big concern for our project because we need to persist the device total power-on time. This will be a key factor to replace the device after some years let's say 6 years of power on.

Could yuo expand a bit more on the use-case? Is the problem that at one point in the future, the device will fail, and at which point you want to retrieve it and figure out how long it has been online? And this accuracy needs to be within 60-30 seconds?

You could buffer more in the application between each time you write to flash.

Amudhan R said:

I am not seeing any documentation on to move the setting partitions dynamically to different location during boot or on the fly. 

I suspect that we do not have any samples or documentation for this exact scenario, but that should work. Though this is essentially what FCB would do as well.

Regards,

Elfving