2020-02-24 02:40 PM
I have two STM32WB55 nucleo boards, and I have built the BLE_MeshLightingDemo from en.stm32cubewb_v1-4-0.zip (STMCubeWB version 1.4.0). I loaded the stm32wb5x_BLE_Stack_fw.bin, and built the demo with IAR. After factory reset I see the node in the device scan, but when I try to provision it either hangs in "waiting for the capabilities", or if it makes it through that it hangs in Provisioning.
I'm using the BLE mesh app version 1.06.002 on IOS 13.3.1
does anyone have any idea why it's so unreliable ? should I try an older version of STMCubeWB (1.2 and 1.3 are available)
Thanks for any help
2020-02-24 02:42 PM
Here is the output on the UART in case it helps:
BD_MAC Address = [c0]:[e1]:[26]:[00]:[43]:[ba]
2207 Model_RestoreStates - data is invalid 0
16713 Appli_BleUnprovisionedIdentifyCb - Unprovisioned Node Identifier received: 00
Unprovisioned device
BLE-Mesh Library v01.10.004
BD_MAC Address = [c0]:[e1]:[26]:[00]:[43]:[ba]
2206 Model_RestoreStates - data is invalid 0
15178 Appli_BleUnprovisionedIdentifyCb - Unprovisioned Node Identifier received: 00
2020-02-24 02:48 PM
I'm using the BLE mesh app version 1.06.002 on IOS 13.3.1
2020-02-25 10:28 AM
Have now also tried app version 1.11 on Android - gets stuck at "MTU Packet Check State".
Diff'ing between CubeWB1.2.0,1.3.0,1.4.0,1.5.0 it seems the firmware is not stable at all - there are significant changes in the application demo code and it's not clear if any regression testing was performed on this demo.
2020-02-27 08:37 AM
I found the problem. I had a couple of old BLE tags in a desk drawer and after pulling the coin cell out of one of them the mesh application is working - I guess the tag may have been in an unstable state (it's probably been running for 2+ years) and interfering with the BLE signals. I found this when I tried the cable replacement BLE demo and saw some strange, misformatted advertising messages received on the central device.