Skip to content
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

Can not connect a second time to a re-created client #65

Closed
Jeroen88 opened this issue May 28, 2020 · 13 comments
Closed

Can not connect a second time to a re-created client #65

Jeroen88 opened this issue May 28, 2020 · 13 comments

Comments

@Jeroen88
Copy link

MVCE

#include <NimBLEDevice.h>


void setup() {
  // put your setup code here, to run once:
  Serial.begin(115200);
  Serial.println("\n\nStarted");

  BLEDevice::init("ESP32");

  Serial.println("Create");
  NimBLEClient *pClient = BLEDevice::createClient();
  Serial.println("Connecting...");
  bool success = pClient->connect(NimBLEAddress("a4:c1:38:5d:ef:16"));
  if(success) {
    Serial.println("Connected");
    pClient->disconnect();
    Serial.println("Disconnected");

    BLEDevice::deleteClient(pClient);
    Serial.println("Create");
    pClient = BLEDevice::createClient();
    
    Serial.println("Connecting...");
    success = pClient->connect(NimBLEAddress("a4:c1:38:5d:ef:16"));
    if(success) {
      Serial.println("Connected");
      pClient->disconnect();
      Serial.println("Disconnected");
    }
  }
}

void loop() {
  // put your main code here, to run repeatedly:

}

Logging:

Started
I NimBLEDevice: "BLE Host Task Started"
I NimBLEDevice: "NimBle host synced."
Create
Connecting...
D NimBLEClient: ">> connect(a4:c1:38:5d:ef:16)"
D FreeRTOS: "Semaphore taking: name: OpenEvt (0x3ffc8870), owner: <N/A> for connect"
D FreeRTOS: "Semaphore taken:  name: OpenEvt (0x3ffc8870), owner: connect"
D FreeRTOS: ">> wait: Semaphore waiting: name: OpenEvt (0x3ffc8870), owner: connect for connect"
D NimBLEClient: "Got Client event "
D NimBLEClient: "Connection established"
D FreeRTOS: "Semaphore giving: name: OpenEvt (0x3ffc8870), owner: connect"
D FreeRTOS: "<< wait: Semaphore released: name: OpenEvt (0x3ffc8870), owner: <N/A>"
D NimBLEClient: "Refreshing Services for: (a4:c1:38:5d:ef:16)"
D NimBLEClient: ">> deleteServices"
D NimBLEClient: "<< deleteServices"
D NimBLEClientCallbacks: "onConnect: default"
D NimBLEClient: "<< connect()"
Connected
D NimBLEClient: ">> disconnect()"
D NimBLEClient: "<< disconnect()"
Disconnected
D NimBLEClient: ">> deleteServices"
D NimBLEClient: "<< deleteServices"
Create
Connecting...
D NimBLEClient: ">> connect(a4:c1:38:5d:ef:16)"
D FreeRTOS: "Semaphore taking: name: OpenEvt (0x3ffc8870), owner: <N/A> for connect"
D FreeRTOS: "Semaphore taken:  name: OpenEvt (0x3ffc8870), owner: connect"
D FreeRTOS: ">> wait: Semaphore waiting: name: OpenEvt (0x3ffc8870), owner: connect for connect"
D NimBLEClient: "Got Client event "
D NimBLEClient: "Got Client event "

... and then just "hangs"

@Staars
Copy link
Contributor

Staars commented May 28, 2020

This reminds of my last weekend, where I finally was "sure" that my ESP32 was broken.

For me the solution was to erase the flash , which seemed to have solved it. In the end I erased it basically before every upload.

What IDE are you using? If you are using some kind of caching mechanism, you might need to delete the compiler cache too.

@Jeroen88
Copy link
Author

I had a "broken" ESP32 too a few days ago, put it apart, I have not thrown it away yet. I'll try to erase the flash to see if that brings it back to life.

But this is another issue. I can reset to run the sketch again. I can re-flash and start the program over again. But is won't get passed the second connect(). As you can see in the logging, while connecting the first time it logs:

D NimBLEClient: "Got Client event "
D NimBLEClient: "Connection established"

and the second time it logs:

D NimBLEClient: "Got Client event "
D NimBLEClient: "Got Client event "

and then waits forever...

Most of the time, also this time, I use the Arduino IDE, 1.8.10 (that is the one but last I believe). Every now and then I use pio.

@h2zero
Copy link
Owner

h2zero commented May 28, 2020

Turn on event code strings to see what

D NimBLEClient: "Got Client event "
D NimBLEClient: "Got Client event "

