FDS record update increments record ID, and calls event handler twice

[BEplane]

Hello,

SDK: 15.3.0

nRF52840-DK

s140

I have taken the flash_fds_s140_pca10056 example and modified it for our own use. I would like to store versioning information, number of system resets, system on time, and various other system related information that needs to persist between power cycles or resets. I would like to define a single record, and I do not expect or intend to add additional records in the future.

The print out below shows initial start up, and  then a restart. The write is successful (which is creating the record and setting the initial values). Record ID = 1, then the update happens and is successful, but the Record ID = 2. I do not know why the record ID is increasing? This is followed by an  Event: FDS_EVT_UPDATE received (FDS_ERR_NOT_FOUND). After the restart the same behavior occurs and Record ID = 3.  Additionally the Dirty Records after the restart is now 1.

I can not make sense of these behaviors. The code is taken from the example and moved into its own file/functions, but I am following the example closely. 

Why is the record ID increasing?

Why would FDS_EVT_UPDATE occur twice?

In peer_data_storage.c the event handler fds_evt_handler has an empty FDS_EVT_UPDATE case. It is not clear what is needed in the event handler for an update? I have added similar print statements as the example in my version of the event handler with a flag to check for when the update is complete.

FDS example started.
Initializing fds...
Event: FDS_EVT_INIT received (FDS_SUCCESS)
Writing config file...
fds_record_write() Error: FDS_SUCCESS
Event: FDS_EVT_WRITE received (FDS_SUCCESS)
Record ID:	0x0001
File ID:	0xf010
Record key:	0x7010
Reading flash usage statistics...
Found 1 valid records.
Found 0 dirty records (ready to be garbage collected).
Config file found, updating boot count to 0.
config1:	off
config2:	on
boot count:	0
device name:	dummy
Event: FDS_EVT_UPDATE received (FDS_SUCCESS)
Record ID:	0x0002
File ID:	0xf010
Record key:	0x7010
Event: FDS_EVT_UPDATE received (FDS_ERR_NOT_FOUND)

(RESTART)

FDS example started.
Initializing fds...
Event: FDS_EVT_INIT received (FDS_SUCCESS)
Record found, no need to create duplicate
Reading flash usage statistics...
Found 1 valid records.
Found 1 dirty records (ready to be garbage collected).
Config file found, updating boot count to 1.
config1:	off
config2:	on
boot count:	1
device name:	dummy
Event: FDS_EVT_UPDATE received (FDS_SUCCESS)
Record ID:	0x0003
File ID:	0xf010
Record key:	0x7010
Event: FDS_EVT_UPDATE received (FDS_ERR_NOT_FOUND)

[Simonr]

Hi

The record ID (and record key for that matter), are discussed and explained thoroughly in this thread and the thread linked to. I hope this will help you understand why the record ID is increasing.

As for why FDS_EVT_UPDATE occurs twice, that has to be because the update is called twice somewhere in your application whether you're aware of it or not.

Best regards,

Simon

[BEplane]

I did not link any threads in my post, but I have seen both of these threads before and liked them. Also neither of the threads have a definitive explanation to clear up how the Record ID, Record Key, and File Key can be used. Linking to other threads that are not properly answered only creates a web of confusion. This helps no one.

I do not see where the thread speaks about the record ID increasing. Can you explain this in more depth?

tesc said:

That is correct. You have two sets of identifiers, one named file and the other named record, that you can use however you want to "tag" the entries.

File Key, and Record Key, are the identifiers I can use 'however' I would like.

I would like a single structure stored in persistent flash. I would like to update the values of this structure and get the values of the structure. I do not want to create multiple Record IDs, or in other words duplicate data, I only want 1 set of data. Is this possible with the FDS?

Additionally, why is the Record ID Increasing? and does this in fact mean there is a duplicate record?

[Simonr]

Hi Paul

Sorry about causing any confusion, I thought those threads would be helpful, but obviously, they weren't in your case.

So, the reason you're seeing two (and three) record IDs is that the fds_record_update first writes a new record to flash, then deletes the old record. Described in the documentation under fds_record_update This is due to the physical properties of the flash memory, as you are only able to erase full pages, so when you want to update a record you'll have to write a new one and mark the old one as dirty.

 This means that it won't be possible to have just one set of data in the FDS I'm afraid, as the data will technically be duplicated, as it is marked as dirty during an update and will stay until you call a garbage collection. Even though the record and file ID aren't guaranteed to be unique, won't this be sufficient to identify your data correctly? You can alternatively, set your own ID as part of the data for identification.

Best regards,

Simon

[BEplane]

So the Record ID isn't really an ID, but more of a Record Count, or Record Update Count?

And in this case the data wouldnt be considered duplicate, as it is being discarded, or marked as dirty. And the record persists in a different physical memory location, but the record/data is still intended to be the same. The Record ID seems to an internal FDS feature being exposed? It is my understanding that the FDS API is suppose to provide high level functionality for the fstorage. So the valid or expected use of the record ID is unclear?

[Simonr]

Hi Paul

Yes, I guess record count would be a more descriptive name of it. The Record ID is indeed an internal ID used to "keep track of" every record and a way to see where the previous records are written are in relation to one another. It is exposed so that people may use this to keep track of their records as well, but for your specific use case, it seems like file_id and record_key would be better suited.

Best regards,

Simon