Bearer bitmap assert in Mesh

[Ryjan]

I'm developing a Bluetooth mesh device on a Window 10 machine using Segger Embedded Studio v4.52c on a nRF52832 chip using SDK16.0.0, Mesh SDK 4.1.0 and FreeRTOS.

in the core_tx.c file I get an assert on line 105 if the m_packet.bearer_bitmap == 0. This seems to happen quite often but not all the time. I'm having a hard time figuring out what the cause is and how to fix it. This assert occurs when a provisioning device is updating parameters from the device. At first I thought that it was memory corruption because of RTOS stacks overlapping since the device was out of RAM. I have since freed up a lot of RAM and I think that eliminated that as a cause. I haven't determined that exact use for that bearer_bitmap and what controls it, so any help on how it works and what should clear it would help me out.

core_tx_bearer_bitmap_t core_tx_packet_alloc(const core_tx_alloc_params_t * p_params, uint8_t ** pp_packet)
{
    NRF_MESH_ASSERT(p_params != NULL);
    NRF_MESH_ASSERT(pp_packet != NULL);
    NRF_MESH_ASSERT(p_params->role < CORE_TX_ROLE_COUNT);
--> NRF_MESH_ASSERT(m_packet.bearer_bitmap == 0); <-------------------------------------------------
    NRF_MESH_ASSERT(p_params->net_packet_len <= sizeof(m_packet.buffer));

[Ryjan]

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?