Service Discovery Failed using pc-ble-driver

RE: Service Discovery Failed using pc-ble-driver

mmercier — Thu, 07 May 2020 15:49:16 GMT

I finally figured it out!

So when I had searched for descriptors after getting my characteristics, I was getting a couple of different values, some with UUIDs that were different from what I expected to see, based on the values in nRF Connect. For each characteristic, one of the descriptors I could receive would have the same UUID as the characteristic, but with a different handle.

Turns out, I needed to pass THIS handle to the write_params, not the handle of the characteristic. Now, my write command is working, and I can see the data on the peripheral's bus!

I also verified my other questions for myself, I was able to figure out how to toggle notifications, and get back the notification data read on a characteristic.

I think I've finally got everything I need for this project! Thanks for the help!

RE: Service Discovery Failed using pc-ble-driver

mmercier — Thu, 07 May 2020 14:57:53 GMT

I think there may be an issue...

I changed my discovery routines to search instead for the first characteristic, which is notify only. I discovered it correctly, and then had my function write to its handle, and I got no error messages, and the handler went into the BLE_GATTC_EVT_WRITE_CMD_TX_COMPLETE state. This characteristic does not have write privileges, it is notify only, so I think I should see some failure somewhere. So something is not writing correctly.

RE: Service Discovery Failed using pc-ble-driver

mmercier — Thu, 07 May 2020 14:34:56 GMT

I did end up fixing that, it didn't have an effect.

I'm not sure what you mean about the callback event, I don't have access to the code that is running on the peripheral. I am just connecting to it and monitoring its parallel bus.

I did some experimenting, and I tried setting the write_params.handle value to m_hrm_char_handle1 instead of m_hrm_char_handle2. This is a variable I intend to use for one of the other characteristics, but for now, I'm only discovering the "write" characteristic, which is being stored in m_hrm_char_handle2.

So basically, I tried calling the same command with a non-assigned, zero-value handle as the write_params.handle value, and I got the same response. As in, there was no error code, and the event handler went into the state for BLE_GATTC_EVT_WRITE_CMD_TX_COMPLETE. I was surprised to not see some error. This makes me wonder if my command is actually doing anything with the actual handle being used. For what it's worth, I did pause the code to check and ensure my m_hrm_char_handle2 value is set to the characteristic's handle that was discovered, and that the discovered characteristic's UUID is the "write" characteristic I'm wanting to use.

RE: Service Discovery Failed using pc-ble-driver

Edvin — Thu, 07 May 2020 14:14:52 GMT

A Shot in the dark:

You set enc_data[0] twice, and you do not set enc_data[10]. Just in case you are not checking for the event, but only a specific packet. Since you mention that you tried to reverse the packet here as well. The content of the payload shouldn't really matter for the BLE stack.

Do you check whether or not the callback event is triggered on the peripheral?

RE: Service Discovery Failed using pc-ble-driver

mmercier — Thu, 07 May 2020 13:14:13 GMT

Okay, so I did some digging and I found a function that I think is right for what I need. It is called "sd_ble_gattc_write". I modified my new "writeble" routine like this:

static uint32_t writeble()
{
    uint32_t error_code;
	uint8_t enc_data[13];
	ble_gattc_write_params_t write_params;
	
	enc_data[0] = 0x01;
	enc_data[1] = 0x00;
	enc_data[2] = 0xFF;
	enc_data[3] = 0x20;
	enc_data[4] = 0x08;
	enc_data[5] = 0x01;
	enc_data[6] = 0x02;
	enc_data[7] = 0x03;
	enc_data[8] = 0x04;
	enc_data[9] = 0x05;
	enc_data[0] = 0x06;
	enc_data[11] = 0x07;
	enc_data[12] = 0x08;
	
	write_params.write_op = BLE_GATT_OP_WRITE_CMD;
	write_params.flags = BLE_GATT_EXEC_WRITE_FLAG_PREPARED_WRITE;
	write_params.handle = m_hrm_char_handle2;
	write_params.offset = 0;
	write_params.len = 0xD;
	write_params.p_value = enc_data;
	
	error_code = sd_ble_gattc_write(m_adapter, m_connection_handle, &write_params);
	
	if(error_code != NRF_SUCCESS){
		printf("Failed to send. Error code 0x%02X\n", error_code);
		fflush(stdout);
		return error_code;
	}
	return NRF_SUCCESS;
}

Now, I don't get any error when I run this code, and the event handler enters the case for BLE_GATTC_EVT_WRITE_CMD_TX_COMPLETE, which should mean that the Write Without Response command completed successfully.

However, I am not seeing the proper response from my peripheral. For reference, I am monitoring a parallel bus on my peripheral, and when this characteristic is written to (using the specified 13-byte packet layout), I will see a response. If I use nRF Connect, I can type these 13 bytes into the characteristic, click "write", and I will see the response on the bus I'm monitoring. However, when using this write command in the program, nothing appears on the bus.

I know the peripheral is behaving properly, since it works in nRF Connect, and it seems that the write command is executing correctly, so there must just be something configured differently in how the program is setting up the command vs how the nRF Connect is setting up the command. I have already tried reversing the byte order in the enc_data array, to no avail. As with the previous code I posted, the handle used here is the one that was assigned to my "write" characteristic (the UUID is matched correctly). I am only discovering this one characteristic for right now, so as to simplify the process. This characteristic does not have any descriptors defined, so I am not calling the "descr_discovery_start" function for now.

