NUS central and DFU using Serialization

RE: NUS central and DFU using Serialization

Vidar Berg — Mon, 17 Sep 2018 06:44:43 GMT

Good to hear. I used the release/v.2.3.2 branch. pc-ble-driver v2.x releases are for SD API v2 & v3, v3.x releases are for SD_API v2 & v5. nrfutil uses API v3 so it might simplify dfu integration if you use the same API version.

RE: NUS central and DFU using Serialization

TS Gowtham — Sat, 15 Sep 2018 14:34:59 GMT

Thank you, your code helped me fix my problem. I had initially assumed that calling the characteristic discovery function once would be enough. I also noticed that your code and pc_ble_driver_py both use the API version 3. Which branch of the pc_ble_driver should I use to get the API version 3?? Even the branch v3 contains sd_ap_v2 and sd_api_v5 in the hex folder. My end aim is to get NUS central and DFU working, so which API version should I use and which branch should I get it from?

FYI, I am currently using sd_api_v5 from the master branch of pc_ble_driver

RE: NUS central and DFU using Serialization

Vidar Berg — Thu, 13 Sep 2018 20:51:19 GMT

I think that must be a mistake in the documentation, will ask the author to confirm.

I tried the pc-ble-driver v.2.3.2 with API version 3 and managed to hack together an example works with the standard ble_app_uart example. I.e., complete service discovery and receive notifications. Can you try to see if it works for you?

Modified hrs_collector example:

devzone.nordicsemi.com/.../main.c

RE: NUS central and DFU using Serialization

TS Gowtham — Thu, 13 Sep 2018 14:09:43 GMT

I did look at the link you suggested. The table says that the CCCD UUID is 0x2800 while the "Attributes types(UUIDs)" paragraph says that the CCCD UUID is 0x2902. Is that a mistake in the document?

I did use the existing discovery functions. The only change I made is that I kept calling the characteristic discovery function (after adding 1 to the start handle) the till I received the GATT status BLE_GATT_STATUS_ATTERR_ATTRIBUTE_NOT_FOUND.

Also, I connected to the peripheral using the nRFConnect app. In the app, it showed the CCCD UUID as 0x2902. But the descriptor discovery using serialization shows that one descriptor is found with UUID as 0x2803, but I haven't added any descriptors to the peripheral other than CCCD. FYI, the peripheral is running a modified version of ble_app_uart example but without any changes to the characteristics or descriptors from the original example.

RE: NUS central and DFU using Serialization

Vidar Berg — Thu, 13 Sep 2018 13:56:47 GMT

Hi,

0x2803 is the characteristic declaration so seems that the value handle for the NUS TX Characteristic handle should be 0xE + 1. Recommend to have a look at this blog post for a better explanation of the attribute table layout: https://devzone.nordicsemi.com/tutorials/b/bluetooth-low-energy/posts/ble-characteristics-a-beginners-tutorial.

I have not verified it, but it looks like you can use the existing discovery functions used in heart rate collector example and just change the UUIDs to filter on, or is that what you have done already?

RE: NUS central and DFU using Serialization

TS Gowtham — Wed, 12 Sep 2018 14:41:38 GMT

Hi,

Your last answer helped me quite a lot, thanks for that.

I was able to reach till the characteristic descriptor discovery part, but I'm facing the following issues:

1) I followed this link's suggestion and incremented the handle by 1 and called the characteristic discover function. But I noticed that the characteristic handles are being allotted in increments of 2.

NUS RX Characteristic handle = 0x000C

NUS TX Characteristic handle = 0x000E

But the above link says to increment by 1 and the graph in the link just states a variable N. So is this value programmer dependent?

2) When calling the descriptor discovery function, I'm getting the following CCCD details:

Handle = 0x000E

UUID = 0x2803

Is the handle supposed to be same as that of the TX characteristic's handle? Also, from what I understood the CCCD UUID should always be 0x2902. If yes, then any specific reason why I am getting a wrong UUID?

RE: NUS central and DFU using Serialization

Vidar Berg — Tue, 11 Sep 2018 07:16:50 GMT

