UI freezes after ble device unexpectedly disconnects

[Iker]

Hi all, I have been suffering from this since some time ago. Whenever the ble device disconnects unexpectedly (out of range) my VB.NET application UI freezes. This problem didn't arise until the version of Wcl that detect and trigger an event when the client disconnect.

This is the call stack of the event:

>   mscorlib.dll!System.Threading.Thread.Join() L

[Mike Petrichenko]

Hi,

Sorry for delay with the answer, we had to test it before answering the question.

This may apper only if you read characteristics/values form separate thread. That isnot recommended. You must do all the calls in the same thread.

[Iker]

Hi Mike, thanks for quick answer.

In general, all calls to your framework are made from one single thread. But there is an exception, the connection to the BLE device is managed from a VB Timer (as far as I understand this means the UI thread), could this explain the issue?.

Regards,

Iker.

[Mike Petrichenko]

Should not. Can you please (if possible) prepare simple demo app that can reproduce the issue and send to us at support@btframework.com so we can reproduce the problem and fix it. Unfortunately (you probably know how it is) our code always (here is a big smile) works on our side.

Thank you.

[Iker]

Let me add some adittional information, as I told the connection to the BLE device is managed from a Timer. In my code the connection procedure comprises this:

1. Call to Client.Connect()
2. Call to Client.ReadServices()
3. Call to Client.ReadCharacteristics()
4. All subsecuent call to your API are now managed from a dedicated thread.

All this calls (1 to 3) are made from the Timer. Modifying my code to move all this to the dedicated BLE thread will requiere some effort so I will be very gratefull if you can confirm that making all this calls from the UI is a probable cause of my problem.

Thanks.

[Mike Petrichenko]

You muist move the steps 2-4 to the OnConnect event handler. And yes, because all the operations (except connection) are synchronous it may block UI.

[Iker]

I have moved steps 2 and 3 to the OnConnect event but still get the same result, UI freezes.

To make it as clear as possible this is what I am doing:

1. From VB Timer: Call to Client.Connect()
2. From OnConnect event: Client.ReadServices()
3. From OnConnect event: Client.ReadCharacteristics()
4. From a dedicated thread all the rest of calls to your API to manage the communication with my device.

Because you said on your previous post I should move steps 2 to 4 to OnConnect I wonder if I should manage step 4 really from inside OnConnect event instead of creating a dedicated task.

[Mike Petrichenko]

Hi,

OnConnect() event fires when connection operation completed. Connect is asynchronous operation, Once you called Connect() it starts connection procedure but does not really connect to device yet (when Connect() method returns). When connection operation completed OnConnect event fires with operation result. If the Error parameter is WCL_E_SUCCESS then connection was established with success. (It all described in the Bluetooth Framework documentation).

As I wrote in my previous answer the ReadServices and ReadCharacteristics are synchronouse operations. They do not return until operation completed. That means that it blocks all the execution until reading attributes completed. As you know Windows based on Windows messages and any Window must have message loop to process messages. Once execution is blocked by call to the function no one message can be processed by window. That is the basic of Windows programming.

About threading. All Bluetooth Framework classes must be used in the same thread that ceated the object. If you created GattClient in main thread you must execute all calls to its method in this main thread. If you need to use separate threads you must create the Gattclient object in that separate thread and call all its methods in that separate thread. There are few execptions (when you can create object in one thread and call its methods from other threads) but you must know eactly what you do and synchronize threads and calls to the object methods by your code. Because interthreading synchronization ca be comples it is better to just say that thread that created th eobject must use the object.

[Iker]

Thank you very much for your help Mike. My area of expertise is firmware and RTOS so I feel quite confident on the matter of interthread synchronization and shared object access protection. Unfortunatelly I am not so expert on the windows subsystem.

No matter what I try I am unable to solve the issue. On your first answer in this thread you said that read characteristics/values form separate thread is not recomended, but because I need to have some kind of UART emulation with constant communication with the BLE device I do not see how can I make it in another way without compromising the UI responsiveness. I am under the impression that this is the cause of the issue in my particular application.

I have made quite a lot of test, even making every single call to your API from my bluetooth thread, instead of some from the UI thread and then from the bluetooth thread. Same result.

So to sumarize, do you think that read characteristics/values form separate thread is the cause of the problem?, any workaround?

Regards,

Iker.

[Mike Petrichenko]

I think it will be better if i create some sample/demo application that shows how to use GattClient in thread so then we can discuss how to add this into your project to prevent UI from freezing. It takes a couple of days, if that OK for you.

[Iker]

That would be great, a couple days is perfectly fine thanks.

[Mike Petrichenko]

Sample code is attached.

[Iker]

Thanks Mike, I will look into it and report back to you.

Regards,

Iker.