RE: Service Discovery Failed using pc-ble-driver

mmercier — Thu, 07 May 2020 11:48:42 GMT

Changing the uuid.type to 0x00 had no change to the behavior with it defined as BLU_UUID_TYPE_VENDOR_BEGIN. So, I am still discovering the service properly, and I'm able to get a characteristic and its descriptor.

By looking through other cases here on the help website, I found suggestions that users simply call the "sd_ble_gattc_characteristics_discover" routine multiple times in order to discover more than one characteristic, just increasing the lower boundary of the handle range each time. I thought this was strange, since the params.char_disc_rsp object has a count parameter, it seems like it should be able to return multiple characteristics. Either way, by using multiple calls, I've been able to assign all 3 characteristics to different handles. For now, though, since I am still trying to figure out the read/write commands, I'm only assigning one characteristic at a time.

So, my next concern is with the write command. Currently, I have my code begin the "sd_ble_gattc_characteristics_discover" routine using an increased lower handle, so that the characteristic it returns has a UUID that matches my peripheral's "write" characteristic. I am wanting to know what code to use to write from this characteristic, mimicking the behavior of the nRF Connect program, where I can type data into the characteristic's string field and click the "write" button.

I've started by looking at the HRM code in the pc-ble-driver example. I've added a function based on this example, here's what it looks like so far:

static uint32_t writeble()
{
    uint32_t error_code;
	uint8_t enc_data[13];
	uint16_t data_len;
	ble_gatts_hvx_params_t hvx_params;
	
	data_len = (uint16_t)13;
	
	enc_data[0] = 0x01;
	enc_data[1] = 0x00;
	enc_data[2] = 0xFF;
	enc_data[3] = 0x20;
	enc_data[4] = 0x08;
	enc_data[5] = 0x01;
	enc_data[6] = 0x02;
	enc_data[7] = 0x03;
	enc_data[8] = 0x04;
	enc_data[9] = 0x05;
	enc_data[0] = 0x06;
	enc_data[11] = 0x07;
	enc_data[12] = 0x08;
	
	hvx_params.handle = m_hrm_char_handle2;
	hvx_params.type = BLE_GATT_HVX_NOTIFICATION;
	hvx_params.offset = 0;
	hvx_params.p_len = &data_len;
	hvx_params.p_data = enc_data;
	
	error_code = sd_ble_gatts_hvx(m_adapter, m_connection_handle, &hvx_params);
	
	if(error_code != NRF_SUCCESS){
		printf("Failed to send. Error code 0x%02X\n", error_code);
		fflush(stdout);
		return error_code;
	}
	return NRF_SUCCESS;
}

This is based on the HRM example. The data is a 13-byte packet, it is the same data that I type into the characteristic's field in the nRF Connect program. The value "m_hrm_char_handle_2" is the handle that this characteristic is being assigned to by "sd_ble_gattc_characteristics_discover".

I've modified the main loop of the example, which waits for a character input into the terminal, then calls the HRC notification toggle. I've commented out this function call, and replaced it with a call to this new function. So after the peripheral is connected, and the service, characteristic, and descriptor are all discovered, pressing a key will call this function.

As it is now, doing so gives me an error code of 0x05, which seems to correspond to NRF_ERROR_NOT_FOUND. So something is not being set up correctly. Is there any other code I need to add to ensure that I can carry out this write command? Or am I going about this the wrong way? For reference, this characteristic only has the "WriteWithoutResponse" property enabled. So if this is doing something other than a write (without response) type of command, maybe that's where the error is from. But since this is the only "write" type command I could find in the examples, I'm not sure where to go from here.

Please let me know if you've got any pointers for me, thanks!

RE: Service Discovery Failed using pc-ble-driver

Edvin — Thu, 07 May 2020 10:03:05 GMT

[quote user="mmercier"]Changing the 16-bit UUID to 0x0001 worked![/quote]

Great! That is good to hear. This is why I wanted you to check the ble_nus_c example, because I wanted you to compare the UUID with the part of the UUID that the central looked for in the service discovery.

[quote user="mmercier"]I just wanted to ask if these handles need to match, or if they are just assigned sequentially and it doesn't particularly matter the exact value.[/quote]

They do not need to match exactly, no. They are just used internally in your application, and are assigned during runtime.

[quote user="mmercier"] My peripheral's service has 3 characteristics, but the call to "sd_ble_gattc_characteristics_discover" is only returning a value of 1 for the count of characteristics found[/quote]

Can you try to set the uuid.type to 0x00 in start_discovery()? What does things look like in the on_service_discovery_response() then?

RE: Service Discovery Failed using pc-ble-driver

mmercier — Wed, 06 May 2020 13:48:03 GMT

One more thing I noticed about the handles, when I discover the characteristic with handle 0xF, and the event handler moves into the descriptor discovery, the returned value of the CCCD handle is also 0xF. On the other hand, in nRF Connect, the characteristic's handle is 0x10, and the CCCD handle is 0x11. It seems strange to me that the program would read the same handle for the characteristic and its CCCD. Is this normal? Thanks.

