This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
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

Mesh and PStorage

I have a problem getting both mesh and persistent storage to work. I am using the code from github.com/.../nRF51-ble-bcast-mesh and followed the document integrating_w_SD_apps.adoc to integrate the mesh code with the softdevice handler in order to use persistent storage. The mesh code now works with the softdevice handler, but in return, persistent storage does not work anymore.

When I try to write to the persistent storage with pstorage_update (or pstorage_store) I receive an error code 13 (timeout) in my pstorage callback handler. If I remove the call to rbc_mesh_sys_evt_handler from my sys_evt_dispatch function, writing to storage works again, but then of course meshing doesn't work anymore. I added some logging and noticed that I get a lot of NRF_EVT_RADIO_BLOCKED sys events. If I remove the respective case from rbc_mesh_sys_evt_handler, storage is working but mesh is not. Same happens if I increase the TIMESLOT_SLOT_EMERGENCY_LENGTH. I either have a working storage or mesh, but not both.

Does anyone have an idea how I can solve this? It seems to me as if the timeslot handler is keeping the softdevice too occupied to handle the storage calls. Can I somehow pause the timeslot handler to give the softdevice time to handle the storage calls? Or can I give the storage a higher priority?

Thanks in advance

  • pstorage_update could take as long as 50ms (read here)

    When you say that if you remove calls to rbc_mesh_sys_evt_handler then writing to storage works. This is a strong proof that pstorage was starved for time. If you want both to work, your mesh sys_evt_handler has to wait for the persistant memory operations to complete (by waiting on pstorage system events)

    pstorage works with SVC calls and SVC calls runs with priority 2 inside the softdevice, you cannot change this.

  • yes I figured it must be something like that, but just delaying the sys event's did not help either. but I did find a solution, if not exactly neat, at least it works

  • As stated by @Aryan, it seems the storage did not get the time to handle the update because the softdevice was busy with radio requests. So my solution to the problem was as follows when trying to write to persistent memory:

    1. call sd_radio_session_close to stop the mesh
    2. wait for the sys event NRF_EVT_RADIO_SESSION_CLOSED
    3. call pstorage_update to store the data
    4. in the pstorage callback handler call timeslot_handler_init to restart the mesh
Related