Yes you are right, notifications/indications will be reported through the on_hvx() function, and writes to the peripheral can be done by calling sd_ble_gattc_write() like you said. hrm_cccd_set() does this, but you may want to use write command instead of write request if you are writing to the NUS characteristic because it's faster.

RE: NUS central and DFU using Serialization

TS Gowtham — Mon, 10 Sep 2018 13:17:48 GMT

Thank you,

I got an approximate idea from the on_notification() function. If I am right, I guess it's function is similar to that of the function on_hvx()? This would solve the portion where the device receives data from the peripheral. But what about transmitting data from the nrf running the connectivity fw to the peripheral? Would just using sd_ble_gattc_write() directly work?

RE: NUS central and DFU using Serialization

Vidar Berg — Mon, 10 Sep 2018 13:11:24 GMT

Hi,

Correct, you should use sd_ble_uuid_vs_add() if you're not using the python/js wrapper. UUID type needs to be set to VENDOR_BEGIN.

RE: NUS central and DFU using Serialization

TS Gowtham — Mon, 10 Sep 2018 09:59:57 GMT

Hi, the link you provided was quite helpful. But now I am currently trying to use the pc ble driver in C++ by modifying the given HRS collector example. Is there a similar code snippet which shows how to add the UUID? I guess I should use the sd_ble_uuid_vs_add function but I am not sure about if the UUID type which should be passed to the function be of type UNKOWN or VENDOR_BEGIN

RE: NUS central and DFU using Serialization

Vidar Berg — Mon, 10 Sep 2018 09:19:00 GMT

Hi,

No worries. I don't think you'll need to modify the connectivity FW as you will be receiving the NUS notifications through the on_notification() callback in your PC app. You could also use the nrfutil dfu ble transport implementation as reference in addition to the hrs collector example (https://github.com/NordicSemiconductor/pc-nrfutil/blob/master/nordicsemi/dfu/dfu_transport_ble.py). It shows how you can add 128 vendor specific UUIDs.

RE: NUS central and DFU using Serialization

TS Gowtham — Sun, 09 Sep 2018 09:14:26 GMT

For 1, I have switched from using the python wrapper to the C library. So how do I add the 128 bit address in C? Also, by adding the address am I correct in assuming that you are referring to adding the vendor ID to the BLE stack table done by calling the 'sd_ble_uuid_vs_add'?

RE: NUS central and DFU using Serialization

TS Gowtham — Sat, 08 Sep 2018 11:50:37 GMT

Hi again and sorry for the delay in replying,

As you suggested I am using the Heart Rate Collector example as the base of my project. But since I am trying to implement NUS, I will need to use UART to transmit the data from the NUS service to my PC. How should I go about this and what kind of effects and changes will this have on the connectivity firmware?

RE: NUS central and DFU using Serialization

Vidar Berg — Wed, 22 Aug 2018 12:50:03 GMT

Hi,

OTA DFU should work with other USB CDC devices. SWD should only be necessary if you use the optional --flash_connectivity argument (programs connectivity FW over SWD). I recommend that you test DFU with your serial bridge to make sure it works as we only use the jlink bridge for our internal verification.

RE: NUS central and DFU using Serialization

TS Gowtham — Tue, 21 Aug 2018 13:53:56 GMT

Hi,

I was looking at the implementation of ble dfu as you suggested. In the function ble(),one of the lines(line 813) mentions the device has to be connected using JLink CDC. I am not aware of how this works. My device will be connected using a serial to usb bridge. Will this work or do I only need to compulsorily use SWD ?

RE: NUS central and DFU using Serialization

Vidar Berg — Thu, 09 Aug 2018 11:14:24 GMT

Hi,

1. Unfortunately, but the HRM example should be a good starting point for creating a NUS central. Just remember to add the 128-bit base UUID. Should look something like this if you're using the python wrapper:

BASE_UUID = BLEUUIDBase([0xXX, 0xXX, ..,])

NUS_RX_CHR = BLEUUID(0xXXXX, BASE_UUID)

NUS_TX_CHR = BLEUUID(0xXXXX, BASE_UUID)

2. Yes, nrfutil uses the connectivity firmware as an intermediary to perform DFU. Source code is available here: https://github.com/NordicSemiconductor/pc-nrfutil/blob/master/nordicsemi/dfu/dfu_transport_ble.py