On a device that is pretty sensitive to lag (with a display and HW drivers), I observe sometimes some lags of about 100 ms.
I tried to disable some part of code to see what component could cause this lag and I found that if I stopped writing to FDS, I remove these lags !By reading the nrf52840 datashet, I saw "The CPU is halted if the CPU executes code from the flash while the NVMC is writing to the flash.", which is 85 ms so could be exactly the root cause of what I observe.
So my questions are:
I also read from another post that this CPU halted for 85 ms could also result to miss some I/O interrupts. This sound a little scary to me. Anyone else experiencing similar issues ?
ThierryC said:Is it possible that FDS write can causes lags of about 85 ms ?
Yes. See "erase time" in datasheet.
No, you cannot really prevent that since the device needs to be able to store data according to bluetooth spec.
If your device is that sensitive to lag, try the dual core (NRF5340).
FDS is doing erase operation only if there is no empty space to write a new record. You cannot eliminate these lags, but you can make them more predictable by calling fds_gc() when your app allows (there are no critical tasks). Garbage collection can take a long (up to few seconds), but then all new records will be written without lag until all reclaimed space is filled. You can use fds_stat() to estimate the time left to next garbage collecition.