Escape flash_manager_wait recursion mesh assert

[rmarques]

I am currently using Mesh SDK 4.2.0 and I could successfully write and read reliably from the flash using a second flash manager instance used in parallel with the flash manager instance used by the Mesh stack.

flash_manager_wait() is being called in my app before almost if not all operations with the flash, namely when I use flash_manager_entry_read or flash_manager_entry_commit. I am running into a mesh_assert problem that points me to a recursion check on bearer_event.c, line 370: NRF_MESH_ASSERT(!s_recursion_guard);

It seems as this is a known problem as the lines above have the following contents: "TODO: The recursion guard can be removed when the call to bearer_event_handler() is removed from flash_manager_wait()."

What are the operations that require a call for flash_manager_wait()? Is there is a way to escape this mesh assert by not waiting for the flash to be free if it is already waiting? (I suppose this is the problem)

Should I just place a while (!flash_manager_is_stable()){} in place of all calls for flash_manager_wait()? Is this the correct thing to do when using a second flash manager instance?

[Hung Bui]

Hi, 

Could you give me some more information on how you use flash_manager_wait() ? 

It's actually not suggested to use the flash manager module directly, instead it's suggested to use mesh configuration to store application data. 

You can find an example of using mesh config in our enocean_switch example. 

[rmarques]

The problem was solved by only calling flash_manager_wait before flash_manager_entry_read and flash_manager_entry_invalidate. If I call flash_manager_entry_alloc and flash_manager_entry_commit when updating an entry (right after flash_manager_entry_invalidate), it seems like flash_manager_wait can be omitted, and actually triggers an assert if called before flash_manager_entry_commit.

I wasn't aware of the mesh configuration module nor that it is not suggested to use flash manager directly. I will take a look at mesh configuration module to see if it is easier to refactor or keep using flash manager directly for now. Thank you.

EDIT: Actually, I would suggest adding an entry to the documentation of the flash manager module that redirects us to the mesh configuration module as the proper API to use for storing persistent data on the chips.

[Hung Bui]

Hi Marques, 
Yes, I agree that it should be more clear on that. I will give the feedback to the Mesh team.