RE: Service Discovery Failed using pc-ble-driver

mmercier — Wed, 06 May 2020 13:29:50 GMT

Changing the 16-bit UUID to 0x0001 worked! I can now move past the service discovery response. So it seems that the 128-bit UUID needs to be defined in little endian format, but the 16-bit service UUID section must be big endian.

I am now able to move past into the characteristic discovery. This has given me a lot more to experiment with. I just have a few questions that I am curious about.

1: I am able to discover a characteristic from my service and read back its UUID. The program also responds with the handle value of the characteristic (it is 0xF, one up from the service handle of 0xE). However, I noticed that, when connecting to the peripheral in nRF Connect, the handle assigned to the characteristic is not 0xF, but 0x10 (service handle is still 0xE, I couldn't find where 0xF was). I just wanted to ask if these handles need to match, or if they are just assigned sequentially and it doesn't particularly matter the exact value.

2: My peripheral's service has 3 characteristics, but the call to "sd_ble_gattc_characteristics_discover" is only returning a value of 1 for the count of characteristics found (only the first, with the 0xF handle, is being found). I experimented by changing the value of handle_range.start_handle to be equal to the service handle + 2 (so that it would skip the first characteristic), and it still returned a count value of 1, but this time, it was the service's second characteristic that had been found (since I made it skip the first). So it seems like something is causing the function to only consider the first characteristic it finds. This seems to make sense, due to the expected HRM only having the one characteristic, but I couldn't find anywhere that specifically told the function to only look for up to 1 characteristic. Is there some setting I can modify to have this function discover all three?

Thanks for the suggestions!

RE: Service Discovery Failed using pc-ble-driver

Edvin — Wed, 06 May 2020 12:11:06 GMT

I do not mean that you should use the SDK's example in the end, but that this example shows you how to try to discover a 128bit UUID. I guess if you ask 4 different people how to develop your application, you will get 4 different answers. What I wanted you to check in the central ble_app_uart_c example was what octets that are being used in the service discovery. This has nothing to do with your scanning or find_adv_name() function. Do you know what service discovery is, in the first place?

The reason I started listing the UUID of the ble_app_uart peripheral is because it is a 128bit UUID.

[quote user="mmercier"]I've also changed the value of BLE_UUID_HEART_RATE_SERVICE to 0x0100, to match with octets 12-13 of my service UUID.[/quote]

Can you try to set it to 0x0001 as well? This is why I tried to point you to the ble_app_uart example, to show a bit of how the UUID is represented in different applications. I am sorry if it was confusing.

If that doesn't work, what happens if you set the uuid.type to 0x00 in start_discovery()? Do you get a on_service_discovery_response() callback in that case? If so, what does the log say from this part?

RE: Service Discovery Failed using pc-ble-driver

mmercier — Tue, 05 May 2020 19:32:20 GMT

Okay, so I've gotten into contact with a Nordic rep to try and figure out what kind of software I should be using for the project I need. He has informed me that, in order to do what I need, I will need to use the pc-ble-driver, and modify the HRC example to search for my peripheral rather than the HRM it's set up to look for. So that UART example will not work. This is what I'd thought at first, but I wanted to make sure I wasn't just making things more difficult for myself.

So now that I know I'm on the right path, I need to figure out how to modify this code in order to search for my specific peripheral rather than the HRM it's normally expecting. So far, I have made 2 major modifications to the original HRC code. The first is in the "find_adv_name" routine, called in the "on_adv_report" routine. Here is the original version of this routine:

static bool find_adv_name(const ble_gap_evt_adv_report_t *p_adv_report, const char * name_to_find)
{
    uint32_t err_code;
    data_t   adv_data;
    data_t   dev_name;

    // Initialize advertisement report for parsing
#if NRF_SD_BLE_API >= 6
    adv_data.p_data     = (uint8_t *)p_adv_report->data.p_data;
    adv_data.data_len   = p_adv_report->data.len;
#else
    adv_data.p_data     = (uint8_t *)p_adv_report->data;
    adv_data.data_len   = p_adv_report->dlen;
#endif

    //search for advertising names
    err_code = adv_report_parse(BLE_GAP_AD_TYPE_COMPLETE_LOCAL_NAME,
                                &adv_data,
                                &dev_name);
    if (err_code == NRF_SUCCESS)
    {
        if (memcmp(name_to_find, dev_name.p_data, dev_name.data_len )== 0)
        {
            return true;
        }
    }
    else
    {
        // Look for the short local name if it was not found as complete
        err_code = adv_report_parse(BLE_GAP_AD_TYPE_SHORT_LOCAL_NAME,
                                    &adv_data,
                                    &dev_name);
        if (err_code != NRF_SUCCESS)
        {
            return false;
        }
        if (memcmp(name_to_find, dev_name.p_data, dev_name.data_len )== 0)
        {
            return true;
        }
    }
    return false;
}

And here is my modified code:

static bool find_adv_name(const ble_gap_evt_adv_report_t *p_adv_report, uint8_t name_to_find)
{
    uint32_t err_code;
    data_t   adv_data;
    data_t   dev_name;

    // Initialize advertisement report for parsing
//#if NRF_SD_BLE_API >= 6
    adv_data.p_data     = (uint8_t *)p_adv_report->data.p_data;
    adv_data.data_len   = p_adv_report->data.len;
//#else
    //adv_data.p_data     = (uint8_t *)p_adv_report->data;
    //adv_data.data_len   = p_adv_report->dlen;
//#endif
	
    //search for advertising names
    /*err_code = adv_report_parse(BLE_GAP_AD_TYPE_COMPLETE_LOCAL_NAME,
                                &adv_data,
                                &dev_name);*/
    err_code = adv_report_parse(BLE_GAP_AD_TYPE_MANUFACTURER_SPECIFIC_DATA,
                                &adv_data,
                                &dev_name);
	
    if (err_code == NRF_SUCCESS)
    {
        //if (memcmp(name_to_find, dev_name.p_data, dev_name.data_len )== 0)
        if (memcmp(&name_to_find, dev_name.p_data, 1 )== 0)
        {
            return true;
        }
    }
    else
    {
        // Look for the short local name if it was not found as complete
        err_code = adv_report_parse(BLE_GAP_AD_TYPE_SHORT_LOCAL_NAME,
                                    &adv_data,
                                    &dev_name);
        if (err_code != NRF_SUCCESS)
        {
            return false;
        }
        if (memcmp(name_to_find, dev_name.p_data, dev_name.data_len )== 0)
        {
            return true;
        }
    }
    return false;
}

As you can see, I've changed the final argument of this function to be a uint8_t rather than a const char*. This is because my peripheral does not advertise its Name data (which is a const char*), but it does advertise its Manufacturer Specific data, which is a uint8_t. The "on_adv_report" function calls "find_adv_name", and passes TARGET_DEV_NAME as its final argument. I've changed this #define statement from a string to the uint8_t value of the Manufacturer Specific Data I intend to find.

I am fairly confident that this change works, as the program seems to find and connect to my peripheral properly. The remainder of the "on_adv_report" function carries on without any error flags returned.

The other change I've made is what I'd described above, in the "service_discovery_start" routine, called by "on_connected". The full text is pasted above, but basically, I've changed the uuid type value from BLE_UUID_TYPE_BLE to BLE_UUID_TYPE_VENDOR_BEGIN, changed the value of the 16-bit UUID field to 0x0100 (octets 12-13 of my peripheral's service UUID), and defined a struct for a 128-bit UUID, populated it with the bytes of my peripheral's UUID, and passed it with a call to "sd_ble_uuid_vs_add".

