This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Problem discovering own services, no BLE_DB_DISCOVERY_COMPLETE event

Hello all, 

I'm working with the nRF51 SoCs, with the s130 SoftDevice and SDK12.1.0

I have a BLE Nano from Red Bear Lab that has a nRF51822 doing adv and it expose my own service, when I write a key in one of its characteristics value it opens a door, this works fine when I do this from an Android phone with the nRFConnect app.

Now I am trying to do that without the phone, so I flashed a central code to another BLE Nano that when it receives some external stimulus it starts to scan, connect, discovery, write and finally disconnect from the peripheral device that opens the door.

Using uart for debug and printing a message each time the device go to the ble_evt_dispatch() like this:

static void ble_evt_dispatch(ble_evt_t * p_ble_evt) {
	printf("ble_evt_dispatch\t");
	printf("%x", (int)p_ble_evt->header.evt_id);
	printf("\r\n");
	ble_tnds_c_on_ble_evt(&m_ble_tnds_c, p_ble_evt);
	on_ble_evt(p_ble_evt);
	bsp_btn_ble_on_ble_evt(p_ble_evt);
	ble_db_discovery_on_ble_evt(&m_ble_db_discovery, p_ble_evt);
}

printing something like this:

It works well most of the time, but some times the central device start scanning, then it connects to the peripheral device, and for an unknown the next dispatch event is the BLE_GAP_EVT_DISCONNECTED, this means that for some reason it connects and then disconnects without discovering the peripheral services,

I also tried the solution to the issue explained in this question.

I was wondering if anyone could help me understand what's going on.  

thanks

Edited: second image fixed, changing the numbers from decimal to hexadecimal

Parents
  • Ok. I see that you changed from dec to hex, so it wasn't 17, but 0x11, like in the first image. That is the disconnected event, then.

     

    On what condition do you disconnect? Do you trigger this from the central? Can it be that the you disconnect from the central (i.e. that the application on the central calls sd_ble_gap_disconnect()) before the discovery is complete?

     

    Did you try the suggestion in my previous reply?

     

    Best regards,

    Edvin

  • Hello Edvin,

    I did it, it gave me the idea of the discovery events, but the problem continues, sometimes the device disconnects before doing any discovery.

    These are the messages when it works fine,

    these are when it works wrong

    In my central app, the sd_ble_gap_disconnect() function is called when a GATTC or GATTS TIMEOUT event occurs, and before going there the device had to go through the dispatch, and finally is called after the client has written in the characteristic.

    I have a question, is there any way to know in the client (an event) when the server gave the order to finish the connection?

    I'll attach my code to this reply, so you can see what I'm doing.

    I have a nRF51DK where I can debug.

    thanks, for your quick response, and sorry for my delay

    .puerta_and_toque.zip

Reply
  • Hello Edvin,

    I did it, it gave me the idea of the discovery events, but the problem continues, sometimes the device disconnects before doing any discovery.

    These are the messages when it works fine,

    these are when it works wrong

    In my central app, the sd_ble_gap_disconnect() function is called when a GATTC or GATTS TIMEOUT event occurs, and before going there the device had to go through the dispatch, and finally is called after the client has written in the characteristic.

    I have a question, is there any way to know in the client (an event) when the server gave the order to finish the connection?

    I'll attach my code to this reply, so you can see what I'm doing.

    I have a nRF51DK where I can debug.

    thanks, for your quick response, and sorry for my delay

    .puerta_and_toque.zip

Children
  • Maybe the peripheral's application crashes?

    Can you try to print the disconnect reason within the Disconnected event?

    Do something like this in the BLE_GAP_EVT_DISCONNECTED event in main.c:

    case BLE_GAP_EVT_DISCONNECTED:
        printf("Disconnected, reason: 0x%02x\r\n", p_ble_evt->evt.gap_evt.params.disconnected.reason);
    

    and see if you can see the disconnect reason.

     

    How long is the time between the connected and the disconnected event?

     

    Can you see whether the peripheral device resets at some point, or if it is running continuously the times when the central can't discover the services?

     

    Best regards,

    Edvin

  • Hello Edvin,

    The disconnect reason is the BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED 0x3e, its a little difficult for me to debug the peripheral device in this moment, because it is in service, so I retry to connect 3 times if the disconnection reason is BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED 0x3e for a fast solution, I'll try to debug the peripheral, and I'll tell you what I could see.

    How long is the time between the connected and the disconnected event?

    When the central device can't discover the peripheral, it is immediately, when the central can discover the services it takes like 4 or more seconds, how can I speed up this process?, is there a way to save the peripheral services and speed up the discovery of the characteristic handle.

    Thank you

  • Hello,

     

    I saw this old DevZone post.

    The original poster in that case has posted a sniffer trace. In that trace I can see that  the peripheral isn't responding to the connection request from the central, which lead to a BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED.

     

    Are you able to do the same logging on the peripheral when the device can't connect? Does the application crash? Do you get a reset?

     

    I wasn't able to find any datasheets to your BLE Nano. Does the BLE nano have an external LFXTAL? It might also be that the connection sometimes fails to be established if the clocks are not synchronized. It is less likely, but it might be.

     

    So can you do the following:

    Try to debug the peripheral. Print a message that should only be printed once when you start the application. See if this is printed when the disconnect happens, which would indicate a reset in the peripheral. If not, do you get the connected event, or anything else of interest in the peripheral log?

     

    Is it possible for you to do a sniffer trace? If you have a DK, you can use the nRF Sniffer.

     

    Best regards,

    Edvin

Related