This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Handling of errors in access_model_publish()

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

  • 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? 

  • 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

  • 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) ? 

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

  • 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.

Related