Notably, before I had added this call to "sd_ble_uuid_vs_add", I was getting an error returned by the "sd_ble_gattc_primary_services_discover" call. After adding this 128-bit UUID, I no longer get an error here, and I am able to move on to the next event. This leads me to believe that the UUID is being passed properly.

Now, my issue is with the next pass through the event handler, which goes to the routine "on_service_discovery_response". The very first thing done in this routine is to check the value of the "gatt_service" parameter of the struct passed by the event handler (called p_ble_evt->evt.gattc_evt). This is resulting in an error, as the value is not 0x0, but 0x10A.

By stepping through the code following the completion of the "on_connected" routine, I discovered that this "gatt_service" value stays 0 until the end of that pass through the event handler. Then, on the next pass (when the "on_service_discovery_response" will be called), the value of "gatt_service" changes to 0x10A. This seems to correspond to the error message for BLE_GATT_STATUS_ATTERR_ATTRIBUTE_NOT_FOUND.

I need to know how to continue on from here. I am not getting any error messages in any of the fields that I've modified, so I do not know where this error could be coming from.

RE: Service Discovery Failed using pc-ble-driver

mmercier — Tue, 05 May 2020 18:24:29 GMT

I have been looking at that example code you mention, and I don't think it will work in this project. It seems to be using an entirely different set of library functions than what I have. I am currently using the libraries/headers/dlls from the pc-ble-driver.

Is there some other set of libraries/headers/dlls that I could use in order to build a project using these other example files you sent? I want to know the simplest way to build a C program which will allow me to connect to my peripheral, and read/write to its characteristics through my dongle, which will be attached to the PC running the C program.

I keep getting conflicting information about how to go about making this program, and I want to ensure I am going down the right path for what I'm trying to accomplish.

RE: Service Discovery Failed using pc-ble-driver

mmercier — Tue, 05 May 2020 16:24:08 GMT

As I'd mentioned, after adding the call to "sd_ble_uuid_vs_add", I do not get error messages in the "service_discovery_start" or "on_connected" functions. I do not get any errors until after the event handler finishes the pass in which it called this function. When the event handler enters its next pass, with the p_ble_evt->header.evt_id set to BLE_GATTC_EVT_PRIM_SRVC_DISC_RSP, this is when the value of p_ble_evt->evt.gattc_evt.gatt_status becomes 0x10A. This is the error I am trying to solve. Thanks.

RE: Service Discovery Failed using pc-ble-driver

mmercier — Tue, 05 May 2020 15:18:25 GMT

I have been describing my modifications to the "service_discovery_start" routine in the above posts, as this is the routine that I'd been originally seeing errors in. For reference, here is the code for this routine:

