This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Need more clarity on FDS Module with respect o File Id, Record id and Record key

Hi Team,

Need help on FDS module, , my need is to Read/write the some of the crypto related keys and session values to some fixed database.

we have come across the FDS example, here we have some queries on this

We have list of 30 different variables which includes 32bit, 16bit and arrays ,total size is less than 512 bytes. To store these values on runtime in FDS what the steps needed for us, i am listing out here , please correct me anything is wrong,

 1. First we need to create unique "File_ID" and "Record_key" for each variable.

 2 .We need to write the each variable in FDS with corresponding "File_ID " and "Record_key".

 3. We Read the same variables by using same combination of File Id and Record_key.

 4. What is the use of "Record_id" in FDS example apart from "Record_key".

 5. When to run the Garbage collector and how to run, is there any specific API for that or it will take care automatically by FDS itself when we remove any one record.

 6. What is the Max and Min size of each "Data Record" in one FDS Page/File.

 7. what is the Maximum size for each FDS File/Page like 1k or 4k bytes.

 8. Can we run the FDS  with out registering the  "fds_evt_handler" or it  is mandatory in my main application means no need to give commands from Putty or some other terminals.

 9. Can we do Successive Write/Read operations at a time without loss of data OR we need to wait for some time on each write/Read operation.

If any one gives me replay on high priority it is very help full to us. Needs to implement the same within 3 days in my app.

Regards,

Srinivas.V

Parents
  • Hi, 

    Your steps 1-3 are correct. 

    I assume you have read the documentation here: 
    https://infocenter.nordicsemi.com/topic/sdk_nrf5_v16.0.0/lib_fds_functionality.html?cp=7_1_3_56_1
    https://infocenter.nordicsemi.com/topic/sdk_nrf5_v16.0.0/lib_fds_format.html?cp=7_1_3_56_2

    4. The Record ID and File ID can be the same for many record, so the system need a unique ID for each of the record. That's the use of record_ID. You can find the explanation from the author of fds here: https://devzone.nordicsemi.com/f/nordic-q-a/47587/difference-between-fds-record-key-and-record-id

    5. You can wait for FDS_ERR_NO_SPACE_IN_FLASH event and then call gc collection, you need to repeat the write (that couldn't executed because flash was full) again. Or you can call fds_stat to monitor the current condition and decide to run garbage collection. 

    6. 1019 words = 4076 bytes https://infocenter.nordicsemi.com/topic/sdk_nrf5_v16.0.0/lib_fds_format.html?cp=7_1_3_56_27. 

    7. I don't think there is a limit on the File. 

    8. It's not mandatory but you would need that handle to catch the event to know when the record is written/erased etc

    9. There is a queue, but you need to check if it's queued successfully or not. Check the return code when you call fds_record_update/write/delete. And also check the event in fds_evt_handler to see if it successfully written/update/deleted or not. But you don't need to wait for event before you do the next command. 

  • Hi Bui,

    Thanks for your valuable reply. It is very much helpful to us. I need small clarification on Fild id.

    1. We have segregated our data into 10 records, and what we dis is we are writing the data for each record based on unique Record key and File ID.

    2. Each data record have unique Record_key , but File Id we are maintaining common for all the records.

     Eg:

         #define FDS_FILE_ID                                                                                   0x0000
       

       #define FLA_KBOX_ADDR_KEY                                                                  0x0001          //16 bytes
      #define FLA_KSYS_ADDR_KEY                                                                   0x0010          //16 bytes 
      #define FLA_KOLD_ADDR_KEY                                                                   0x0020          //16 bytes
      #define FDS_KSYS_kOLD_ROLLOVER_DATA_KEY                                  0x0030          //8 bytes
      #define FDS_BEACON_DATA_KEY                                                             0x0040           //8 bytes
      #define FDS_FAMILY_PROD_CODE_BAD_KEY_DATA_KEY                    0x0050          //8 bytes
      #define FDS_RTC_MAX_KEY_TRANS_CHAR_KEY                                  0x0060           / /12 bytes
      #define FDS_TZONE_IBECPOW_MFG_ID_LOCK_CAPB_KEY                 0x0070          //8 bytes 

    The above example is  fine or we need to maintain separate File ID for each record.

    3. On start up if we want to write the all the records data at first time , can we write all at a time sequentially or how to design this one.Second time on wards we will write only updated record, first time how deal all the records data to FDS.

    4 .When we need to use Write()  and update() functions to modified the data record.

    Regards,

    Srinivas.V

  • Hi Srinivas, 

    2. It's fine to have same File ID.

    3. You can just write them sequentially. First check that fds_record_write() return NRF_SUCCESS. And then check the event FDS_EVT_WRITE  inside fds_evt_handler() to make sure that the record is written correctly. 

    4. After you have the record written first time with fds_record_write() and you want to update its value, please use fds_record_update() instead of fds_record_write().

    If you use fds_record_write() for a record that's already in the flash, a new version of the record will be created. Meaning you will have multiple of records having the same Record ID and File ID. 

    This applied even after a reboot. So you better check if the record is already in flash before writing a new one using fds_record_find()

Reply
  • Hi Srinivas, 

    2. It's fine to have same File ID.

    3. You can just write them sequentially. First check that fds_record_write() return NRF_SUCCESS. And then check the event FDS_EVT_WRITE  inside fds_evt_handler() to make sure that the record is written correctly. 

    4. After you have the record written first time with fds_record_write() and you want to update its value, please use fds_record_update() instead of fds_record_write().

    If you use fds_record_write() for a record that's already in the flash, a new version of the record will be created. Meaning you will have multiple of records having the same Record ID and File ID. 

    This applied even after a reboot. So you better check if the record is already in flash before writing a new one using fds_record_find()

Children
No Data
Related