writing to flash nRF52810

[Vojislav]

Hi, 

I have developed an application for nrf52810 and now it needs an additional feature of saving several integer values to flash, so they are available even after power loss. 
Besides the application, there is a bootloader, softdevice, and bl_settings in memory. My question is if it is possible to do this with the memory that is left?
I know there is a limitation on minimal memory required to do this. Currently, as I see there are 33533 bytes free.
And if this is possible what is the preferred way to do this. 

I am working with nRF5SDK v15.3.0

Best regards,
Vojislav.

[tesc]

Hi,

You do have a couple of options.

First, please note that with flash the write operations work by flipping individual bits from 1 to 0, but in order to flip bits back to 1 you must erase the full flash page (4 kB on the nRF52).

The go-to-solution in the nRF5 SDK is Flash Data Storage (FDS), which lets you store "records" in flash, where a "record" is a series of bytes tagged with a "file id" and a "record key" for organizing. It allows for writing, updating, reading and deleting records by lookup on "file id", "record key", or both. This abstracts away the details of working directly with flash. You can read more on Infocenter: Flash Data Storage.

If you would rather operate more directly on flash, but still have a higher-level API, you can use Flash Storage (fstorage). As a side note, FDS is built on top of fstorage. Another alternative is direct flash access through the SoftDevice API.

Please note that most examples in the SDK use the Peer Manager library for handling BLE bonds with other devices. In that case the easiest is by far to use FDS, as FDS is already in place and in use by Peer Manager.

The place to store application data in flash is described in the Memory layout section of the bootloader documentation. It is part of the "Aplication area (incl. free space)", and can be seen at the top of the application area in the figure, labelled "Application data". The DFU bootloader will keep an amount of data below NRF_UICR_BOOTLOADER_START_ADDR according to APP_DATA_RESERVED. See the Preserving application data section of the Dual-bank and single-bank updates documentation.

Regards,
Terje

[Vojislav]

Hi tesc,

Thanks for the detailed reply. I think the FDS will do the job. My main concern was if have enough space to do FDS, and now I think it would be ok since there is ~33kB free space and one flash page (4kB) is more than enough to store all data I need. 

Best regards,
Vojislav. 

[tesc]

Hi,

Yes, you should have more than enough space. FDS needs one page for swap, and the rest of the FDS pages are data pages. In our SDK, the examples typically use 3-4 pages total for FDS.

For calculations on how much space you need, note that FDS flash pages has a 8 byte page header, and each record have a header of 12 bytes followed by the actual data. Typically you want to be able to update records for some time before having to do garbage collection. Each update means an existing record is invalidated (but still taking the same flash space) and a new (valid) record is written with same file id / record key.

Regards,
Terje

[Vojislav]

Hi, 

Thank you, I will keep that in mind. 

Best regards,
Vojislav.