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

sd_ble_gattc_primary_services_discover

Related to devzone.nordicsemi.com/.../, how should the last parameter to sd_ble_gattc_primary_services_discover() be cooked for 128-bit service UUIDs?

printf("Discovering primary services\n"); fflush(stdout);
start_handle = 0x0001;

/* vendor specific base UUID */
ble_uuid128_t     base_uuid = { BLE_UUID_MY_SERVICE_BASE_UUID };
/* add service based on vendor specific UUID */
ble_uuid_t srvc_uuid;
srvc_uuid.type = BLE_UUID_TYPE_VENDOR_BEGIN;
srvc_uuid.uuid = BLE_UUID_MY_SERVICE;
err_code = sd_ble_uuid_vs_add(&base_uuid, &srvc_uuid.type);

err_code = sd_ble_gattc_primary_services_discover(m_connection_handle, start_handle, &srvc_uuid);

Is the above correct? I think the srvc_uuid.type = BLE_UUID_TYPE_VENDOR_BEGIN; line is superfluous, it is not used, right?

By pure luck I found this patch lurking in the pc-ble-driver-py folder /usr/local/lib/python2.7/dist-packages/pc_ble_driver_py/hex/SD20_SDK11.patch, which seems related:

diff --git a/components/serialization/application/codecs/s130/middleware/app_mw_ble_gatts.c b/components/serialization/application/codecs/s130/middleware/app_mw_ble_gatts.c
--- a/components/serialization/application/codecs/s130/middleware/app_mw_ble_gatts.c
+++ b/components/serialization/application/codecs/s130/middleware/app_mw_ble_gatts.c
@@ -586,7 +586,8 @@ static uint32_t gatts_attr_get_rsp_dec(const uint8_t * p_buffer, uint16_t length
     const uint32_t err_code = ble_gatts_attr_get_rsp_dec(
         p_buffer,
         length,
-        (ble_gatts_attr_md_t **)&mp_out_params[0],
+        (ble_uuid_t **)&mp_out_params[0],
+        (ble_gatts_attr_md_t **)&mp_out_params[1],
         &result_code);

I haven't seen notice of this patch. Is it a bug fix, or related to a change in the SD 2.0.1 specification??

Related