nRF5 SDK is not maintained anymore
More Info: Consider nRF Connect SDK for new designs
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

nRF51822 fds storage: Issue with fds_record_write

Hello everyone! Wave

We are using nRF51822 SoC together with s130 Softdevice. nRF5 SDK v12.3.0 is used for firmware development together with the Segger Embedded Studio.

Among the other things, we have a need to store one 32-bit variable in non-volatile flash memory. Consequently, we decided to use Flash Data Storage (FDS) for that purpose.

We can properly initialize the FDS module by using:

ret_code_t ret = fds_register(fds_evt_handler);
if (ret != FDS_SUCCESS)
{
    // Registering of the event handler has failed.
}
ret_code_t ret = fds_init();
if (ret != FDS_SUCCESS)
{
    // Handle error.
}

as it is described here.

However, the trouble comes when we want to write a record to the flash with the fds_record_write() function (link). The function returns FDS_SUCCESS which implies that the write record operation was queued successfully but we never get the FDS_EVT_WRITE event inside the event handler (fds_evt_handler()).

Do you have any idea what we are missing here? We are using FDS in combination with the Softdevice. Perhaps that can be an issue? Do we need any particular SES settings that will enable FDS storage?

Here attached you can find nvs_storage.c/h modules that contain FDS-related code. As you can see, when we call the init_nvs_storage() function for the very first time, there will be no record in the flash, and create_blank_ouid_records() function will be called. Within that function, we try to call fds_record_write() that returns FDS_SUCCESS but FDS_EVT_WRITE event is never detected inside the event handler (fds_evt_handler()).

Thanks in advance for your time and efforts. Looking forward to hearing from you.

Cheers!  Beers

Bojan.

Parents
  • Hey, guys... here are some additional pieces of information:

    • when I initialize the FDS module AFTER initializing the Bluetooth module (gap, advertising, gatt, services, connection parameters), then I am able to properly write an initial value to the flash by using fds_record_write() function. FDS_EVT_WRITE event is properly detected.
    • However, when I establish BLE connection with the Central device and want to update the flash with fds_record_write() or fds_record_update() functions then write/update record operation was queued successfully but we never get the FDS_EVT_WRITE/UPDATE event inside the event handler.

    It seems to me that the FDS module has some limitations when used in the presence of the Softdevice. I know that the Peer Manager is also using FDS. Is there anything we should do to make the FDS module works together with the Softdevice?

    Some threads that are reporting similar issue (e.g. link1, link2) suggest including ${SDK_ROOT}/components/softdevice/common/nrf_sdh_soc.c file in the build. However, nRF5 SDK v12.3.0 does not contain that file. Is there anything similar we should include?

    Regards,

    Bojan.

  • Hello,

    Flash operations have very low priority compared to other softdevice taks:
    https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s130.sds/dita/softdevices/s130/multilink_scheduling/priorities_and_events_intro.html 

    So, it may take considerably time before the flash operation completes or it can even timeout if the softdevice is not able to execute the flash operation due to other higher priority activities. What you can try is to for instance configure FS_OP_MAX_RETRIES to 1000, that should at least give more retries before it "give up". 

    To give the softdevice time to execute flash operations, it may help to increase the connection interval, and at least use slave latency on the link, since this will allow connection intervals to be skipped (e.g. to handle flash operations if needed).

    Best regards,
    Kenneth

Reply Children
  • Thanks for the suggestions, Kenneth!

    Changing FS_OP_MAX_RETRIES or connection interval parameters did not resolve the issue.

    What resolved the issue is putting the event into the scheduler queue with app_sched_event_put() API.

    Writing into the FDS from withing scheduler handler function did the job for us!

    Thanks in advance for your hints! I think we can close the ticket now.

    Cheers,

    Bojan.

Related