Unable to find the DFU service while using ble_app_buttonless_dfu example provided in SDK17.

[rajAsthana]

Hi,

I am unable to find the DFU services in example ble_app_buttonless_dfu provided in SDK 17.

Please suggest how to proceed.

Thanks 

Raj

[Einar Thorsrud]

Hi Raj,

The DFU service is included in the ble_app_buttonless_dfu example (you will see many reference to it if you search for "dfu" in main.c), and you will see the device advertising with the DFU UUID if running the example on a DK. Note that it requires bootloader etc, so it requires a bit to et up unless you flash a merged hex file that included everything. Just to see how this shoud work you could flash for instance <SDK>\examples\dfu\secure_dfu_test_images\ble\nrf52832\sd_s132_bootloader_buttonless_with_setting_page_dfu_secure_ble_debug_without_bonds.hex if working with the nRF52 DK.

If this does not address the issue, then please elaborate/clarify so that I can answer more specifically.

[rajAsthana]

Hi Einar,

Now I am able to put my board(nrf52840) in DFU mode with buttonless code using Esp32 as controller.

The problem currently i am facing is to send a init packet to my nrf board at data point.

when ever i am trying to send an init packet, I didn't get any reply at my ESP32 board  and after some time my nrf board comes in application mode from DFU mode.

For reference i am attaching logs of my ESP32 board

20:44:24.078 -> Starting Arduino BLE Client application...
20:44:24.755 -> BLE Advertised Device found: Name: UART_DFU_Test, Address: c3:3e:a6:fb:ed:f4, serviceUUID: 0000fe59-0000-1000-8000-00805f9b34fb
20:44:24.755 -> Found our device! address: Forming a connection to c3:3e:a6:fb:ed:f4
20:44:24.789 -> - Created client
20:44:24.822 -> - Connected to server
20:44:25.469 -> - Found our Data service
20:44:25.469 -> - Found our characteristic....
20:44:25.469 -> - Found our DFU service
20:44:25.469 -> DFU service canIndicate....
20:44:25.537 -> Indicate callback
20:44:25.537 -> 20 01 01(Response from NRF52 to ESP32 corrospondance to 0x01 command )
20:44:32.153 -> 60 06 01 00 02 00 00 00 00 00 00 00 00 00 00 ((Response from NRF52 to ESP32 corrospondance to 60 01 command for select object))
20:44:35.154 -> sending create object command...
20:44:35.188 -> Indicate callback
20:44:35.188 -> 60 01 01 (Response from NRF52 to ESP32 corrospondance to 0x01, 0x01,0x90,0x00,0x0,0x0 command to create object)
20:44:35.188 -> Ready to send init Packet
20:44:35.188 ->

when i am trying to send init packet as show in log above nothing happens.

i stored the content of init packet in a local buffer in my code as shown below 

uint8_t emgPkt3[144] = {0x12,0x8D,0x01,0x0A,0x47,0x08,0x01,0x12,0x43,0x08,0x01,0x10,0x34,0x1A,0x05,0xCA,0x01,0xFE,0x95,0x03,0x20,0x20,0x28,0x20,0x30,0x20,0x38,0xF0,0xA2,0x03,0x42,0x24,0x08,0x03,0x12,0x20,0x65,0x2B,0xCB,0x9A,0xCA,0x79,0xC4,0x5C,0x99,0x81,0x98,0x06,0xF3,0x1E,0x3D,0x27,0xA7,0x08,0x69,0x20,0x20,0x94,0x51,0x7F,0x4B,0xD0,0x14,0x53,0x74,0x55,0x53,0xEF,0x48,0x01,0x52,0x040,0x80,0x01,0x12,0x20,0x10,0x20,0x1A,0x40,0x7B,0x14,0x2F,0xA8,0x3B,0xAA,0xB2,0x4B,0x84,0x5C,0x44,0x59,0xBF,0x05,0x24,0x5A,0xBF,0xDF,0x44,0x24,0x1F,0xC5,0xAE,0x3C,0xF6,0x5C,0x54,0xD0,0x3E,0x84,0xDB,0x04,0xD4,0x8B,0xA6,0x3B,0x64,0xE4,0x30,0x5E,0x8E,0x01,0xEB,0x47,0xDE,0x69,0x79,0x27,0x93,0x09,0xF3,0xE1,0xE2,0xF1,0x1B,0x73,0xE2,0x19,0x6B,0x2F,0xAB,0x1A,0x11,0x0E};

and sending four bytes at a time till all 144 bytes are completed.

can you suggest me where i am wrong?

Thanks 

Raj

[rajAsthana]

Hi Einar,

Please have a look on RTT Bootloader logs  given below, 