actually are.

Looks like you're hanging on a semaphore, or the stack is getting stuck because the peripheral has not disconnected yet. Try putting a delay of 100ms or so between deleting and creating the client.

@Jeroen88
Copy link
Author

Logging now:

Started
I NimBLEDevice: "BLE Host Task Started"
I NimBLEDevice: "NimBle host synced."
Create
Connecting...
D NimBLEClient: ">> connect(a4:c1:38:5d:ef:16)"
D FreeRTOS: "Semaphore taking: name: OpenEvt (0x3ffc88fc), owner: <N/A> for connect"
D FreeRTOS: "Semaphore taken:  name: OpenEvt (0x3ffc88fc), owner: connect"
D FreeRTOS: ">> wait: Semaphore waiting: name: OpenEvt (0x3ffc88fc), owner: connect for connect"
D NimBLEClient: "Got Client event BLE_GAP_EVENT_CONNECT "
D NimBLEClient: "Connection established"
D FreeRTOS: "Semaphore giving: name: OpenEvt (0x3ffc88fc), owner: connect"
D FreeRTOS: "<< wait: Semaphore released: name: OpenEvt (0x3ffc88fc), owner: <N/A>"
D NimBLEClient: "Refreshing Services for: (a4:c1:38:5d:ef:16)"
D NimBLEClient: ">> deleteServices"
D NimBLEClient: "<< deleteServices"
D NimBLEClientCallbacks: "onConnect: default"
D NimBLEClient: "<< connect()"
Connected
D NimBLEClient: ">> disconnect()"
D NimBLEClient: "<< disconnect()"
Disconnected
D NimBLEClient: ">> deleteServices"
D NimBLEClient: "<< deleteServices"
Create
Connecting...
D NimBLEClient: ">> connect(a4:c1:38:5d:ef:16)"
D FreeRTOS: "Semaphore taking: name: OpenEvt (0x3ffc88fc), owner: <N/A> for connect"
D FreeRTOS: "Semaphore taken:  name: OpenEvt (0x3ffc88fc), owner: connect"
D FreeRTOS: ">> wait: Semaphore waiting: name: OpenEvt (0x3ffc88fc), owner: connect for connect"
D NimBLEClient: "Got Client event BLE_GAP_EVENT_MTU"
D NimBLEClient: "Got Client event BLE_GAP_EVENT_DISCONNECT"

I think the issue is indeed that BLE_GAP_EVENT_DISCONNECT arrives AFTER calling connect() again.

I think disconnect() should wait for this event...!

@Jeroen88
Copy link
Author

Jeroen88 commented May 28, 2020

Adding a 200 ms delay between createClient() and connect() solves the problem, 100 ms is too short. Still I think disconnect() should wait for the event.

@Staars
Copy link
Contributor

Staars commented May 29, 2020

Adding a 200 ms delay between createClient() and connect() solves the problem, 100 ms is too short. Still I think disconnect() should wait for the event.

Interesting observation, I will test this too.

@h2zero
Copy link
Owner

h2zero commented May 29, 2020

What is the purpose of doing this? It seems odd to me to create a client object delete it and create another in such a short time, why not just reuse the client object?

Still I think disconnect() should wait for the event.

That would unnecessarily slow down other applications, if you really need to know the client is disconnected there is a callback for that.

@Jeroen88
Copy link
Author

In the integration I am creating several devices are read out independently. Most don't need a connection, some do. I just want to use the functionality that is there. Also, I think it should always work

Could you give me some directions how to check if the client has disconnected? The function isDisconnected() does not do this job

@chegewara
Copy link

For me the solution was to erase the flash , which seemed to have solved it. In the end I erased it basically before every upload.

This is must when you are building bluetooth app.

@chegewara
Copy link

D FreeRTOS: ">> wait: Semaphore waiting: name: OpenEvt (0x3ffc88fc), owner: connect for connect"
D NimBLEClient: "Got Client event BLE_GAP_EVENT_MTU"
D NimBLEClient: "Got Client event BLE_GAP_EVENT_DISCONNECT"

This may have happen when there is no successful connection, maybe except MTU exchange, because this requires full connection established, unless MTU is called too early (in wrong place).

@Staars
Copy link
Contributor

Staars commented May 29, 2020 via email

@h2zero
Copy link
Owner

h2zero commented May 30, 2020

This issue was just resolved in commit 4c798fe.

@Jeroen88
Copy link
Author

This issue was just resolved in commit 4c798fe.

I can confirm that. Thank you @h2zero!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants