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

Problems in creating vendor specific model

Hi Nordic Developers,

I would like to extend my question on creating vendor specific model from this question I posted earlier (extension of Thingy Mesh Demo v0.1):

https://devzone.nordicsemi.com/f/nordic-q-a/51183/hardware-ability-report-after-provisioning-in-mesh-demo

I have created hardware_infos_server model for Thingy Nodes and hardware_infos_client model for Thingy Bridge, with reference to simply_thingy client and server model from Nordic. I am glad that for Thingy Nodes runs smoothly and showed positive results.

When compiling Thingy Bridge, I have one warning in the codes below: assignment from incompatible pointer type [-Wincompatible-pointer-types]:

In main.c, in access_setup(void) method (line 324):

/* Initialize and enable all the models before calling ***_flash_config_load. */
    ERROR_CHECK(config_client_init(config_client_event_cb));
    ERROR_CHECK(health_client_init(&m_health_client, 0, health_event_cb));

    for (uint32_t i = 0; i < CLIENT_COUNT; ++i)
    {
        m_clients[i].led_status_cb = led_status_cb;   
        m_clients[i].sensor_status_cb = sensor_status_cb;
        ERROR_CHECK(simple_thingy_client_init(&m_clients[i], i));  
            
        // hi stands for handware info
        // I have initialized hi_clients[CLIENT_COUNT] with type hardware_infos_client_t
        // , just the same like m_clients
        hi_clients[i].infos_status_cb = infos_status_cb;
        ERROR_CHECK(hardware_infos_client_init(&hi_clients[i], i));  
    }

The bridge functions ok before debugging. But when I debug, I have encountered this problem when running last line of the codes above:

[1;31m:ERROR: id = 16385, pc = 0, file = C:\Users\WH\Desktop\Nordic-Thingy52-FW-master\Thingy_bridge\pca20020_s132\main.c, line number: 331, error code = 4 = NRF_ERROR_NO_MEM 

Then I tried to add 1 to the defining of ACCESS_MODEL_COUNT.

For defining opcode handlers and allocating the model to element, I did it the same way as simply_thingy models. Or I just duplicate and edit the functions that I needed. Did I missed out something? I suppose the steps for enabling all the models before calling ***_flash_config_load is needed right?

I would glad to provide further details if needed. I appreciate your time for looking into this matter. Many thanks.

Kindly,

WHui

Parents Reply
  • Hi Hung Bui,

    As you can see from the pic in nrf_mesh_config_app.h above, the total number of ACCESS_MODEL_COUNT is 25. If I add one to the number and make ACCESS_MODEL_COUNT becomes 26, the NRF_ERROR_NO_MEM will be gone. I thought the server count is 10, while the number of my new group (Hardware Infos client (group)) should be one? Do you know the reason behind the number?

Children
  • Hi WHui, 

    My idea is to port the example to SDK v3.2.0. This would require to significantly modify the demo to be able to use with SDK v3.2. And usually it's easier to base the code on one of the example in SDK v3.2 and the add the code for the thingy and models in. 

    Regarding your issue, i think you hit the memory limit. You need memory in RAM for each of the client you create. 

    I don't think it's a good idea to create a client for each and every server. You are doing mesh and you can  get to hundreds of node. It's easier to create one single client that can handle multiple servers. You can use group address for this. No need to have one client for each server. 

    Please be aware that we made the project mainly to create a demo. It shouldn't be used to create your own products. 

    I would strongly suggest you to study our example (light switch for example) to understand the concept of mesh (access layer, model etc) and then port it to run on the thingy. 

  • Hi Hung Bui,

    Thank you for the tips Hung Bui. My intension is to create my own demo as well. I think I will start anew again with SDK v3.2.0 as you mentioned. Thanks again!

Related