static uint32_t service_discovery_start()
{
    uint32_t   err_code;
    uint16_t   start_handle = 0x01;
    ble_uuid_t srvc_uuid;
	ble_uuid128_t srvc_uuid128;

    printf("Discovering primary services\n");
    fflush(stdout);

    //srvc_uuid.type = BLE_UUID_TYPE_BLE;
    srvc_uuid.type = BLE_UUID_TYPE_VENDOR_BEGIN;
    //srvc_uuid.type = BLE_UUID_TYPE_UNKNOWN;
    srvc_uuid.uuid = BLE_UUID_HEART_RATE_SERVICE;
	
	//for(int i=0;i<16;i++)
		//srvc_uuid128.uuid128[i] = BLE_UUID_LONG[i];
    	//printf("%02X ", BLE_UUID_LONG[i]);
	srvc_uuid128.uuid128[0] = 0x32;
	srvc_uuid128.uuid128[1] = 0x0D;
	srvc_uuid128.uuid128[2] = 0x3B;
	srvc_uuid128.uuid128[3] = 0x45;
	srvc_uuid128.uuid128[4] = 0x12;
	srvc_uuid128.uuid128[5] = 0x32;
	srvc_uuid128.uuid128[6] = 0xF3;
	srvc_uuid128.uuid128[7] = 0x8B;
	srvc_uuid128.uuid128[8] = 0x84;
	srvc_uuid128.uuid128[9] = 0x47;
	srvc_uuid128.uuid128[10] = 0x07;
	srvc_uuid128.uuid128[11] = 0xEB;
	srvc_uuid128.uuid128[12] = 0x00;
	srvc_uuid128.uuid128[13] = 0x00;
	srvc_uuid128.uuid128[14] = 0xC3;
	srvc_uuid128.uuid128[15] = 0x17;
	
	err_code = sd_ble_uuid_vs_add(m_adapter, &srvc_uuid128, &srvc_uuid.type);
	
	if (err_code != NRF_SUCCESS)
    {
        printf("Failed to add custom 128-bit UUID\n");
        fflush(stdout);
    }

    // Initiate procedure to find the primary BLE_UUID_HEART_RATE_SERVICE.
    err_code = sd_ble_gattc_primary_services_discover(m_adapter,
                                                      m_connection_handle, start_handle,
                                                      &srvc_uuid);
                                                      //NULL);
    if (err_code != NRF_SUCCESS)
    {
        printf("Failed to initiate or continue a GATT Primary Service Discovery procedure\n");
        fflush(stdout);
    }

    return err_code;
}

The "on_connected" routine is identical to what you've posted. As you can see, I've changed the type parameter of the srvc_uuid struct to BLE_UUID_TYPE_VENDOR_BEGIN, and I've defined a new struct (srvc_uuid128) which I've populated with the values of my device's 128-bit UUID. I've added a call to "sd_ble_uuid_vs_add" to add this 128-bit UUID to the list of available UUIDs, and this does not return an error code.

I've also changed the value of BLE_UUID_HEART_RATE_SERVICE to 0x0100, to match with octets 12-13 of my service UUID. For reference, the full UUID of the service is 17C30001EB0747848BF33212453B0D32.

I have been using this code as my base because it is the only example in the pc-ble-driver. I've been told multiple times, by multiple different Nordic reps, that this is what I need to use. So that is why I am using it. This UART example is not in the pc-ble-driver. I need to be able to make a C program that can connect to my device's service, and read/write to its characteristics. From all I've been told, I need the pc-ble-driver to be able to do that. If there is other code that can do this, that can be built into a C project, please let me know. Thanks.

RE: Service Discovery Failed using pc-ble-driver

Edvin — Tue, 05 May 2020 14:55:17 GMT

What does your on_connected() look like, then?

[quote user="mmercier"]If it helps, the only code I've modified is the "on_adv_report" routine[/quote]

That is probably the issue, because this example will by default look for the HRS UUID in the service discovery. This is why I keep pointing to the SDK example ble_app_uart_c, because it shows you how to look for a long (128-bit) UUID, which you then need to modify to your own.

If you haven't changed it, your on_connected() function looks like this, right?

static void on_connected(const ble_gap_evt_t * const p_ble_gap_evt)
{
    printf("Connection established\n");
    fflush(stdout);

    m_connected_devices++;
    m_connection_handle         = p_ble_gap_evt->conn_handle;
    m_connection_is_in_progress = false;

    service_discovery_start();
}

And your service_discover_start() looks like this:

static uint32_t service_discovery_start()
{
    uint32_t   err_code;
    uint16_t   start_handle = 0x01;
    ble_uuid_t srvc_uuid;

    printf("Discovering primary services\n");
    fflush(stdout);

    srvc_uuid.type = BLE_UUID_TYPE_BLE;
    srvc_uuid.uuid = BLE_UUID_HEART_RATE_SERVICE;

    // Initiate procedure to find the primary BLE_UUID_HEART_RATE_SERVICE.
    err_code = sd_ble_gattc_primary_services_discover(m_adapter,
                                                      m_connection_handle, start_handle,
                                                      &srvc_uuid);
    if (err_code != NRF_SUCCESS)
    {
        printf("Failed to initiate or continue a GATT Primary Service Discovery procedure\n");
        fflush(stdout);
    }

    return err_code;
}

