[ble mesh] esp_ble_mesh_init stuck (IDFGH-12226)

[chegewara]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

5f42493

Espressif SoC revision.

esp32-s3

Operating System used.

Linux

How did you build your project?

Command line with idf.py

If you are using Windows, please specify command line type.

None

Development Kit.

esp32s3-devkit

Power Supply used.

USB

What is the expected behavior?

To get esp_err_t error

What is the actual behavior?

esp_ble_mesh_init in some cases, when one of parameters is wrong (not sure which one) function stuck and never returns.

Steps to reproduce.

Im not entirely sure. My library is auto-generating composition elements, so i am guessing if for some reson composition.elements is incorrect then it stuck

Debug Logs.

No response

More Information.

First of all i would like to say that ble mesh components is awesome. The number of error and warn messages when its missconfigured, for example when scene setup server model is missing, is impressive and helpful for newbie like me.

Thanks you for such good job.

[chegewara]

I think its happening when there is a mismatch between number of elements and element_count passed in this config, especially when for some reason el_cnt is big, like 60 and only 3 elements:

    composition = {
        .cid = CID_ESP,
        .element_count = el_cnt,
        .elements = sig_mesh_elements,
    };

Ity happened to me when el_cnt is not initialized in C++, so it can have random value.
I know its a bug in my code, but it should not cause this function to stuck forever.

[chegewara]

Hi,
with vendor model i dont see any of this events when sending/receiving with esp_ble_mesh_model_publish

ESP_BLE_MESH_MODEL_PUBLISH_COMP_EVT
ESP_BLE_MESH_CLIENT_MODEL_RECV_PUBLISH_MSG_EVT

[forx157]

Hi, @chegewara
In your first question, are you saying that you gave sig_mesh_elements a different length than el_cnt, which in turn caused the problem?
In your second question, Is it convenient to say what kind of functionality you want to achieve with esp_ble_mesh_model_publish? How do you use esp_ble_mesh_model_publish?

[chegewara]

Hi,

Hi, @chegewara In your first question, are you saying that you gave sig_mesh_elements a different length than el_cnt, which in turn caused the problem?

Yes, although i understand the problem is on my side, and API is just trying to do its best to build composition data from corrupted information and most likely stuck in endless loop. So, i dont think its a bug anymore

In your second question, Is it convenient to say what kind of functionality you want to achieve with esp_ble_mesh_model_publish? How do you use esp_ble_mesh_model_publish?

In vendor model i am receiving publish messages from another vendor mode, but this event is not triggered ESP_BLE_MESH_CLIENT_MODEL_RECV_PUBLISH_MSG_EVT . Instead this one is ESP_BLE_MESH_MODEL_OPERATION_EVT.

This is API i am using to publish to unicast address
esp_ble_mesh_model_publish

Here is log on receive
vendor event: 0,

[chegewara]

BTW with persistent store enabled, when i reset node everything is deleted except appKeys (after node reset and power on cycle)

I (1465) BLE_MESH: Restored Model Bound AppKey, index 0000ffffffff
I (1465) BLE_MESH: Restored Model Bound AppKey, index 0000ffffffff
I (1475) BLE_MESH: Restored Model Bound AppKey, index 0000ffffffff
I (1475) BLE_MESH: Restored Model Bound AppKey, index 0000ffffffff

and publish settings too (after node reset and power on cycle):

I (1514) BLE_MESH: Restored Model Publication, address 0x0001, app_idx 0x000

So, after provisioning node again app keys are already bound. No big deal, but in some cases may be unwanted

Thanks

edit: it is strange, because its not always happen, and i dont know what is the factor yet (will try to find out)