16bits to 12bits UUID conversion problem on PC

[jpo38]

I'm working on a PC application (using nrf51-ble-driver_win_0.4.1 API) to connect a BLE device and discover BLE services.

Today, I'm tying to connect the Nordic dev kit programmed with "Nordic_UART" application (providing few services).

When discovering services, one is detected with type BLE_UUID_TYPE_UNKNOWN and uuid 0, meaning it's a 128bits UUID.

Then, I use sd_ble_gattc_read to read the full 128bits address and get in return {0x9e 0xca 0xdc 0x24 0x0e 0xe5 0xa9 0xe0 0x93 0xf3 0xa3 0xb5 0x01 0x00 0x40 0x6e}. Which appears to be correct. 16bits UUID is then {0x01 0x00} (bytes 12 and 13 of 128bits address).

As all the API works with 16bits UUID, my understanding is that I need to call sd_ble_uuid_vs_add to add a mapping between 16bits UUID {0x01 0x00} and 128bits UUID {0x9e 0xca 0xdc 0x24 0x0e 0xe5 0xa9 0xe0 0x93 0xf3 0xa3 0xb5 0x01 0x00 0x40 0x6e} for any future function call of the API with 16bits UUID to work. Is that true?

Then, I do:

uint8_t p_type;
uint32_t err_code = sd_ble_uuid_vs_add( &uuid128, &p_type ); // uuid128 storing the 128bits array read by sd_ble_gattc_read

This returns NRF_SUCCESS and p_type is set to BLE_UUID_TYPE_VENDOR_BEGIN so it apparently worked.

By the way, I saw examples where uuid128[12] and uuid128[13] are set to 0x00 before calling sd_ble_uuid_vs_add (to "Mask 16-bit UUID part to zeros")....am I supposed to do that?

Now, later in my code, when I display UUID to user, I'd like to convert back the 16bits UUID ({0x01 0x00}) to the long 128bits UUID. My undesrtanding is that it should be doable without using again sd_ble_gattc_read as mapping between both was added to the system when I called sd_ble_uuid_vs_add. Is that true?

So I try that:

    ble_uuid_t      ble_uuid;
    ble_uuid.type = BLE_UUID_TYPE_VENDOR_BEGIN;
    ble_uuid.uuid = 0x0001;

    uint8_t len = 0;
    ble_uuid128_t restored128;
    sd_ble_uuid_encode(&ble_uuid, &len, restored128.uuid128);

This returns me NRF_SUCCESS, which is good. But len remains 0 and restored128.uuid128 is unchanged. Moreover, log_handler is invoked with sd_rpc_log_severity_t of LOG_ERROR and message File: (null), Line: 0, Error code: 12.

Shouldn't I get len == 16 and restored128.uuid128 set to {0x9e 0xca 0xdc 0x24 0x0e 0xe5 0xa9 0xe0 0x93 0xf3 0xa3 0xb5 0x01 0x00 0x40 0x6e}?

Am I misunderstanding something?

Note: This question could be a duplicate as this one posted by me but as I could not get any answer, I'm giving a new try explainging the problem differently... ;-)

[Hung Bui]

@jpo38: I tried with the BLE drive, and reproduced your issue. I am talking with the developer to find the root cause. It could be an issue with the serialization library we have.

I will let you know when we figure out.

[jpo38]

Great, good to know you could duplicate this. Waiting for a fix, I simply saved the mapping between types and corresponding 128bits mask on my side and do the resolution myself instead of calling sd_ble_uuid_encode...so I'm not stuck with that anymore. But it would be nice to have it be fixed for good on your side.

[Hung Bui]

@jpo38: I got the confirmation from the R&D team that it was a bug in the serialization library in the BLE driver. We did a wrong assertion and throw error code 12 because of that bug.

This explained why I couldn't reproduce it when I tried directly on the nRF51 chip.

This only affects sd_ble_uuid_encode. So sd_ble_uuid_vs_add() works just fine.

I have reported the bug in the system, and it will be fixed in the next release of the SDK and the BLE driver.

I'm glad that you already found the workaround. Thanks for reporting the issue.

[jpo38]

Great! Thanks for the quick investigation!

[Hung Bui]

btw, an easy workaround that can avoid the assertion is to set the value of "len" to something >16 for example 17. Then it should be fine to call sd_ble_uuid_encode().