This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

ESB, BLE and FSTORAGE Erase Problems

Project configuration: nRF52832, SDK 12.1, s132

We have a system with ESB, BLE and FStorage for NV access. The system works great with either the ESB and FStorage, or, BLE and FStorage, or even ESB and BLE. However, once we combine all three, a single page erase starts to really drag out and cause problems in the system. In the accompanying timing diagram, the top line is the single page erase, which takes almost 2 seconds. The signal goes high when the fs_erase is called and goes low when the erase added to the FS queue has finally been removed from the queue (same for the write which is represented by the third signal). The write seems to be fine, but the erase consistently has issues in the configuration with all three.

I would like to know what the expected behavior should be for the ESB, BLE and FStorage time slicing. It seems to me that maybe the ESB and BLE (both radio related) have a higher priority in the soft device than the FStorage and that keeps the fstorage request low on the SD scheduling list. Is that a correct interpretation of what I'm seeing?

The documentation says that a page erase should take between 2.05ms to 89.7ms, which is significantly smaller. I saw one that took 2.5 seconds and I saw one that took 1.04 seconds, most though took closer to 2 seconds. Is there a way to mitigate this?

Signal 0 (top): Erase request length

Signal 1:Execution of app scheduler (ESB and BLE + other system events) during erase

Signal 2: Write request length

Signal 3 (bottom):Execution of app scheduler (ESB and BLE + other system events) during write

  • Hi,

    Your understanding is correct. It is not the page erase itself that takes such a long time. However, you have two real time protocols (BLE and ESB in time slots) which the SoftDevice has to schedule time to. That may leave few long enough time windows for a page erase, which it why it can take a long time from you request it until it is actually scheduled. The more BLE and/or ESB activity, the more difficult it is to schedule time for the flash erase. As an experiment you could try to for instance reduce the BLE connection interval and see what affect it has.

Related