Two calls to sd_ble_uuid_vs_add with same parameter fails

[jpo38]

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) returns NRF_SUCCESS and p_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 return NRF_SUCCESS (it returns NRF_ERROR_FORBIDDEN) and does not set p_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...

[Ulrich Myhre]

Hi,

This is all according to the documentation. The return values for sd_ble_uuid_vs_add are described like this:

NRF_SUCCESS	Successfully added the Vendor Specific UUID.
NRF_ERROR_INVALID_ADDR	If p_vs_uuid or p_uuid_type is NULL or invalid.
NRF_ERROR_NO_MEM	If there are no more free slots for VS UUIDs.
NRF_ERROR_FORBIDDEN	If p_vs_uuid has already been added to the VS UUID table.

In a later version of the SoftDevices, this has been changed to simply return NRF_SUCCESS and the already-assigned type.

Please also do a search for "sd_ble_uuid_vs_add" here and you will find many similar questions with helpful answers.

[jpo38]

Thanks, if that's already adressed in next versions, it's great.