What does service_discover_start()? And did you modify it somehow? If not, I suggest you try to change BLE_UUID_TYPE_BLE and BLE_UUID_HEART_RATE_SERVICE according to the device that you are trying to connect to.

Don't use BLE_UUID_TYPE_BLE, because these are the 16-bit UUIDs defined by Bluetooth. You want to use BLE_UUID_TYPE_VENDOR_BEGIN, which are the 128-bit UUIDs. Then you need to change the BLE_UUID_HEART_RATE_SERVICE to a variable containing the UUID that you are expecting to find.

Look at how this is done in SDK16.0.0\examples\ble_central\ble_app_uart_c.

If you look in ble_nus_c_init(). the base_uuid is added as NUS_BASE_UUID, and the discovery is registered as uart_uuid.

Now, I have not tried this with pc-ble-driver, which works a bit different, but you need to change the srvc_uuid that you pass on in service_discovery_start. Try to do this, and see if you can manage to make it discover the custom uuid.

RE: Service Discovery Failed using pc-ble-driver

Edvin — Tue, 05 May 2020 14:37:17 GMT

Adding your code using insert->code for readability:

static void ble_evt_dispatch(adapter_t * adapter, ble_evt_t * p_ble_evt)
{
    if (p_ble_evt == NULL)
    {
        printf("Received an empty BLE event\n");
        fflush(stdout);
        return;
    }
    
    switch (p_ble_evt->header.evt_id)
    {
        case BLE_GAP_EVT_CONNECTED:
            on_connected(&(p_ble_evt->evt.gap_evt));
            break;
        
        case BLE_GAP_EVT_DISCONNECTED:
            printf("Disconnected, reason: 0x%02X\n",
            p_ble_evt->evt.gap_evt.params.disconnected.reason);
            fflush(stdout);
            m_connected_devices--;
            m_connection_handle = 0;
            break;
        
        case BLE_GAP_EVT_ADV_REPORT:
            on_adv_report(&(p_ble_evt->evt.gap_evt));
            break;
        
        case BLE_GAP_EVT_TIMEOUT:
            on_timeout(&(p_ble_evt->evt.gap_evt));
            break;
        
        case BLE_GATTC_EVT_PRIM_SRVC_DISC_RSP:
            on_service_discovery_response(&(p_ble_evt->evt.gattc_evt));
            break;
        
        case BLE_GATTC_EVT_CHAR_DISC_RSP:
            on_characteristic_discovery_response(&(p_ble_evt->evt.gattc_evt));
            break;
        
        case BLE_GATTC_EVT_DESC_DISC_RSP:
            on_descriptor_discovery_response(&(p_ble_evt->evt.gattc_evt));
            break;
        
        case BLE_GATTC_EVT_WRITE_RSP:
            on_write_response(&(p_ble_evt->evt.gattc_evt));
            break;
        
        case BLE_GATTC_EVT_HVX:
            on_hvx(&(p_ble_evt->evt.gattc_evt));
            break;
        
        case BLE_GAP_EVT_CONN_PARAM_UPDATE_REQUEST:
            on_conn_params_update_request(&(p_ble_evt->evt.gap_evt));
            break;
        
        case BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST:
            on_exchange_mtu_request(&(p_ble_evt->evt.gatts_evt));
            break;
        
        case BLE_GATTC_EVT_EXCHANGE_MTU_RSP:
            on_exchange_mtu_response(&(p_ble_evt->evt.gattc_evt));
            break;
        
        default:
            printf("Received an un-handled event with ID: %d\n", p_ble_evt->header.evt_id);
            fflush(stdout);
            break;
    }
}

RE: Service Discovery Failed using pc-ble-driver

mmercier — Tue, 05 May 2020 12:53:45 GMT

My code is based on the Heart Rate Collector example from the pc-ble-driver package, and has not been changed in terms of the event handler and any setup functions. Here is the event handler, for reference:

static void ble_evt_dispatch(adapter_t * adapter, ble_evt_t * p_ble_evt)
{
if (p_ble_evt == NULL)
{
printf("Received an empty BLE event\n");
fflush(stdout);
return;
}

switch (p_ble_evt->header.evt_id)
{
case BLE_GAP_EVT_CONNECTED:
on_connected(&(p_ble_evt->evt.gap_evt));
break;

case BLE_GAP_EVT_DISCONNECTED:
printf("Disconnected, reason: 0x%02X\n",
p_ble_evt->evt.gap_evt.params.disconnected.reason);
fflush(stdout);
m_connected_devices--;
m_connection_handle = 0;
break;

case BLE_GAP_EVT_ADV_REPORT:
on_adv_report(&(p_ble_evt->evt.gap_evt));
break;

case BLE_GAP_EVT_TIMEOUT:
on_timeout(&(p_ble_evt->evt.gap_evt));
break;

case BLE_GATTC_EVT_PRIM_SRVC_DISC_RSP:
on_service_discovery_response(&(p_ble_evt->evt.gattc_evt));
break;

case BLE_GATTC_EVT_CHAR_DISC_RSP:
on_characteristic_discovery_response(&(p_ble_evt->evt.gattc_evt));
break;

case BLE_GATTC_EVT_DESC_DISC_RSP:
on_descriptor_discovery_response(&(p_ble_evt->evt.gattc_evt));
break;

case BLE_GATTC_EVT_WRITE_RSP:
on_write_response(&(p_ble_evt->evt.gattc_evt));
break;

case BLE_GATTC_EVT_HVX:
on_hvx(&(p_ble_evt->evt.gattc_evt));
break;

case BLE_GAP_EVT_CONN_PARAM_UPDATE_REQUEST:
on_conn_params_update_request(&(p_ble_evt->evt.gap_evt));
break;

case BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST:
on_exchange_mtu_request(&(p_ble_evt->evt.gatts_evt));
break;

case BLE_GATTC_EVT_EXCHANGE_MTU_RSP:
on_exchange_mtu_response(&(p_ble_evt->evt.gattc_evt));
break;

default:
printf("Received an un-handled event with ID: %d\n", p_ble_evt->header.evt_id);
fflush(stdout);
break;
}
}

