NDEF record save location

[T IJ]

Hello DevZone,

For a project I'm using the TAG-4 NFC writeable NDEF message example in my SDK and I had a question if this message is always stored in flash or if it is stored in both flash and RAM.

I am using the NDEF message to communicate to a host and I'm writing/updating quite a few times.

I saw in the datasheet of the NRF52832 that the flash endurance is at least 10k times.

If I write/update my NDEF message 100x per day, does that mean that my device will last roughly 100 days before I have the chance of corrupting data due to flash deterioration? 

Second question, if this is the case, is there a way to store the message in RAM, and periodically write it in flash?

Kind regards 

[Jørgen Holmefjord]

Hi,

The NFCT peripheral always reads/writes directly from/to RAM, see the EasyDMA chapter in the peripheral documentation. Trying to set the packet pointers to an address in flash will cause an error or a Hardfault.

If you want to store the NDEF data in flash, this must be handled in the application, like it is done in the Writable NDEF Message example. Storing the data in flash is totally optional, and it is also up to you to determine how often you want to store the data. The flash-storage is only used for "remembering" the written data between resets, all handling of the data between application and NFCT peripheral happens in RAM.

Note that the example uses FDS for storing data in flash. FDS provides basic wear-leveling techniques, by invalidating records - not erasing, after a new update of the record is stored to another address. This allows you to spread the writes over a larger flash area, compared to writing the same address over and over. The erase operation is initiated by garbage collection, which can be run when FDS is running low on available free space.

Best regards,
Jørgen

[Jørgen Holmefjord]

T IJ said:

When I go to the function I see that it calls the fds_record_update function, which in my perspective updates flash?

Yes, that is correct. This function will save the new record to flash and invalidate the old one.

T IJ said:

Should I comment out this function and only stick with the ndef_file_prepare_record function?

If you do not want to store the record in flash, this should be fine. 

[T IJ]

Thank you very much, I'll implement this and create a separate function for writing it to flash.