esp-idf: Not able to provision the ESP - BLE-MESH Example. (IDFGH-11775)

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.

General issue report

Hai, My sdk version is ESP-IDF v5.3-dev-1157 & Esp32-c3 development board. I tried onoff_client, onoff_server, sensor ble mesh examples under this location esp-idf\examples\bluetooth\esp_ble_mesh I haven’t modified anything on code. I just changed BLE mesh log level. I’m using NRF BLE MESH Android app for provisioning but I’m not able to complete the provisioning process. It always fails.

Here is the on-off server example on esp32-c3 log:

I (30) boot: ESP-IDF v5.3-dev-1157-g341a8f2d65 2nd stage bootloader
I (30) boot: compile time Dec 26 2023 10:33:55
I (31) boot: chip revision: v0.3
I (35) boot.esp32c3: SPI Speed      : 80MHz
I (40) boot.esp32c3: SPI Mode       : DIO
I (44) boot.esp32c3: SPI Flash Size : 2MB
I (49) boot: Enabling RNG early entropy source...
I (54) boot: Partition Table:
I (58) boot: ## Label            Usage          Type ST Offset   Length
I (65) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (73) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (80) boot:  2 factory          factory app      00 00 00010000 00177000
I (88) boot: End of partition table
I (92) esp_image: segment 0: paddr=00010020 vaddr=3c0e0020 size=3b4c8h (242888) map
I (140) esp_image: segment 1: paddr=0004b4f0 vaddr=3fc90a00 size=02f28h ( 12072) load
I (142) esp_image: segment 2: paddr=0004e420 vaddr=40380000 size=01bf8h (  7160) load
I (147) esp_image: segment 3: paddr=00050020 vaddr=42000020 size=dc5fch (902652) map
I (301) esp_image: segment 4: paddr=0012c624 vaddr=40381bf8 size=0ec34h ( 60468) load
I (317) boot: Loaded app from partition at offset 0x10000
I (317) boot: Disabling RNG early entropy source...
I (329) cpu_start: Unicore app
I (338) cpu_start: Pro cpu start user code
I (338) cpu_start: cpu freq: 160000000 Hz
I (338) cpu_start: Application information:
I (341) cpu_start: Project name:     onoff_server
I (347) cpu_start: App version:      1
I (351) cpu_start: Compile time:     Dec 26 2023 11:09:40
I (357) cpu_start: ELF file SHA256:  562da1cc4...
I (363) cpu_start: ESP-IDF:          v5.3-dev-1157-g341a8f2d65
I (369) cpu_start: Min chip rev:     v0.3
I (374) cpu_start: Max chip rev:     v1.99
I (379) cpu_start: Chip rev:         v0.3
I (383) heap_init: Initializing. RAM available for dynamic allocation:
I (391) heap_init: At 3FC9B410 len 00024BF0 (146 KiB): RAM
I (397) heap_init: At 3FCC0000 len 0001C710 (113 KiB): Retention RAM
I (404) heap_init: At 3FCDC710 len 00002950 (10 KiB): Retention RAM
I (411) heap_init: At 50000010 len 00001FD8 (7 KiB): RTCRAM
I (418) spi_flash: detected chip: generic
I (422) spi_flash: flash io: dio
W (426) spi_flash: Detected size(4096k) larger than the size in the binary image header(2048k). Using the size in the binary image header.
I (439) sleep: Configure to isolate all GPIO pins in sleep state
I (446) sleep: Enable automatic switching of GPIO sleep configuration
I (453) coexist: coex firmware version: c02915e
I (467) coexist: coexist rom version 9387209
I (468) main_task: Started on CPU0
I (468) main_task: Calling app_main()
I (468) EXAMPLE: Initializing...
I (468) gpio: GPIO[8]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
I (478) gpio: GPIO[8]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
I (488) gpio: GPIO[8]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
I (508) BLE_INIT: BT controller compile version [b877d66]
I (508) BLE_INIT: Bluetooth MAC: 7c:df:a1:c2:0e:82
I (508) phy_init: phy_version 1130,b4e4b80,Sep  5 2023,11:09:30
Bluetooth Mesh v1.1 commit: [154b4fcc98]
I (568) BLE_MESH: Friend not supported
I (628) EXAMPLE: ESP_BLE_MESH_PROV_REGISTER_COMP_EVT, err_code 0
I (628) EXAMPLE: ESP_BLE_MESH_NODE_PROV_ENABLE_COMP_EVT, err_code 0
I (628) EXAMPLE: BLE Mesh Node initialized
I (638) main_task: Returned from app_main()
I (6818) EXAMPLE: ESP_BLE_MESH_NODE_PROV_LINK_OPEN_EVT, bearer PB-GATT
W (8468) BLE_MESH: No Health Server context provided
I (9368) BLE_MESH: Algorithm:   0x00
I (9368) BLE_MESH: Public Key:  0x00
I (9368) BLE_MESH: Auth Method: 0x00
I (9368) BLE_MESH: Auth Action: 0x00
I (9378) BLE_MESH: Auth Size:   0x00
I (9638) BLE_MESH: Remote Random: 977f71785a107b753fa2ab3ddfec264f
I (9738) BLE_MESH: Primary Element: 0x001c
I (9738) BLE_MESH: net_idx 0x0000 flags 0x00 iv_index 0x0000
I (9738) BLE_MESH: DevKey 0600416b9d5b3221629100404c71b29f
I (9738) BLE_MESH: NetKey ae415409468ef870f8559d1279eaaa97
W (9748) BLE_MESH: No Health Server context provided
I (9758) BLE_MESH: Primary address 0x001c, element count 3
I (9758) BLE_MESH: Scan is already started
I (9768) EXAMPLE: ESP_BLE_MESH_NODE_PROV_LINK_CLOSE_EVT, bearer PB-GATT
I (9768) EXAMPLE: ESP_BLE_MESH_NODE_PROV_COMPLETE_EVT
I (9778) EXAMPLE: net_idx: 0x0000, addr: 0x001c
I (9778) EXAMPLE: flags: 0x00, iv_index: 0x00000000
W (10808) BT_HCI: hcif disc complete: hdl 0x2, rsn 0x13
I (17158) BLE_MESH: recv, app_idx 0xfffe src 0x0001 dst 0x001c
I (17158) BLE_MESH: recv, len 3: 800800
I (17158) BLE_MESH: send, app_idx 0xfffe src 0x001c dst 0x0001
I (17168) BLE_MESH: send, len 32: 0200e502000000000a0003000000020000000010000001000010000001000010
I (17178) BLE_MESH: Seg, send_tag 0x03, send_szmic 0, aszmic 0
I (17178) BLE_MESH: Use security credentials 0x00, proxy 0
I (17188) BLE_MESH: Network PDU, count 2, interval 20
I (17188) BLE_MESH: Use security credentials 0x00, proxy 0
I (17198) BLE_MESH: Network PDU, count 2, interval 20
I (17208) BLE_MESH: Use security credentials 0x00, proxy 0
I (17208) BLE_MESH: Network PDU, count 2, interval 20
I (18228) BLE_MESH: Attempts: 3
I (18228) BLE_MESH: Resending 0/2, cred 0x00
I (18228) BLE_MESH: Resending 1/2, cred 0x00
I (18228) BLE_MESH: Resending 2/2, cred 0x00
I (19248) BLE_MESH: Attempts: 2
I (19248) BLE_MESH: Resending 0/2, cred 0x00
I (19248) BLE_MESH: Resending 1/2, cred 0x00
I (19248) BLE_MESH: Resending 2/2, cred 0x00
I (20268) BLE_MESH: Attempts: 1
I (20268) BLE_MESH: Resending 0/2, cred 0x00
I (20268) BLE_MESH: Resending 1/2, cred 0x00
I (20268) BLE_MESH: Resending 2/2, cred 0x00
I (21288) BLE_MESH: Attempts: 0
I (21288) BLE_MESH: Resending 0/2, cred 0x00
I (21288) BLE_MESH: Resending 1/2, cred 0x00
I (21288) BLE_MESH: Resending 2/2, cred 0x00
W (22308) BLE_MESH: Ran out of retransmit attempts
W (358928) BT_HCI: hcif disc complete: hdl 0x2, rsn 0x13

In Nrf mesh app it’s getting stop at “Sending composition data get…” Screenshot_2023-12-21-19-57-35-26_3207d904ec569c183efa42395aeecd91

Why is this happening? How to resolve this.

Best Regards Bose

About this issue

  • Original URL
  • State: closed
  • Created 6 months ago
  • Comments: 33 (11 by maintainers)

Commits related to this issue

Most upvoted comments

Ive found it, finally. It has nothing to do with anything i said earlier, and for sure with ble mesh v1.1. provisioning cant pass this check https://github.com/espressif/esp-idf/blob/master/components/bt/esp_ble_mesh/core/net.c#L1813 This is the fix

    if (IS_ENABLED(CONFIG_BLE_MESH_GATT_PROXY_SERVER) &&
       bt_mesh_private_gatt_proxy_state_get() != BLE_MESH_PRIVATE_GATT_PROXY_ENABLED &&
       net_if == BLE_MESH_NET_IF_PROXY) {

Thanks

PS now it works with nRF connect and silab app too

+3
chegewara on Mar 12, 2024

Yes

+1
forx157 on Mar 14, 2024

Im not sure if my deduction is correct, but i found something. To perform this test i am doing some “stupid” operations, but results are interesting.

  • i have this variable as a class member (its correctly initialized) esp_ble_mesh_model_pub_t pub = {};
  • i update value in net buffer with
        memcpy(pub.msg->data, data, len);
        pub.msg->len = len;
        ESP_LOG_BUFFER_HEX("TAG update 2", pub.msg->data, pub.msg->len);

and get correct result

TAG update 2: 44 44 44 44 <--- data sent to vendor model from nrf mesh

now the strange part only for this test purpose

    void publishState(size_t len, uint8_t* data)
    {
        esp_ble_mesh_model_publish(_model, set_opcode, len, data, ROLE_NODE); <--- here i pass data
        ESP_LOG_BUFFER_HEX("TAG update 3", pub.msg->data, pub.msg->len);
        esp_ble_mesh_model_publish(_model, set_opcode, pub.msg->len, pub.msg->data, ROLE_NODE); <---- here i pass `pub` with previously updated data
        ESP_LOG_BUFFER_HEX("TAG update 4", pub.msg->data, pub.msg->len);
    }

and here is log

I (56527) TAG update 3: c4 34 12 44 44 44 44 <--- correctly updated pub.msg->data with opcode
I (56537) TAG update 4: c4 34 12 c4 34 12 c4 44 12 c4 <--- data corrupted

we can observe 2 things:

  • on first call to publish i pass data straight to the function, even tho pub data is updated with opcode (which is probably expected in normal usage)
  • on second call to publish pub is updated again with opcode, but the pointer is not reset to begin of data buffer, so data are corrupted

Bear in mind that in normal use case i call only one time publish function with data passed from pub

I hope i described it that it can be understand, even if its a bit messy

Thanks

+1
chegewara on Mar 14, 2024

No problem, im glad it is that easy fix I honestly believe this ble mesh component is very good job of you guys. If lame like me can easy build any mesh device, node models or provisioner, without issue and get clear info when something is wrong (like missing setup server or or light models) then its very good.

I can only complain that mesh in esp-idf 5.1 is not C++ friendly (macros wont let use it in C++), but its fixed in 5.3.

Thanks

+1
chegewara on Mar 13, 2024

@chegewara Thank you very much for your excellent work and apologies for the oversight in our code, we will be fixing this as soon as possible, thanks again for your efforts.

+1
forx157 on Mar 13, 2024

Looks like i dont know what i am saying about, maybe except how to workaround provisioning issues with nrf mesh.

Here is what i found:

  • even esp32 ble mesh provisioner v1.0 cant provision device with mesh v1.1
  • composition data in v1.1 looks different (additional 2 bytes value in front), according to logs – composition data from v1.0 e502 0000 0000 0a00 0300 and v1.1 0200 e502 0000 0000 0a00 0300
  • ble mesh v1.1 specs does not mention about this additional value - table 4.2 - https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=554899

Hai @chegewara I haven’t looked into it. It’s Great. This means, we need a V1.1 provisioner to provision the v1.1 device. Nrf iOS app will support v1.1, that’s the reason we can provision using iOS. But Android nrf doesn’t support v1.1.

+1
Bosemani on Feb 29, 2024

Looks like i dont know what i am saying about, maybe except how to workaround provisioning issues with nrf mesh.

Here is what i found:

  • even esp32 ble mesh provisioner v1.0 cant provision device with mesh v1.1
  • composition data in v1.1 looks different (additional 2 bytes value in front), according to logs – composition data from v1.0 e502 0000 0000 0a00 0300 and v1.1 0200 e502 0000 0000 0a00 0300
  • ble mesh v1.1 specs does not mention about this additional value - table 4.2 - https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=554899
+1
chegewara on Feb 29, 2024

Hi, I am 90% sure its issue with espressif mesh code, in particular with proxy out characteristic in proxy server. I tested with nrf mesh, sti mesh and silab mesh app, also with espressif espmesh app. None can provision mesh node from master.

If you dont have any provisioned esp32 devices, then its easy solution. Grab esp32 devkit and flash any mesh example built with idf 5.1. You have tool to work with mesh 5.1, because you can continue provisioning and play with mesh v1.1.

Specs says that mesh 1.1 shall be backward compatible, so any provisioner which works with mesh 1.0 should works with v1.1, just wont handle new features.

+1
chegewara on Feb 26, 2024

Hi @Bosemani! I have the same problem using the nrf mesh application for Android. I tried doing the same with the Apple appand it worked without any problem. If you take a look to the source code of the nrf mesh application it seems that the Android app supports BLE Mesh 1.0.1 while the Apple app supports BLE Mesh 1.1. Maybe the problem is related to the version of the supported protocol by the application.

If you don’t have an apple product, you can try to do the same using an esp32 as provisioner.

+1
Herbrant on Feb 20, 2024
Read more comments on GitHub
← esp-idf: No boot error with: memory_layout: SOC_RESERVE_MEMORY_REGION region range 0xfffffffc - 0x00000000 ov (IDFGH-403)
esp-idf: NVS write crashes with "Cache disabled but cached memory region accessed" (IDFGH-8634) →