Previously, my issue with the UUIDs had occurred within the "on_connected" routine, but now, with the changes I described above, I've been able to move past this routine without errors. On the next pass through the event handler, I am entering the case for the "on_service_discovery_response" routine, and this is where I run into the error.

The very first thing done in the "on_service_discovery_response" routine is to check the "gatt_status" parameter of the struct being passed to the function (in this case, p_ble_evt->evt.gattc_evt is being passed, as can be seen above). If gatt_status is equal to 0, then the routine continues on, but displays an error message if it is anything else. In my case, I am getting error message 0x10A, which seems to correspond to BLE_GATT_STATUS_ATTERR_ATTRIBUTE_NOT_FOUND.

I stepped through the code using breakpoints to monitor this value, and see if I can figure out where it is being changed to 0x10A. As I mentioned, the event handler goes through the case for "on_connected" immediately before the case where I am seeing the error. During this entire pass through the event handler, the "gatt_status" parameter of p_ble_evt->evt.gattc_evt is equal to 0. This is true for when the "on_connected" routine is being executed, and for afterward, when the event handler case ends and goes to the end of the function.

However, when the event handler then enters its next pass, the "gatt_status" suddenly changes to 0x10A. I do not know what all is going on between passes through the event handler. I am assuming it is done using the library functions, but just stepping through, I don't see anything occurring between passes. Either way, something is occurring, since the value of p_ble_evt->header.evt_id is changing (so that the event handler enters a different case), and I am assuming whatever changes this value is also responsible for setting the gatt_status.

If it helps, the only code I've modified is the "on_adv_report" routine (to check for Manufacturer Specific Data rather than Device Name) and the "service_discovery_start" routine (to add the 128-bit UUID, as described above). Other than that, my code is effectively identical to the heart rate collector example in the pc-ble-driver github page.

RE: Service Discovery Failed using pc-ble-driver

Edvin — Tue, 05 May 2020 08:59:58 GMT

Where exactly does the BLE_GATT_STATUS_ATTERR_ATTRIBUTE_NOT_FOUND appear?

Is db_disc_handler() called? Or whatever function that is set to the event handler that is passed onto ble_db_discovery_init():

/** @brief Function for initializing the database discovery module. */
static void db_discovery_init(void)
{
    ble_db_discovery_init_t db_init;

    memset(&db_init, 0, sizeof(ble_db_discovery_init_t));

    db_init.evt_handler  = db_disc_handler;
    db_init.p_gatt_queue = &m_ble_gatt_queue;

    ret_code_t err_code = ble_db_discovery_init(&db_init);
    APP_ERROR_CHECK(err_code);
}

Does it have:

p_evt->evt_type == BLE_DB_DISCOVERY_COMPLETE?

If so, what is p_evt->params.discovered_db.srv_uuid.uuid?

If this event does not occur, can you show me how you initialize the central service on your central?

[quote user="mmercier"]Doing more studying with breakpoints, it looks like this "gatt_status" variable remains at 0 through the entire "on_connected"[/quote]

What do you mean by gatt_status? Can you show some snippets? In what event do you expect this to change? Are you talking about the

p_ble_gattc_evt->gatt_status? If so, 0 means BLE_GATT_STATUS_SUCCESS, so this being 0 is not unexpected.

Are you talking about the on_primary_srv_discovery_rsp()? If so, does it print anything from this callback?

RE: Service Discovery Failed using pc-ble-driver

mmercier — Mon, 04 May 2020 19:47:14 GMT

I believe I've found the error, I needed to search for 0x0100 instead of 0x100.

It looks like this error message is called BLE_GATT_STATUS_ATTERR_ATTRIBUTE_NOT_FOUND. So there is some attribute not being found when the service is being discovered. Unfortunately, since this is not in response to any function call, I have no idea what is setting this variable. It is the "gatt_status" parameter of the ble_evt object's evt.gattc_evt parameter, which is passed to the "on_service_discovery_response" function by the event handler.

Doing more studying with breakpoints, it looks like this "gatt_status" variable remains at 0 through the entire "on_connected" routine, even after finishing and ending the pass through the event handler's loop. But then, when the event handler enters its next pass (going to the case for BLE_GATTC_EVT_PRIM_SRVC_DISC_RESP), this value is now set to 0x10A.

