UUID comparison in different endinaess

[Embedded_Engineer]

Using SDK16, SD140 v7.0.1

While filtering UUID and taking ble_app_hrs_c from ble_central as reference, raw_uuid correctly appears when sd_ble_uuid_encode(p_target_uuid, &raw_uuid_len, raw_uuid) is called. The received parsed UUID is also same but it is in order of reception i.e. MSB first.

say UUID: 70786e86-fa13-4a65-ab89-d7b199fd0bc2

raw_uuid      = {[0] = 0xc2, [1] = 0x0b, [2] = 0xfd,..., [14] = 0x78, [15] = 0x70}

p_parsed_uuid = {[0] = 0x70, [1] = 0x78, [2] = 0x6e,..., [14] = 0x0b, [15] = 0xc2}

In the function ble_advdata_uuid_find when the comparison happens at memcmp(&p_parsed_uuid[list_offset], raw_uuid, raw_uuid_len) for comparing UUID, naturally it would fail.

What am I apparently missing.

[Simon]

I was not able to recreate your issue.

Could you try to program respectively ble_app_uart peripheral and ble_app_uart central and see if you are able to connect them? In your peripheral device, how did you add the base UUID? Be aware that they are stored with the LSBits first in memory. E.g. if you are working with the UUID 70786e86-fa13-4a65-ab89-d7b199fd0bc2 (this shows up in nRF Connect app for mobile), you should store the base UUID in the advertising peripheral device as followed: 

ble_uuid128_t nus_base_uuid = {{0xC2, 0x0B, 0xFD ..... 0x78, 0x70}} /**< Used vendor specific UUID. */
.
.
err_code = sd_ble_uuid_vs_add(&nus_base_uuid, &p_nus->uuid_type);

Best regards,

Simon

[Embedded_Engineer]

@Simon Any update on this. Please check with ble_app_hrs_c.

[Simon]

Could you upload your application code? Both the modified ble_app_hrs_c and the peripheral example.

Best regards,

Simon