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

Mesh Error 4 (and Mesh Error 5) in Bluetooth Mesh application.

Dear DevZone community,

I'm developing a Mesh application using nRF52840, I'm developing with both the Nordic development kit (BOARD_PCA10056) and USB dongle (BOARD_PCA10059) and using Segger Embedded Studio (SES) in Linux. I'm using version 15.2.0 of the SDK and version 3.1.0 of the Mesh SDK.

I've been trying to solve this error for over a day now. I've read every forum entry on "Mesh Error 4" and similar, that I could find, and tried all the suggested solutions to no avail.

The situation is this: I've written a simple sensor Bluetooth mesh model, a vendor model which I have thoroughly tested and it works for both the server and client versions. I took the Light Switch example and rewrote the app side of things and all the necessary source and header files to integrate the new model, which substituted the Generic OnOff model in the original Nordic example.

Now I've taken the Light Switch example and integrated the simple sensor model with the Generic OnOff.  I had no issues doing this with the Client version, I could exchange messages and data between this client and generic onoff servers, and simple sensor servers. No issues with that.

The issue is only happening in the Server side in main.c file. When I instantiate an initialize both models like so:

static void app_model_init(void)
{
    /* Instantiate Simple Sensors server on element index APP_SSENSORS_ELEMENT_INDEX */
    ERROR_CHECK(app_simple_sensors_init(&m_ssensors_server_0, APP_SSENSORS_ELEMENT_INDEX));
    __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "App SIMPLE  SENSORS Model Handle: %d\n", m_ssensors_server_0.server.model_handle);
    
    /* Instantiate onoff server on element index APP_ONOFF_ELEMENT_INDEX */
    ERROR_CHECK( app_onoff_init(&m_onoff_server_0, APP_ONOFF_ELEMENT_INDEX) );
    __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "App OnOff Model Handle: %d\n", m_onoff_server_0.server.model_handle);
    
}

I always get the following error:

<t:      13042>, app_error_weak.c,  119, Mesh error 4 at 0x00026855 (/.../sensor_server/src/main.c:134)

which occurs in     ERROR_CHECK( app_onoff_init(&m_onoff_server_0, APP_ONOFF_ELEMENT_INDEX) );
I've tried instantiating the GenericOnOff first, and in that case, the error always occurs when I instantiate the second model.

If I only instantiate one of the models, I have no issues and it works fine. 

I've also noted that if I omit the ERROR_CHECK like so:

static void app_model_init(void)
{
    /* Instantiate Simple Sensors server on element index APP_SSENSORS_ELEMENT_INDEX */
    ERROR_CHECK(app_simple_sensors_init(&m_ssensors_server_0, APP_SSENSORS_ELEMENT_INDEX));
    __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "App SIMPLE SENSORS Model Handle: %d\n", m_ssensors_server_0.server.model_handle);
    
    /* Instantiate onoff server on element index APP_ONOFF_ELEMENT_INDEX */
    //ERROR_CHECK(
    app_onoff_init(&m_onoff_server_0, APP_ONOFF_ELEMENT_INDEX);// );
    __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "App OnOff Model Handle: %d\n", m_onoff_server_0.server.model_handle);
    
}

I can circumvent the error message and the application works just fine! I can operate both models in the device and all works as it should!

I've also gotten Mesh Error 5 in some other cases, but the main focus now is solving Mesh error 4 which is the one bugging me. I could simply move on without the Error_Check, as omiting it apparently isn't braking functionality, however I would prefer to do this cleanly.

What can I do?

Thanks in advance!

Regards

//E

  • $echo  "Hello everybody. It's been one week... Doesn't anyone have a clue as to why this is happening!?"

  • Have you increased the number of models in the nrf_mesh_config_app.h file?

    Failing to increase access model count will cause mesh error 4

  • Hello ! Thank you for replying and giving a hand.

    As I said earlier, I already tried all the solutions I could find in this forum... What you suggested had already been discussed in another thread about this same error. But, it doesn't work in my case.

    In my case I have 4 models in one element in each device. So normally I have access model count = 4 and access element count = 1 defined in nrf_mesh_config_app.h 

    However,  in this case I tried the following:

    //#define ACCESS_MODEL_COUNT (1 + /* Configuration server */  \
    //                            1 + /* Health server */  \
    //                            1 + /* Generic OnOff server */ \
    //                            1   /* Simple Sensor server */)
    
    #define ACCESS_MODEL_COUNT (10)
    
    /**
     * The number of elements in the application.
     *
     * @warning If the application is to support _multiple instances_ of the _same_ model, these instances
     * cannot be in the same element and a separate element is needed for each new instance of the same model.
     */
    #define ACCESS_ELEMENT_COUNT (2)

    and it does not work... What can I do? Any other ideas?

    Thanks!

  • Hi. 

    Sorry about the delay here. 

    Have you tried stepping into the function so see which exact check is causing the Mesh error 4 (NRF_ERROR_NO_MEM)?

    However, I talked to one of my colleagues about this. He suggested that to solve this, you will most likely need to increase ACCESS_SUBSCRIPTION_LIST_COUNT. This is due to the function; access_model_subscription_list_alloc() inside generic_onoff_server_init()

    Best regards, 
    Joakim 

  • Yes, that solved the issue! Thank you! I still don't understand what should the correct value be, though. I changed it from (1) to (2) and that did the trick.

    However, the comment note on that variable in .../include/nrf_mesh_config.h says " This value must equal @ref ACCESS_MODEL_COUNT minus the number of  models operating on shared states.". In my case I have 4 models explicitly referred in "ACCES_MODEL_COUNT, as far as I am aware none of this models are operating on shared states. which means that ACCESS_SUBSCRIPTION_LIST_COUNT should be 4 all the same. Should that be the case?

Related