fs_event_handler callback is delayed

[Sawada]

It takes time for fs_event_handler to be called back after nrf_fstorage_erase is executed.

In SDK13.1.0, it didn't take much time, but in SDK15.3.0 currently being developed, it takes time to be called back.

The priority cannot be set in the fstorage config of SDK15.3.0.
It is assumed that there is a delay due to not setting here.

*SDK13.1.0 
    FS_REGISTER_CFG(fs_config_t fs_config) =
    {
        .callback = fs_event_handler,
        .num_pages = PDL_PAGE_NUM,
        // We register with the highest priority in order to be assigned
        // the pages with the highest memory address (closest to the bootloader).
        .priority = 0xFE //***************this config*****************//
    };

*SDK15.3.0
    NRF_FSTORAGE_DEF(nrf_fstorage_t fs_mainte_config) =
    {
        .evt_handler = fs_event_handler,
        .start_addr = 0xD5000,
        .end_addr = 0xF6000,
    };

[Sawada]

Is there any alternative to "priority" in 15.3.0?

[Susheel Nuguru]

no, there does not seem to priority concept in fstorage, 

Do you know what is the context priority in which you are calling nrf_fstorage_erase? are you calling it from main thread or some interrupt priority? Can you also post us the difference in the time it takes between SDK13.1 and SDK15.3.

[Sawada]

>>Do you know what is the context priority in which you are calling nrf_fstorage_erase? 

No.

Immediately after the main thread started, we called the following in each SDK version and measured the time until the handler was executed.

SDK15.3: nrf_fstorage_erase()
-> 4 second
SDK13.1: fs_erase()
->0.2 second

[Susheel Nuguru]

Since there is no concept of priority now in fstorage, the call will inherit the priority of the caller, so the timing must have changed in your app.

which version of fstorage backend instance are you using?

If you are using NVMC, then we can try to bump up the priority by using EGU interrupt and make sure that your fstorage call is executed in a bit higher priority.

[Sawada]

I used "nrf_fstorage_sd.c".

[Sawada]

It is unclear why there is a time difference in the SDK.
Are there any other factors that could make a difference?
I want to shorten the erase time with SDK15.3.

[Susheel Nuguru]

I am not sure what has changed. I am not able to reproduce this in SDK15.3

Some else had a similar problem like you so I had to test this on my desk.

On nRF52832 (PCA10040 DK), with BLE connection established with HRS example, I saw diff as 2 ticks 

And with nRF52840 (PCA10056 DK), with BLE connection established with the same HRS example, it is same 2 RTC ticks as below

I am guessing that the difference in timing is something to do with the other contexts running in your app, interrupting your measurement. 

Can I suggest you do another measurement like below on both 52832 and 52840, but this time disable the application interrupts by executing the below code in critical section.

CRITICAL_REGION_ENTER() 
uint32_t start = nrf_drv_rtc_counter_get(&rtc);

nrf_fstorage_write(&rc_fs_instance, (uint32_t)addr, val, 4, NULL);

uint32_t finish = nrf_drv_rtc_counter_get(&rtc);
CRITICAL_REGION_EXIT() 

I am thinking that the problem is that some other context has gained priority between the SDK, due to the default values in the sdk_config.h being changed.