So whatever is changing the evt_id, I'm assuming, is responsible for changing the "gatt_status" parameter, and it's being set to this error code.

Could you please help me figure out what attribute is not being found? Thanks.

RE: Service Discovery Failed using pc-ble-driver

mmercier — Mon, 04 May 2020 19:33:13 GMT

I did some more experimenting with different functions. I found a function called "sd_ble_uuid_vs_add", which is supposed to add a vendor specific UUID to the program. I defined a struct of type ble_uuid128_t, and assigned its 16-length array to be my device's full 128-bit UUID (in little endian format, ie, srvc_uuid128[0] = 0x32, srvc_uuid128[1] = 0x0D, etc).

I assigned this function to return an error code and print a fail message if it isn't equal to NRF_SUCCESS, and I made it past this function with no errors. I am also now making it past the "sd_ble_gattc_primary_services_discover" function without error (using 0x0100 as my 16-bit UUID, based on the service).

However, I am now receiving an error message at the "on_service_discovery_response" function. The very first thing checked is the "gatt_status" parameter of the "p_ble_gattc_evt" object. This is failing with an error code of 0x10A. I tried searching the header files for an 0x10A, with no results, and for an 0x100. The only result I found was an error code that corresponds to 0x100 + some constant, which is defined as 0x3000, so this clearly isn't my error message.

So I am now at the point where I began, before trying to make changes to the UUID properties. Could you please help me to determine what this 0x10A error message means, and what to do about this? Thanks.

RE: Service Discovery Failed using pc-ble-driver

mmercier — Mon, 04 May 2020 16:41:49 GMT

Would you be able to let me know the functions I need to call in order to connect to this service using the pc-ble-driver C program? Thanks.

RE: Service Discovery Failed using pc-ble-driver

mmercier — Mon, 04 May 2020 15:10:39 GMT

Here is the product when connected in nRF Connect.

RE: Service Discovery Failed using pc-ble-driver

mmercier — Mon, 04 May 2020 15:03:59 GMT

The product has the service UUID of 17C30001EB0747848BF33212453B0D32. It is not a heart rate monitor. I am using the heart rate collector example because it is the only example that exists in the pc-ble-driver package.

According to the description of the struct definition, this struct "encapsulates both 16-bit and 128-bit UUIDs". For 128-bit UUIDs, I need to define the 'uuid' parameter of the struct as "octets 12-13 of 128-bit UUID", according to the description.

It is worth noting that there is another struct type defined in this header file called "ble_uuid128_t", which only has a single parameter made up of an array of 8-bit values. However, the "sd_ble_gattc_primary_services_discover" is expecting to be passed a parameter of type "ble_uuid_t", not "ble_uuid128_t". And this function is defined in the pc-ble-driver libraries, so it's not as if I can simply modify it to take the other struct instead.

Considering that the "ble_uuid_t" struct has a parameter for type, and this can be set to "BLE_UUID_TYPE_VENDOR_BEGIN", this seems to suggest to me that this struct should be usable for defining 128-bit UUID services. I am wondering, then, if there needs to be some other function call that sets the rest of the 128-bit UUID. If there is, though, I can't find it. The program calls "sd_ble_gattc_primary_services_discover" as its first function call on connection.

Could you please let me know if there is either a function I need to use to set the rest of the UUID, or if there is a function I can use to pass a "ble_uuid128_t" struct instead of a "ble_uuid_t"? Thanks.

RE: Service Discovery Failed using pc-ble-driver

Edvin — Mon, 04 May 2020 14:52:55 GMT

Let's keep this in one ticket. If I understand correctly, we are currently discussing the same issue in both the tickets that you have with me. I'll close the other one, and we can continue here.

What does the service of your peripheral look like in nRF Connect -> Bluetooth? Can you show me a screenshot? Didn't you say that it was a custom UUID?`Please note that you can't just change UUIDs from the standard Bluetooth UUIDs, such as the heart rate monitor UUID, and keep it as a short UUID. If you customize it, you must use a 128-bit UUID.

However, if you have a standard Heart rate UUID, look at how the UUID is implemented in the ble_app_hrs example and how it appears in the nRF Connect -> Bluetooth Low Energy.

So, what does your peripheral look like in nRF Connect?

RE: Service Discovery Failed using pc-ble-driver

mmercier — Mon, 04 May 2020 14:41:09 GMT

For further info, here is the definition of the struct being used, defined in ble_types.h:

/** @brief Bluetooth Low Energy UUID type, encapsulates both 16-bit and 128-bit UUIDs. */
typedef struct
{
uint16_t uuid; /**< 16-bit UUID value or octets 12-13 of 128-bit UUID. */
uint8_t type; /**< UUID type, see @ref BLE_UUID_TYPES. If type is @ref BLE_UUID_TYPE_UNKNOWN, the value of uuid is undefined. */
} ble_uuid_t;

The "service_discovery_start" routine is creating a struct of this type and passing it to the function "sd_ble_gattc_primary_services_discover", which is defined in the pc-ble-driver libraries. I currently have the 'type' parameter of this struct set to BLE_UUID_TYPE_VENDOR_BEGIN, and I'm trying to figure out what value to set for the 'uuid' parameter.