Warnings on Compilation - excess elements in struct initializer

[Ananye]

Hello,

I am working on the ble_app_template example, nrf52840, SDK 17.0.2 and Segger Embedded Studio version 5.34. I have added multiple custom services to my code, however when I build and compile my program I get some warnings which I am not sure how to resolve.

Below is a screenshot of what those warnings are. I have also attached my code to where these warnings come from.

#define BLE_UUID_OUR_SERVICE_UUID                0x5763 
#define BLE_UUID_OUR_SERVICE_2_UUID              0x8964 
#define BLE_UUID_NUS_SERVICE 0x0001

static ble_uuid_t m_adv_uuids[]          =                                          /**< Universally unique service identifier. */
{
    {BLE_UUID_NUS_SERVICE, NUS_SERVICE_UUID_TYPE, BLE_UUID_OUR_SERVICE_2_UUID, BLE_UUID_TYPE_VENDOR_BEGIN,BLE_UUID_OUR_SERVICE_UUID,BLE_UUID_TYPE_VENDOR_BEGIN}
};

Thanks

Ananye

[Vidar Berg]

Hello,

Each "uuid-type" pair must be enclosed with curly brackets as shown in the snippet below. Another problem is that you probably will not be able to fit all 3 128-bit service UUIDs in your advertising payload (payload per packet is 31 bytes if you use legacy advertising). Are you sure you need to include all 3 in your advertisment?

#define BLE_UUID_OUR_SERVICE_UUID                0x5763 
#define BLE_UUID_OUR_SERVICE_2_UUID              0x8964 
#define BLE_UUID_NUS_SERVICE 0x0001

static ble_uuid_t m_adv_uuids[]          =                                          /**< Universally unique service identifier. */
{
    {BLE_UUID_NUS_SERVICE, NUS_SERVICE_UUID_TYPE}, 
    {BLE_UUID_OUR_SERVICE_2_UUID, BLE_UUID_TYPE_VENDOR_BEGIN},
    {BLE_UUID_OUR_SERVICE_UUID,BLE_UUID_TYPE_VENDOR_BEGIN}
};

Best regards,

Vidar

[Ananye]

Hi Vidar,

Thank you for your response. Adding the brackets helped resolve the warnings.

Also, thanks for pointing out about the memory aspect. Yeah for the application we are working, we would need these 3 different services. I did add one of the services to the scan response packet but even then I would not be able to have all 3 at once. Is there any other way?

Also, I have defined a 128 bit base UUID and then created 16 bit custom UUIDs under that base UUID. So does that mean all 3 still use 128 bits in memory? My understanding was that after having one base UUID, any new UUIDs we create under that only use 16 bits in memory, not 128 bits.

Thanks

Ananye

[Vidar Berg]

Hi Ananye,

Ananye said:

Also, thanks for pointing out about the memory aspect. Yeah for the application we are working, we would need these 3 different services.

 Just to be clear, this limit does not apply to how many services/characteristics you may include in your app. There is nothing in the specification mandating that all services must be included in the advertisement.

Ananye said:

Is there any other way?

 Yes, you could enable advertisement extensions, a feature introduced in Bluetooth 5. This allows a payload of up to 255 bytes. A potential problem with this is that you would need to always have a BT 5 compatible observer that supports adv. extensions to receive it.

Ananye said:

Also, I have defined a 128 bit base UUID and then created 16 bit custom UUIDs under that base UUID. So does that mean all 3 still use 128 bits in memory? My understanding was that after having one base UUID, any new UUIDs we create under that only use 16 bits in memory, not 128 bits.

 The base UUID is stored once through the sd_ble_uuid_vs_add(), and is later referenced through the uuid -> type value returned by sd_ble_uuid_vs_add(). But this is related to the internal memory handling. The adv. packet must contain the whole 128-bit byte string for each custom service that is included.

Best regards,

Vidar