advertising custom service - ble_advertising_init err_code 0x7

[Fávero]

Hello!

I'm trying to advertise my custom service. After setting everything up, when calling ble_advertising_init I receive error 0x7.

static m_adv_uuids[] = {0x1523, 0x2}; //my custom uuid and vendor spefic type
    void advertising_init(){
        uint32_t      err_code;
        static ble_advdata_t advdata;
    	
        // Build advertising data struct to pass into @ref ble_advertising_init.
        memset(&advdata, 0, sizeof(advdata));
    
        advdata.name_type               = BLE_ADVDATA_FULL_NAME;
        advdata.include_appearance      = true;
        advdata.flags                   = BLE_GAP_ADV_FLAGS_LE_ONLY_LIMITED_DISC_MODE;
        advdata.uuids_complete.uuid_cnt = sizeof(m_adv_uuids) / sizeof(m_adv_uuids[0]);
        advdata.uuids_complete.p_uuids  = m_adv_uuids;

        ble_adv_modes_config_t options = {0};
        options.ble_adv_whitelist_enabled = true;
        options.ble_adv_fast_enabled  = BLE_ADV_FAST_ENABLED;
        options.ble_adv_fast_interval = APP_ADV_INTERVAL;
        options.ble_adv_fast_timeout  = APP_ADV_TIMEOUT_IN_SECONDS;
    
        err_code = ble_advertising_init(&advdata, NULL, &options, on_adv_evt, NULL);
        #ifdef RTT_DBG
    	SEGGER_RTT_printf(0,"advertising_init err_code: %d \r\n", err_code);
        #endif
        APP_ERROR_CHECK(err_code);
}

[Eric Stutzenberger]

Hi,

The type value for your custom UUID needs to be filled in based on what the SoftDevice provides as part of calling sd_ble_uuid_vs_add(). This function fills in a "type" which is a handle reference to where that UUID is stored in SoftDevice RAM. Arbitrarily picking a value of 0x2 will not necessarily refer to the correct UUID.

HTH,

Eric

[Fávero]

Hi!

I collected type by using sd_ble_uuid_vs_add() but it also returns type 2.

To walkaround this issue, I followed NUS example, as it is a custom service. In that example, advertising init is set differently, as uuids_complete.uuid_cnt and uuids_complete.p_uuids are set in the scan response and not in advdata.

Fávero

[Anders Strand]

What is your base UUID? Are adding it using sd_ble_uuid_vs_add before calling advertising_init? Can you also check what number sizeof(m_adv_uuids) / sizeof(m_adv_uuids[0]); returns?

[Eric Stutzenberger]

It may be the case that you also need to put your UUID in the scan response data. The advertising data packet is 32 bytes and there are some marker bytes for the various fields giving you less than that for your own data. Since you are advertising the FULL_NAME and appearance, it may be the your advertising data is too large and you need to move some of it to the scan response. Alternatively, you could set include_appearance to false and advertise a SHORT_NAME which should allow you to fit at least one 128-bit UUID in the advertising packet.

Note: sd_ble_uuid_vs_add() returned 2 in this case but if you added another service, it would likely return 3. If you passed in 2 for that UUID when advertising, you wouldn't get the correct UUID. You would get the other UUID instead. Something to keep in mind for future BLE projects =D

[Anders Strand]

If the advertisement packet was too large, he would get NRF_ERROR_DATA_SIZE (0xC), not NRF_ERROR_INVALID_PARAM (0x7). It is weird that moving the uuid to the scan response solved this, but i guess that doesen't matter as long as it works now.