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

[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

[Archana Fugare]

Hi,

I am also facing same of mesh assert error if set priority as lowest or thread, could you please help me.

Thanks.

Regards,

  Archana