RE: Bearer bitmap assert in Mesh

Mttrinh — Wed, 09 Sep 2020 09:55:09 GMT

Hi,

Sorry, seems like I missed the link.

I talked to one of my colleagues and he suspected that this might be because of either:

- inadequate heap allocation in FreeRTOSConfig.h file causing stack corruption in app memory

- some RTOS task of Mesh/App is not with the correct priority.

Hard to say which one is the issue. Can you check?

RE: Bearer bitmap assert in Mesh

Ryjan — Thu, 03 Sep 2020 21:56:42 GMT

I actually referenced that project above. Right now what we dd was consolidate the softdevice task and the mesh task into one task. I'm in the process of testing the stability of that setup.

RE: Bearer bitmap assert in Mesh

Mttrinh — Thu, 03 Sep 2020 13:35:24 GMT

Hi,

We do have an example on Github demonstrating how the Mesh stack can coexist with the FreeRTOS library available in the nRF5 SDK. I will suggest you have a look at that and see if it help you solve the issue.

RE: Bearer bitmap assert in Mesh

Ryjan — Wed, 02 Sep 2020 22:01:26 GMT

A co-worker showed me a thread I had missed in my searches:

https://devzone.nordicsemi.com/f/nordic-q-a/36979/mesh-assert-error-in-m_packet-bearer_bitmap-events

This seems to be addressing this same issues. I theorized today that the m_packet member variable is getting accessed and edited in multiple threads. There is a mesh thread and a BLE thread since my code is based off of this playground example:

https://github.com/NordicPlayground/nrf-mesh-freeRTOS-example

Setting up a mutex to protect the corruption in the m_packet variable was one idea, but it right now I decided to elevate the priority of the BLE thread (the softdevice thread) to above the mesh thread and my initial tests have not caused the assert error and given me reliable operation so far. After reading the second bullet point from the top in the article cited in the link on the 3rd post (see here: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.meshsdk.v2.1.1%2Fmd_doc_getting_started_mesh_interrupt_priorities.html&cp=4_1_0_3_3) it's still confusing if that is the right solution concerning priorities, you can see below:

"The less time-critical parts should run in the same IRQ priority as the user application's low priority code. This can be any priority lower than the SoftDevice API call priority, but it should be the same as the SoftDevice event IRQ handler. When using the nRF5 SDK, this will normally be NRF_MESH_IRQ_PRIORITY_LOWEST (APP_IRQ_PRIORITY_LOWEST). However, if you use the nRF5 SDK's app_scheduler module to run the application from the main loop, the low priority parts of the mesh stack should also run from the main loop."

That page deals with non RTOS related implementation.

Also According to the above mentioned playground project it says:

/** The FreeRTOS task priority used for the Mesh processing task.
 *  Should not have to be modified.
 *  It is important that this is not lower than the priority of the SoftDevice Handler
 *  task in nrf_sdh_freertos.c as that will cause issues with GATT provisioning.
 */
#define MESH_FREERTOS_TASK_PRIO             2

What I tried to fix this is in violation of this warning, I boosted the BLE thread to 3, making it higher and because the bearer_bitmap field is not being corrupted like it often was at the end of provisioning. It sounds like what I have done is not a good solution, so what may be better for this FreeRTOS implementation?