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
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
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.
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
Hi Raj,
I see that the RTT log is from the application and not the bootloader. Can you upload the RTT log from the bootloader instead? (In some cases using the RTT viewer can be difficult when RTT logging is enabled in both the bootloader and application, but a simple workaround is to disable RTT logging in the application when you test).
PS: I took the liberty to improve the readability of your code. Please use Insert -> Code in the future when inserting code, as that makes it a lot easier to read it.
Einar
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.
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.
Hi ,
But i am getting the same logs when doing OTA using nrf mobile app. Am i missing something ?
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.
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.
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..
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.
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..
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.
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