Handling of errors in access_model_publish()

RE: Handling of errors in access_model_publish()

Archana Fugare — Wed, 27 Nov 2019 06:44:06 GMT

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

RE: Handling of errors in access_model_publish()

Gerry — Fri, 10 Aug 2018 08:18:51 GMT

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

RE: Handling of errors in access_model_publish()

Hung Bui — Tue, 24 Jul 2018 16:23:24 GMT

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.

RE: Handling of errors in access_model_publish()

Gerry — Tue, 24 Jul 2018 09:20:48 GMT

[quote userid="2121" url="~/f/nordic-q-a/36268/handling-of-errors-in-access_model_publish/140805"]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.[/quote]

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?

RE: Handling of errors in access_model_publish()

Hung Bui — Mon, 23 Jul 2018 16:52:48 GMT

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()

RE: Handling of errors in access_model_publish()

Gerry — Sun, 22 Jul 2018 12:15:01 GMT

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.

RE: Handling of errors in access_model_publish()

Hung Bui — Sat, 21 Jul 2018 22:43:45 GMT

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.

RE: Handling of errors in access_model_publish()

Gerry — Fri, 20 Jul 2018 12:12:57 GMT

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.

RE: Handling of errors in access_model_publish()

Hung Bui — Fri, 20 Jul 2018 09:31:24 GMT

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:

Please config the mesh IRQ priority in “NRF_MESH_IRQ_PRIORITY_THREAD” instead of “NRF_MESH_IRQ_PRIORITY_LOWEST”
So we can make sure all the mesh events have the same priority, and the nest interrupt between mesh events won’t happen
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.

RE: Handling of errors in access_model_publish()

Gerry — Wed, 18 Jul 2018 09:50:25 GMT

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?

RE: Handling of errors in access_model_publish()

Hung Bui — Mon, 16 Jul 2018 15:56:18 GMT

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.

RE: Handling of errors in access_model_publish()

Gerry — Sat, 14 Jul 2018 17:15:58 GMT

I changed the code to one client now, thanks for pointing this out.

access_model_publish() still returns 4 (NO_MEM) when sending approx. 5-10 messages / Sek (8 Bytes).

Also the assert still happens in core_tx_complete_cb_set()

This didn't happen in SDK 1.0.0. What could be the reason for that?

RE: Handling of errors in access_model_publish()

Hung Bui — Thu, 12 Jul 2018 16:09:03 GMT

No it shouldn't affect when you have the reply from the server. The server replies to the unicast address of the client, so should always receive it, doesn't matter which public address you currently pointing to.

RE: Handling of errors in access_model_publish()

Gerry — Thu, 12 Jul 2018 13:52:55 GMT

Thanks for your answer Hung

I think we don't really need one client per server, so I will eliminate this first and then set CLIENT_MODEL_INSTANCE_COUNT = 1. I only have to change the address using access_model_publish_address_set() when talking to the servers right? Does this affect the callbacks when receiving messages on the client also?

RE: Handling of errors in access_model_publish()

Hung Bui — Thu, 12 Jul 2018 13:10:32 GMT

You are having 21 element (21 client model) on one device ? I would suggest to test using less number of models/element on one device. Do you really need to have one client for each server ? If you have large number of server you want to control, I would suggest to use one single client and change the publication address instead.

Please test and verify you see the issue with stock light switch example.

RE: Handling of errors in access_model_publish()

Gerry — Thu, 12 Jul 2018 11:25:07 GMT

Hi Hung

BEARER_ADV_INT_DEFAULT_MS is set to 20. I didn't change any settings in nrf_mesh_config_bearer.

GATT_PROXY is set to 0, so proxy.h is not included in my project. There's also no changes made to nrf_mesh_config_code. I use standard values and I don't use BLE.

I only changed the settings in nrf_mesh_config_app.h. Could there be the problem?

Here are my settings:

SERVER_COUNT = 20

CLIENT_MODEL_INSTANCE_COUNT = SERVER_COUNT + 1

#define ACCESS_DEFAULT_TTL (SERVER_COUNT > NRF_MESH_TTL_MAX ? NRF_MESH_TTL_MAX : SERVER_COUNT)

#define ACCESS_MODEL_COUNT (1 + /* Configuration client */ \
1 + /* Health client */ \
1 + /* Simple OnOff client (group) */ \
2 + /* remote client */ \
SERVER_COUNT /* Simple OnOff client (per server) */)

#define ACCESS_ELEMENT_COUNT (1 + CLIENT_MODEL_INSTANCE_COUNT)

#define ACCESS_SUBSCRIPTION_LIST_COUNT (ACCESS_MODEL_COUNT)

#define ACCESS_FLASH_PAGE_COUNT (1)

#define ACCESS_RELIABLE_TRANSFER_COUNT (ACCESS_MODEL_COUNT)

#define DSM_SUBNET_MAX (1)
#define DSM_APP_MAX (1)
#define DSM_DEVICE_MAX (SERVER_COUNT) //(SERVER_COUNT)
#define DSM_VIRTUAL_ADDR_MAX (1)
#define DSM_NONVIRTUAL_ADDR_MAX (ACCESS_MODEL_COUNT + 1)
#define DSM_FLASH_PAGE_COUNT (2)

RE: Handling of errors in access_model_publish()

Hung Bui — Thu, 12 Jul 2018 08:38:41 GMT

Hi Gerry,

What was your advertising interval ? Usually it's defined as BEARER_ADV_INT_DEFAULT_MS and equal 20ms.

Do you do any proxy role or BLE ? Could you reproduce the issue with the light switch client&server (not the proxy ones) ?

RE: Handling of errors in access_model_publish()

Gerry — Wed, 11 Jul 2018 14:15:45 GMT

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

RE: Handling of errors in access_model_publish()

Hung Bui — Wed, 11 Jul 2018 13:27:21 GMT

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?