BluetoothLE Sample fails to connect to Silicon Labs device after it reboots in OTA mode
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
Research direction
Start with Samples/BluetoothLE/cppwinrt/Scenario2_Client.cpp around the linked service-discovery call at line 209. Reproduce the disconnect and reboot into OTA mode using the reported Windows 11, SDK 10.0.22621.0, and Visual Studio 17.6.5 configuration, then trace reconnection and discovery behavior. Done means the sample reconnects to the Silicon Labs device after rebooting into OTA mode.
Written by the indexing model from the issue text.
Description
Which sample are you reporting a bug in?
BluetoothLE sample C++/WinRT
Describe the bug
I am unable to connect to a Silicon Labs MCU after the MCU closes the connection. I have developed a UWB App before based on this sample, with the purpose of executing an OTA DFU on a Silicon Labs MCU. However, the laptops were changed and now I am using a Windows 11 PC.
That said, the process of the OTA DFU in Silicon Labs basically follows this procedure:
- Write in OTA Control Characteristic
- MCU reboots in OTA mode, closing the connection
- Connect and send new firmware image
The problem lies in step 2, where the Windows UWP Sample is unable to establish a connection again to the device. I don't have any of these problems using any other BLE Mobile Apps like EFR Connect or nRF Connect.
I believe the problem might be in here , where the device tries to discover the services and it fails, but I am guessing the problem/incompatibility is deeper than only this function call.
So I want to ask the UWP dev team if there is anything that the Windows API needs to receive in order to establish a connection (i am sure the connection is opened but not maintained since the device exit OTA mode) since this only happens when the MCU is rebooted into the called OTA mode.
Expected behavior
Windows PC should connect to the MCU after the MCU reboots.
Screenshots
Configuration
- C++/WinRT x64 Debug
- Windows 11 SDK (10.0.22621.0)
- Visual Studio 17.6.5
Additional context
I can also add that advertising packets sent in normal mode are as follows:
- Flags = 0x06
- Complete Local Name
In OTA Mode the advertising packets contain:
- Flags = 0x06;
- Complete Local Name
- LE Bluetooth Device Address (random type)
- TX Power Level
- Dominant language
- JavaScript
- Stars
- 9.7k
- Forks
- 7.8k
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/Windows-universal-samples
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
bug
Difficulty 3/5 1-2 days Newbie friendliness 52/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 55/100
microsoft/Windows-universal-samples#1442 · 6 comments ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 42/100
microsoft/Windows-universal-samples#1440 · 3 comments · 1 reaction ·
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 45/100
microsoft/Windows-universal-samples#1437 · 3 comments ·
All issues in microsoft/Windows-universal-samples
Similar issues
-
code-quality refactoring
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
github/gh-aw-firewall#8816 ·
-
integration:quickjs org:external priority:backlog topic:code-interpreter topic:middleware type:feature
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
langchain-ai/deepagents#6450 ·
-
optimization optimization:agents-md-curator
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
githubnext/gh-aw-cao#13143 ·
-
status: needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100