I'm using nrf51-ble-driver_win_0.4.1 to connect BLE devices on PC. When device has a 128bits UUID, you have to call sd_ble_uuid_vs_add( &uuid128, &p_type )
to register the 128bits UUID and get a VENDOR type (p_type).
But, if your device has two 128bits services, for instance: "0xAABB5500-CCCC-DDDD-EEEE-FFFFFFFFFFFF" and "0xAABB5501-CCCC-DDDD-EEEE-FFFFFFFFFFFF"
-
When discovering first service (0xAABB5500-CCCC-DDDD-EEEE-FFFFFFFFFFFF) first call to
sd_ble_uuid_vs_add( &uuid128, &p_type )
(with 0xAABB0000-CCCC-DDDD-EEEE-FFFFFFFFFFFF as parameter, where 0 replaces short service UUID) returnsNRF_SUCCESS
andp_type
is set. -
Now when discovering secondservice (0xAABB5501-CCCC-DDDD-EEEE-FFFFFFFFFFFF) second call to
sd_ble_uuid_vs_add( &uuid128, &p_type )
(with again 0xAABB0000-CCCC-DDDD-EEEE-FFFFFFFFFFFF as parameter, where 0 replaces short service UUID) does not returnNRF_SUCCESS
(it returnsNRF_ERROR_FORBIDDEN
) and does not setp_type
.
Then, API client has to store a local list of UUIDs for which sd_ble_uuid_vs_add
was already called and map them to vendor types to workaround the bug...