Handling of errors in access_model_publish()

[Gerry]

Hi,

like described in this post I sometimes get an error = 4 (NO_MEMORY) when calling:

error = access_model_publish(m_clients[0].model_handle, &msg);

How should this be handled? (Ignore, retry with delay, etc)

Is there a way to find out, wether the softdevice is still sending a message and therefore is not ready for the next one?

I'm using the mesh SDK 2.0.1 

Regards

Gerry

[Hung Bui]

Hi Seger, 

When access_model_publish() throw NRF_ERROR_NO_MEM this means there isn't enough buffer for your message and you have to wait for a NRF_MESH_EVT_TX_COMPLETE event before you continue. How often do you call publish command ? Was it a reliable message? 

[Gerry]

Hi,

I call access_model_publish()  as an unreliable message 10 times per second when I get NRF_ERROR_NO_MEM in about 50% of the calls. When using Mesh SDK 1.0.0. I was able to send 20-30 messages per second with the same code without a problem. Is there a signifficant drop in speed using SDK 2.0.1.?

I didn't check the return value when using SDK 1.0.0 but now I get an assert sometimes like described here, so I thought, this could be related to it. What do you think?

Kind regards

    Gerry

[Hung Bui]

Hi, 

 

Are you publishing reliable or unreliable message ? If you have no mem , most likely it was reliable packet not getting ACKed and piled up the stack. 

Could you check what cause assert in core_tx_complete_cb_set() and which error code ? The mesh stack is not a black box, please try to debug when you see an error. 

[Gerry]

Hi Hung

I'm publishing unreliable. the following line causes the assert in core_tx_complete_cb_set() :

NRF_MESH_ASSERT(m_packet.bearer_bitmap == 0);

I didn't find a way to debug this any further, since it only happens during havy communication but I placed a Log-message in front of this line to get the actual m_packet.bearer_bitmap. This suddenly returns 1 instead of 0 when this happens. I'm not publishing in an interrupt. 

What could cause this?

What is the meaning of bearer_bitmap?

[Hung Bui]

HI Seger, 

 

We found that it's an issue with the interrupt priority. If you configure the mesh with NRF_MESH_IRQ_PRIORITY_LOWEST, you should call your mesh API with that priority to avoid the operation being interrupted by other mesh activity. Another option is to set them down to Thread mode. 

Here is the quote from one of our colleague: 

The key points are:

• in mesh_init(), the code set the mesh IRQ priority in “NRF_MESH_IRQ_PRIORITY_LOWEST”
• which means the mesh internal scheduling is using “level 7”
• in mesh SDK, we want all the mesh events are in the same level

• however, if we call the mesh API in the main-context, the interrupt priority will be in “NRF_MESH_IRQ_PRIORITY_THREAD”
• the level is “15”
• the priority level is less critical than the “NRF_MESH_IRQ_PRIORITY_LOWEST”
• which means, the procedure may be “interrupted by other mesh events”, and ruin the mesh stack status

To solve this issue:

1. Please config the mesh IRQ priority in “NRF_MESH_IRQ_PRIORITY_THREAD” instead of “NRF_MESH_IRQ_PRIORITY_LOWEST”
2. So we can make sure all the mesh events have the same priority, and the nest interrupt between mesh events won’t happen
3. And please modify the busy loop in the main() like this:

 

 for (;;)
 {
     if(m_relay)
     {
          simple_on_off_control_send_state(&m_control);
          m_relay=false;
     }
     bool done = nrf_mesh_process();
     if(done)
     {
         sd_app_evt_wait();
     }
}

You can read more about interrupt priority levels here. 

[Gerry]

Thanks for your answer Hung

when I change the .core.irq_priority in mesh_init from NRF_MESH_IRQ_PRIORITY_LOWEST  to NRF_MESH_IRQ_PRIORITY_THREAD I get a problem initializing.

My initialisation:

initialize();
execution_start(start);
init_flash();

.. flash read/write operation

init_uart();
key_update();
provisioner_setup();

In init_falsh(), the line:

ret_code = flash_manager_add(&m_flash_manager, &custom_data_manager_config);

returns 4 (no memory)

Also I have problems with the code, that needs to be added to the main() loop. 

simple_on_off_control_send_state() and m_relay are not defined.

[Hung Bui]

Hi Seger, 

 

I'm not 100% sure why you get no memory. You may need to step into the code and check what throw error 4. 

When you change the priority to Thread mode, you need to update the main loop, please follow the guide here. 

[Gerry]

ok, I did that and found out, that status = NRF_ERROR_NO_MEM happens in m_prepare_for_reserve() on line 145 of packet_buffer.c (SDK 2.0.1) . This line is also hit 2 times before my attempt to add a flash manager. Probably when the stack itself tries to add one.

[Hung Bui]

Hi Seger,

 m_prepare_for_reserve() to get no mem is quite normal if the mesh buffer is full. U just need to retry after a TX_COMPLETE event. 

I'm a bit lost here. We need to sum it up on what exactly you are doing and what would be the issue here. I would suggest you to try using NRF_MESH_IRQ_PRIORITY_THREAD in a unmodified example first. Make sure it works, then continue with your application. 

I don't think we have something called simple_on_off_control_send_state()

[Gerry]

Hung Bui said:

We found that it's an issue with the interrupt priority. If you configure the mesh with NRF_MESH_IRQ_PRIORITY_LOWEST, you should call your mesh API with that priority to avoid the operation being interrupted by other mesh activity. Another option is to set them down to Thread mode.

How about the other option beside Thread mode you mentioned earlier? How to call the API with that priority? What would I have to change to accomplish that?

[Hung Bui]

Hi Seger, 

you would need to call mesh APIs from an interrupt handler. Either your application's hardware interrupt handler (timer for example) or an Software interrupt (SWI) that you generate if you execute from the main loop, please have a look at app_timer.c where we use SWI0 to execute timer start/stop. 

[Gerry]

I finally solved this by using an interrupt callback on the uart instead of polling it in the mainloop