Extending Buttonless DFU app to include UART. Fails when trying to advertise.

RE: Extending Buttonless DFU app to include UART. Fails when trying to advertise.

cor10 — Fri, 13 Nov 2020 00:52:48 GMT

Thanks Hung. This makes sense. I am able to debug and verify that the ble_uuid.type is actually 0x03 rather than the VENDOR_BEGIN type, which is 0x02. I now save this uuid type that is returned from sd_ble_uuid_vs_add() and add this second UUID advertising information to the scan response data in the advertising_init() function before calling ble_advertising_init().

`And my custom app now successfully advertises and can perform DFU!!!

RE: Extending Buttonless DFU app to include UART. Fails when trying to advertise.

Hung Bui — Thu, 12 Nov 2020 14:31:26 GMT

Hi Corten,
Please try to add the UUIDs to scan response packet and check if you can get it there.

If you have a look at sd_ble_uuid_vs_add() description you can find that p_uuid_type is the output. You need to save this value after you call and use this value when you add the UUID to the advertising packet.

RE: Extending Buttonless DFU app to include UART. Fails when trying to advertise.

cor10 — Thu, 12 Nov 2020 11:27:40 GMT

I forgot to mention it but I already made my code call services_init() before advertising_init(). Doing this resolved a previous error I was getting about invalid parameters, but now I face this new and different error that I described above.

I will try and change that use of BLE_UUID_TYPE_VENDOR_BEGIN. I only used that because it was the value used for the NUS Service in the ble_app_uart example code. And I confirm that the buttonless DFU init code is called before the nus init code in my services_init() func, so the DFU part calls sd_ble_uuid_vs_add() first. If this is what is truly happening, what should I do next to try and get this to work properly? How can I get it to advertise correctly? Is it just changing this VENDOR_BEGIN type?

My device name that is advertised is just four letters "TLDB", and all I am adding is these 2 UUIDs. Should this fit into one advertising packet?

RE: Extending Buttonless DFU app to include UART. Fails when trying to advertise.

Hung Bui — Thu, 12 Nov 2020 11:15:19 GMT

Hi Corten,

Please make sure you call services_init before you call advertising_init. The reason is that you need to add the NUS UUID base to the softdevice before you can use the UUID type of it.
Also using the BLE_UUID_TYPE_VENDOR_BEGIN as the UUID type is not always correct. You should use what uuid_type value returned from sd_ble_uuid_vs_add() call.
If it's the first UUID base you register using sd_ble_uuid_vs_add() it will equal to BLE_UUID_TYPE_VENDOR_BEGIN . But if the second one then it will be BLE_UUID_TYPE_VENDOR_BEGIN + 1 .
In this case when you combine NUS and Buttonless DFU, I suspect that the Buttonless DFU has already registered BLE_NORDIC_VENDOR_BASE_UUID using sd_ble_uuid_vs_add() and you may have an issue with the uuid_type.

Also, please aware that the advertising packet is only 31 bytes payload with a lot of overhead. If you have a long device name, multiple UUIDs, it may not fit into one advertising packet. You may want to use the scan response if you want to include a 128 bit UUID in the advertising packets.