-
Notifications
You must be signed in to change notification settings - Fork 7.6k
[BLE Client] Deadlock when calling writeValue after registerForNotify #4952
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I really need to find my old code fixes for this library and PR them. The issue here is your device has been disconnected while you were waiting for the write to complete and are now stuck on the semaphore as that event is not handled properly to release it in the BLERemoteChracteristic class. Here is the fix; Add this code to this line:
That should resolve this issue. |
Thank you for providing the fix. |
it will :) |
Nice :) |
nice |
Describe your system
Hardware: Custom ESP32 Module
Computer: Windows 10
Core version: 1.0.4
Environment: Arduino IDE
Hardware:
Board: ESP32 Dev Module
Core Installation version: 1.04
IDE name: Arduino IDE
Flash Frequency: 40Mhz
PSRAM enabled: no
Upload Speed: 115200
Computer OS: Windows 10
Description:
My task locks when calling writeValue right after calling registerForNotify.
This is very random and seems to happen most frequently when the client disconnects from the sever and reconnects, and then again tries to register for notifications from server and write a value in the characteristic.
I got from the logs that when calling writeValue it waits forever for a mutex to be released:
m_semaphoreWriteCharEvt.take("writeValue");
It seems that registerForNotify take the writeValue mutex and never releases it, probably waiting for an event release it.
When writeValue is called, it tries to take the mutex and keep waiting forever causing the deadlock.
As a temporary solution I set a task watchdog to panic and reset the device if the situation above happen, but this may be affecting other people projects that a reset is impracticable.
Also, the client is connected and the code is executed right after a scan and successful connection to server.
Sketch:
Logs
The text was updated successfully, but these errors were encountered: