What triggers flash write after fds_record_write() is called?

[Prasad]

I found this comment in fds.h as function header for fds_record_write()

 * Record data can consist of multiple chunks. The data must be aligned to a 4 byte boundary, and
 * because it is not buffered internally, it must be kept in memory until the callback for the
 * operation has been received. The length of the data must not exceed @ref FDS_VIRTUAL_PAGE_SIZE
 * words minus 14 bytes.

It says that data must be kept in the buffer till the callback is received. I am interested in knowing what triggers the actual flash write? Can I trigger it through my code? I want the write to be synchronous as the writes are not going to be too often, is there are way to do it?

[Jørgen Holmefjord]

Hi,

From the SDK documentation on FDS and Fstorage, the following can be read:

FDS uses Experimental: Flash Storage as backend to write to flash. Flash Storage, in turn, relies on the SoftDevice to execute the write. Flash Data Storage supports synchronous read operations and asynchronous writes.

and:

Flash Storage (or fstorage for short) is a module for storing and erasing data in persistent flash storage. The module serves as a wrapper around the SoftDevice flash API. It accepts requests to store data or erase data pages and queues these requests up for asynchronous handling. The application is notified of the operation results through callbacks to registered event handlers.

Fstorage automatically splits up large writes and erases into smaller operations, thus enabling the SoftDevice to handle these requests between radio operations. Failed flash operations that are not accepted or not scheduled by the SoftDevice are retried.

Access to the flash (NVMC) is restricted when using a softdevice, meaning you need to use the softdevice API to access it. This means that you can't do synchronous writes to flash when using a softdevice. You can read more about BLE and flash operations here.

Best regards,

Jørgen