Using the Connect SDK client functions to access the buttonless dfu service.

Cant get the target into DfuTarg mode.  I’ve written a manual DFU client app using Bluez.  We are changing our client app to run on a 52840.  Peripheral is also a 52840.

I’m able to discover the single buttonless dfu service.  Using NULL instead of DFU_SERVICE discovers only handles 0x0000 to 0x0009.

#define UUID_DFU_SERVICE        BT_UUID_DECLARE_16(0xfe59)

err = bt_gatt_dm_start(conn, UUID_DFU_SERVICE, &dfu_discovery_cb, NULL);

I enable indications in a discovery_complete_cb:

struct bt_gatt_subscribe_params indication_params =

{

    .notify = indicate_callback,

    .value = BT_GATT_CCC_INDICATE,

    .value_handle = 0x0010,

    .ccc_handle = 0x0011,

    .subscribe = subscribe_callback,

    .write = NULL,

    .node = NULL,

    .flags = BT_GATT_SUBSCRIBE_FLAG_VOLATILE,

};

int err = bt_gatt_subscribe(conn, &indication_params);

 

I then write 0x01 to 0x0010 but get the invalid op code response.

 

00:00:10.316,070] <dbg> command_c: gatt_discover: Command DFU

[00:00:10.316,131] <dbg> command_c: connected: >>>>>>>> Connected waiting for services

[00:00:10.417,480] <inf> command_c: MTU exchange done

[00:00:11.467,346] <dbg> dfu_c: discovery_dfu_complete: UUID:<2800>    Handle: 0x000E    permissions: 0x0000

[00:00:11.467,407] <dbg> dfu_c: discovery_dfu_complete: UUID:<2803>     Handle: 0x000F

[00:00:11.467,620] <dbg> dfu_c: discovery_dfu_complete: UUID:<8ec90003-f315-4f60-9fb8-838830daea50>     Handle: 0x0010

[00:00:11.467,681] <dbg> dfu_c: discovery_dfu_complete: UUID:<2902>     Handle: 0x0011

[00:00:11.493,164] <dbg> dfu_c: dfu_connect_buttonless: Services Resolved, Connection complete in 1220 msec

[00:00:11.567,291] <dbg> dfu_c: subscribe_callback: value_handle:0x0010    CCC_Handle:0x0011    Value: 0x0002

[00:00:11.667,236] <dbg> dfu_c: write_response_callback: write_response_callback()   data: 0x01   len: 1   handle: 0x10   offset: 0

[00:00:11.667,724] <dbg> dfu_c: indicate_callback: <0x20>

[00:00:11.667,724] <dbg> dfu_c: indicate_callback: <0x46>

[00:00:11.667,755] <dbg> dfu_c: indicate_callback: <0x02>

[00:00:11.674,499] <dbg> dfu_c: dfu_connect_buttonless: >>>> Buttonless UUID written in 180 msec

 

A Wireshark capture shows that indications are not getting set:

Frame 245: 35 bytes on wire (280 bits), 35 bytes captured (280 bits) on interface COM7-4.2, id 0

nRF Sniffer for Bluetooth LE

Bluetooth Low Energy Link Layer

Bluetooth L2CAP Protocol

Bluetooth Attribute Protocol

    Opcode: Write Request (0x12)

    Handle: 0x0011 (Unknown: Client Characteristic Configuration)

        [Characteristic UUID: 8ec90003f3154f609fb8838830daea50]

        [UUID: Client Characteristic Configuration (0x2902)]

    Characteristic Configuration Client: 0x0000

        0000 0000 0000 00.. = Reserved: 0x0000

        .... .... .... ..0. = Indication: False

        .... .... .... ...0 = Notification: False

Parents Reply Children
  • Hi Sigurd,

    I found it works ok from my phone also.  It acts like maybe a memory issue? Maybe a config problem? I cant find this flag: config BT_RECV_CONTEXT mentioned in the description for bt_gatt_subscribe().

    I also found all the permissions reporting 0x0000 from bt_gatt_dm_attr_next() for all services, including the NUS.  But that works, I'm able to read and write to the NUS handles in the central_gatt_write project.

    And like I mentioned, using NULL in bt_gatt_dm_start() fails to discover anything but the base service.

    What do u suggest next?  Thanks for the help.

    Bob

  • central_gatt_write.7z

    Modified for DFU service 0xFE59 on 52840 client.  I have a target address hard coded.  Fails to put into DfuTarg mode???  Thanks for any ideas. 

  • Hi!

    Thanks for the project, I will test it and see why it fails to put the device in DFU mode.

    I tried building the project using NCS(nRF Connect SDK) v2.5.0, but I got some build errors. I'm guessing this project was originally written for another version. What version of NCS did you use?

  • V2.3.0   Sorry, I should have mentioned that.  I don't object to updating.  I'm developing on a nRF52840 dev kit and will be using the Fanstel BT840F module.  Our system will use a Debian board to interface with it, thus the overlay.  Not needed in the test project.  Thanks again.

  • Hey Sigurd, I found it.  And updated to v2.5.0.  Thanks.

                uint8_t send_data[3] = {0};
                send_data[0]= 0x01;
               
                struct bt_gatt_write_params write_params =
                {
                    //.data = 0x01,
                    .data = send_data,
                    .length = 1,
                    .func = write_callback,
                    .handle = 0x0010,
                    .offset = 0,
                };
                err = bt_gatt_write(conn, &write_params);
Related