<info> app: Inside main
<debug> app: In nrf_bootloader_init
<debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
<debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
<debug> nrf_dfu_settings: Using settings page.
<debug> nrf_dfu_settings: Copying forbidden parts from backup page.
<debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
<info> nrf_dfu_settings: Backing up settings page to address 0xFE000.
<debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
<debug> app: Enter nrf_bootloader_fw_activate
<info> app: No firmware to activate.
<debug> app: App is valid
<info> nrf_dfu_settings: Backing up settings page to address 0xFE000.
<debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
<debug> app: Running nrf_bootloader_app_start with address: 0x00001000
<debug> app: Disabling interrupts. NVIC->ICER[0]: 0x0

The same logs I am getting with NRF mobile app.

[Einar Thorsrud]

Hi Raj,

This shows that the bootloader starts the application, but it does not show anything about the bootloader having entered DFU mode. Does it? Can you share a log of an actual attempt do to DFU update (which is what is not working from what you have written)? The very first thing that has to happen for that is for the bootloader to enter DFU mode instead of starting the application.

[rajAsthana]

Hi ,

But i am getting the same logs when doing OTA using nrf mobile app. Am i missing something ?

[Einar Thorsrud]

Hi,

Does DFU actually work then? If soy, you should see a lot of logging during the DFU procedure. As you can see from the log you uploaded that states that it starts a valid app, and it is clear that no DFU update occurs when you get this log output.

[rajAsthana]

hi ,

I think DFU is happening because name of the Device Changes .

Also i have more logs of ESP32 where after 1st writeValue() of DFU packet system gets stuck.

ESP32 Logs :

18:13:48.599 -> Characteristic: uuid: 8ec90002-f315-4f60-9fb8-838830daea50, handle: 13 0x000d, props: broadcast: 0, read: 0, write_nr: 1, write: 0, notify: 0, indicate: 0, auth: 0Ready to send init Packet
18:13:48.636 -> Init i = 0[D][FreeRTOS.cpp:189] take(): Semaphore taking: name: WriteCharEvt (0x3ffe11e0), owner: <N/A> for writeValue
18:13:48.636 -> [D][FreeRTOS.cpp:198] take(): Semaphore taken: name: WriteCharEvt (0x3ffe11e0), owner: writeValue
18:13:48.668 -> [D][BLEClient.cpp:458] handleGAPEvent(): BLEClient ... handling GAP event!
18:13:49.013 -> [D][BLEDevice.cpp:148] gattClientEventHandler(): gattClientEventHandler [esp_gatt_if: 4] ... Unknown
18:13:49.013 -> [D][BLEClient.cpp:158] gattClientEventHandler(): gattClientEventHandler [esp_gatt_if: 4] ... Unknown

Ty..

[Einar Thorsrud]

Hi,

rajAsthana said:

I think DFU is happening because name of the Device Changes .

I see. Then is is just that the log is from another time, I guess? Can you try again and make sure that the log is from the actual DFU process? Will will see clearly form the log that DFU is ocuring with a lot of printouts of received commands etc.

[rajAsthana]

Hi,

whenever I try to write on DFU packet characteristics, on ESp32 side we observer that code gets stuck at "m_semaphoreWriteCharEvt.wait("writeValue"); " 

ty..

[Einar Thorsrud]

I see. It is not easy for me to comment on your ESP32 code, though. But I am happy to assist on the DFU protocol.

[rajAsthana]

Hi Einar,

While Sending Init packet I am getting this response from Target Controller, Can you please confirm is it valid response or not?

DFU Controller  ----------0x01----------->  DFU Target (AT DFU characteristics)

DFU Controller  <----------0X20 0x01 0x01-----------  DFU Target 

DFU Controller  ----------0x06 0x01----------->  DFU Target (AT Control characteristics)

DFU Controller  <---------60 06 01 00 02 00 00 00 00 00 00 00 00 00 00------------ DFU Target 

DFU Controller  ----------01 01 90 00 00 00---------->  DFU Target (AT Control characteristics)

DFU Controller  <----------60 01 01---------- DFU Target 

DFU Controller  ----------Send init packet no response----------> DFU Target (AT data characteristics)

DFU Controller  ----------0x03---------> DFU Target (AT Control characteristics)

DFU Controller  <----------60 03 01 90 00 00 00 58 0b a5 3b---------- DFU Target 

DFU Controller  ----------0x04---------> DFU Target (AT Control characteristics)

DFU Controller  <----------60 04 05---------- DFU Target 

 

Thanks 

Raj           

[Einar Thorsrud]

Hi Raj,

The response you are getting is 0x05 which is NRF_DFU_RES_CODE_INVALID_OBJECT. From API doc: "Data object does not match the firmware and hardware requirements, the signature is wrong, or parsing the command failed". You can refer to this post for more details.