Start Secure DFU button in application

[sjerlhagen]

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

[Vidar Berg]

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. 

[sjerlhagen]

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

[Vidar Berg]

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.