FDS size and record change

[JohnCC]

Hi,

    I use FDS to save my data. Below is my fds list. All RECORD already have data from factory production.

#define FILE_ID 0x1111
#define RECORD_KEY_TORQUE_0 0x0001
#define RECORD_KEY_W_TORQUE 0x0002
#define RECORD_KEY_I_TORQUE 0x0003
#define RECORD_KEY_UUID 0x0004
#define RECORD_KEY_EMS 0x0005
#define RECORD_KEY_SPINDOWN 0x0006
#define RECORD_KEY_SMT 0x0007
#define RECORD_KEY_ASM 0x0008

My question is 

1. If I create new RECORD (Like #define RECORD_TEMP 0x0009) and update my application by DFU. Will this be a problem? Because my old application have 8 RECORD but new application have 9 RECORD. I'm worried that the original record data will be lost

2. If I keep my RECORD number is 8. But I change one RECORD size. (RECORD_KEY_ASM is 5 words in old application. Then I change 5 words to 6 words in new application). Also update application by DFU. Will this be a problem? Will the original record data be lost?

Thank you.

John.

[Einar Thorsrud]

Hi John,

1. If I create new RECORD (Like #define RECORD_TEMP 0x0009) and update my application by DFU. Will this be a problem? Because my old application have 8 RECORD but new application have 9 RECORD. I'm worried that the original record data will be lost

No, that is no problem. FDS is like a file system and the size of the records does not matter much (as long as there is room in the "file system" and the record not too large to fit in a single page). You can add new records with new keys provided there is available space.

Regarding DFU and FDS data can be lost during a DFU operation if the bootloader is misconfigured and uses the FDS pages for temporary storage. The key here is that the NRF_DFU_APP_DATA_AREA_SIZE is set correctly in the bootloader's sdk_config.h file so that the bootloader never writes to the FDS pages.

2. If I keep my RECORD number is 8. But I change one RECORD size. (RECORD_KEY_ASM is 5 words in old application. Then I change 5 words to 6 words in new application). Also update application by DFU. Will this be a problem? Will the original record data be lost?

This will not cause problems for FDS. It does mean that your application needs to handle the fact that the same record key holds two different types of data, though. But you know the length of the record when you read it so you can distinguish based on that. Intuitively I would think that if you have fixed size records in general it would make more sense to use a new key in this case, but it is entirely up to you and your preferences.

Einar

[JohnCC]

Einar Thorsrud said:

Regarding DFU and FDS data can be lost during a DFU operation if the bootloader is misconfigured and uses the FDS pages for temporary storage. The key here is that the NRF_DFU_APP_DATA_AREA_SIZE is set correctly in the bootloader's sdk_config.h file so that the bootloader never writes to the FDS pages.

So do we have to verify "NRF_DFU_APP_DATA_AREA_SIZE" value in bootloader setting? Or If we use default bootloader sample code in SDK. it's already set, no need to change it

Thank you.

John.

[Einar Thorsrud]

Hi John,

That depends. This needs to match the number of pages you have reserved for FDS in your application sdk_config.h. The default value for NRF_DFU_APP_DATA_AREA_SIZE in the bootloader projects is 12288, which corresponds to 3 pages. And 3 pages is also the default for FDS_VIRTUAL_PAGES in most application examples. If that is the case, then you are good.

Einar

[JohnCC]

Hi Elnar,

       I see. Thank you.