Mesh assert error in m_packet.bearer_bitmap events

[Chaabane]

Hello,

I'm using mesh 2.0.1 to test message sending between 2 nRF52840 DK boards.

I'm using a task from FreeRTOS kernel to send messages from the node to the provisionner.

I get an assert because of m_packet.bearer_bitmap is set after sending few messages ( 70, 111 or 200...etc). messages are sent each 2 seconds

I have setup the mesh irq priority to NRF_MESH_IRQ_PRIORITY_LOWEST.

I'm using uint32_t access_model_publish(access_model_handle_t handle, const access_message_tx_t * p_message) to send the messages.

The stack shows that the core_tx_packet_alloc() when the assert happens is call from the QDEC_IRQHandler

I tried to check m_packet.bearer_bitmap before sending data but this didn't help ?

 

Is there a solution to avoid this kind of issue ?

Thank you

[Chaabane]

I disabled FreeRTOS and I used timre1 to send messages with access_model_publish() every seconde and it is working with now issues.

The timer interrupt priority is set to 7.

I also reduced message size from 13 to 5 and it works with no problem !

[Hung Bui]

Hi, 

We haven't tested Mesh with FreeRTOS so we don't know what could be wrong. 

But if you use NRF_MESH_IRQ_PRIORITY_LOWEST, you should only call the mesh API from an interrupt handler with NRF_MESH_IRQ_PRIORITY_LOWEST, not from main loop. Please have a look here. This most likely the reason why you receive m_packet.bearer_bitmap issue. 

 

 

 

 

[Chaabane]

Thank you for the feedback. I have already looked in the link you mentioned above and I have few questions:  

from the link :

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.

SoftDevice event IRQ handler priority is set in 

sd_nvic_SetPriority(SD_EVT_IRQn, NRF_MESH_IRQ_PRIORITY_LOWEST)

But I can't find the priority level of the SoftDevice API call ?

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.

In the light switch example, there is only sd_app_evt_wait() in the main loop which only handle BLE event if my understanding is correct. All the mesh events are handled in the EVENT_IRQHandler() interrupt ?

If I want to handle all mesh events in the main loop, How can this be achieved ?

Thank you 

Chaabane

[Hung Bui]

Hi Chaabane, 

 

The softdevice API calls priority is defined in the Softdevice spec, Please look for "Interrupt model " chapter. In S132 v6.0 it's level 4. 

This part it's more about the "The less time-critical parts " of the mesh stack, not about the softdevice here. Any function the application call to mesh stack, are considered "the less time-critical parts " of the stack. 

If you want to handle in the main loop please use NRF_MESH_IRQ_PRIORITY_THREAD when you declare Mesh in nrf_mesh_init(). Make sure you followed the instruction in the link I sent. 

[Chaabane]

I'm trying to do handle everything thing in the main loop as suggested.

The APP_SCHED_INIT() function requires the event size and the queue size.

For the queue size I put 10 as I can see the BEARER_EVENT_FLAG_COUNT is 8.

For the event size I put sizeof(nrf_mesh_evt_handler_t), not sure if it's enough to cover all the mesh events ?

Is this correct ?

Also, I'm having hardfault error in the provisioner and noticed that there is app_mesh_core_event_cb() tha thandle flash  events, should this be handled int the nrf_mesh_process() aswell ?