Problem discovering own services, no BLE_DB_DISCOVERY_COMPLETE event

[Esteban Gutiérrez Correa]

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

[Edvin]

Hello,

As I don't have your central project,it is hard to say exactly what the issue is.

I assume that you don't have any debug capabilities, but can you go into the ble_db_discovery_on_ble_evt, and try to print a string on each of the event cases, to see what sort of discovery events you get? I am also not sure what SDK you use, but in SDK12.3.0, which is the latest SDK supporting nRF51, try to do something like this:

void ble_db_discovery_on_ble_evt(ble_db_discovery_t * const p_db_discovery,
                                 const ble_evt_t * const    p_ble_evt)
{
    VERIFY_PARAM_NOT_NULL_VOID(p_db_discovery);
    VERIFY_PARAM_NOT_NULL_VOID(p_ble_evt);
    VERIFY_MODULE_INITIALIZED_VOID();

    switch (p_ble_evt->header.evt_id)
    {
        case BLE_GATTC_EVT_PRIM_SRVC_DISC_RSP:
            on_primary_srv_discovery_rsp(p_db_discovery, &(p_ble_evt->evt.gattc_evt));
            printf("PRIM_SRVC");
            break;

        case BLE_GATTC_EVT_CHAR_DISC_RSP:
            on_characteristic_discovery_rsp(p_db_discovery, &(p_ble_evt->evt.gattc_evt));
            printf("CHAR_DISC");
            break;

        case BLE_GATTC_EVT_DESC_DISC_RSP:
            on_descriptor_discovery_rsp(p_db_discovery, &(p_ble_evt->evt.gattc_evt));
            printf("EVT_DESC");
            break;

        case BLE_GAP_EVT_DISCONNECTED:
            on_disconnected(p_db_discovery, &(p_ble_evt->evt.gap_evt));
            printf("DISC_DISCONNECTED");
            break;

        default:
            break;
    }
}

To see if any of these events trigger.

What is the event ble_evt_dispatch 17?

BLE_GAP_EVT_AUTH_KEY_REQUEST?

Are you handling this event? I can't see it in the scenario when everything goes well in your first log.

 

Do you have a development kit where you can actually debug?

 

Best regards,

Edvin

[Edvin]

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

[Esteban Gutiérrez Correa]

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

[Edvin]

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

[Esteban Gutiérrez Correa]

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