Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Start Secure DFU button in application

Hi,

We are testing Buttonless Secure DFU without bonds using the windows nRF Connect app. If I open the "Secure DFU" service in our app, enable notification for "Buttonless Secure DFU without bonds", and write 01 to it, the device directly reboots to DFU mode. I can then find the device in DFU mode and connect to it (name DfuTarg). I can then click the "Start Secure DFU" button and update the firmware. Everything is fine.

But our app also displays the "Start Secure DFU" button. If I click this then everything freeze for 100 seconds before the reboot and download starts. In this case everything works automatic. But why is there a 100s delay ? Is this more automatic mode supposed to be supported by nRF-Connect or is the button displayed because I have my advertising set up wrong ?

We use nRF Connect v3.3.0 and SDK 15.3.0 and nRF52832.

Thanks

  • Hi,

    enable notification for "Buttonless Secure DFU without bonds", and write 01 to it, the device directly reboots to DFU mode.

     The DFU start button does the same as you describe. It starts by enabling indications on the buttonless characteristic, then it writes 0x1 to make the app enter Bootloader DFU mode. This should not be any slower than doing it manually. I tried to replicate this as well with the template app, but there was no noticeable delay.  

    Do you have logging/LED indications to indicate what state the board is in during the 100s delay? E.g., if the app or bootloader is running, and if it's an active connection or advertising during this time. 

  • After connecting to the application the log has reached <<<1>>> below. Clicking the DFU button in nRF Connect's application window has no immediate effect except nRF Connect says status initializing... Our application is still running and is not aware of the action, I have a breakpoint at ble_dfu_buttonless_on_ctrl_pt_write() and it has not been reached. After 100 sec the breakpoint is reached or if it is inactivated the DFU download proceeds in the expected way with the rest of the log below.

    Something is wrong in either our application or the nRF Connect app (probably the former).

    Our app uses free rtos and is based on ble_app_hrs_freertos from SDK 15.3.0. Where can I set a breakpoint to see the start of the chain of events, I thought the above breakpoint was pretty early in the chain ?

    Thanks
    Sven


    00> J-Link V6.54c - Real time terminal output
    00> J-Link OB-SAM3U128-V2-NordicSemi compiled Jan 7 2019 14:07:15 V1.0, SN=682444101
    00> Process: IarIdePm.exe
    00> <debug> app: *** App main_Init() ***
    00>
    00> <debug> app: Enter BLE_GeneralInit
    00>
    00> <debug> nrf_sdh_freertos: Creating a SoftDevice task.
    00>
    00> <debug> app: Return from BLE_GeneralInit
    00>
    00> <debug> nrf_sdh_freertos: Enter softdevice_task.
    00>
    00> <info> app: Fast advertising.
    00>
    00> <debug> nrf_ble_gatt: Requesting to update ATT MTU to 247 bytes on connection 0x0.
    00>
    00> <info> app: Connected
    00>
    00> <debug> nrf_ble_gatt: ATT MTU updated to 247 bytes on connection 0x0 (response).
    00>
    00> <info> app: Data len is set to 0xF4(244)
    00>
    00> <debug> app: ATT MTU exchange completed. central 0xF7 peripheral 0xF7
    00>
    <<<1>>>
    00> <debug> nrf_ble_gatt: Peer on connection 0x0 requested a data length of 251 bytes.
    00>
    00> <debug> nrf_ble_gatt: Updating data length to 27 on connection 0x0.
    00>
    00> <debug> nrf_ble_gatt: Data length updated to 27 on connection 0x0.
    00>
    00> <debug> nrf_ble_gatt: max_rx_octets: 27
    00>
    00> <debug> nrf_ble_gatt: max_tx_octets: 27
    00>
    00> <debug> nrf_ble_gatt: max_rx_time: 2120
    00>
    00> <debug> nrf_ble_gatt: max_tx_time: 2120
    00>
    00> <debug> app: ATT MTU exchange completed. central 0xF7 peripheral 0xF7
    00>
    00> <info> app: Received indication state 1
    00>
    00> <info> app: Device is preparing to enter bootloader mode.
    00>
    00> <debug> app: Disconnected connection handle 0
    00>
    00> <info> app: Disconnected 1 links.
    00>
    00> <debug> app: In ble_dfu_buttonless_bootloader_start_finalize
    00>
    00>
    00>
    00> <info> app: Device will enter bootloader mode.
    00>
    00> <debug> app: *** App main_Init() ***
    00>
    00> <debug> app: Enter BLE_GeneralInit
    00>
    00> <debug> nrf_sdh_freertos: Creating a SoftDevice task.
    00>
    00> <debug> app: Return from BLE_GeneralInit
    00>
    00> <debug> nrf_sdh_freertos: Enter softdevice_task.
    00>
    00> <info> app: Fast advertising.
    00>

  • I managed to capture a wireshark trace of the event which I believe holds the answer, though I don't understand it. At log no 1986 (27 seconds) I push the DFU button. The nRF Connect app queries my app on a number of faulty handles which takes exactly 100 seconds. At log no 2532 nRF Connect writes the DFU attribute and things proceed (though that's not in the log as I didn't capture the bootloader traffic). My app must be declaring something wrong at connection.

    dfu_hang_2.pcapng

  • Thanks for providing the sniffer trace! It looks nRF connect is starting to retrieve information about every attribute handle as soon as you click "DFU start". It would have been interesting to know if it did the same when you do it manually.

    In any case, the DFU start command appears to get delayed until the service discovery is completed, which takes quite a while considering the large attribute table and long connection interval (400 ms). As a test, please try to use a shorter connection interval and see how it impacts the delay. To do that you can either change the preferred connection interval range in your FW app, or you can make nRF connection ignore the connection parameter update requests from your device. 

  • No, when I do it manually it does much less service discovery, at log 6508 in the new log. In the hang-log at 2003, 2077, 2309, 2397 there are errors, why ?

    dfu_manual_no_hang.pcapng

Related