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,

The server gives the invalid attribute handle response in packet  #2003 to 2309 because the PC client is issuing a request where the starting handle is set higher than the end handle. That might be a bug in our service discovery implementation in nRF connect. However, this is not what's causing the delay you are experiencing.  And the last "Attribute not found" response is returned in this case because the client has reached the end of the attribute table (no attribute that matches the request). 

Invalid handle response

To improve the timing for the PC app you may try delay the connection parameter update request in your app by a few seconds to allow the client to complete service discovery at the initial fast interval  ( is configurable, see Connection Parameters Negotiation). And you can initialize the DFU service first, so it gets moved to the top of your attribute table. 

I don't expect our nRF connect on Android and iOS to have the same problem. Have you tried DFU with those as well?

[sjerlhagen]

No I have not tried Android or iOS yet. I tried to set connection interval 10 ms which got the service discovery time down to 9 seconds after requesting DFU. I thought complete service discovery was done at connection and saved but I see now that it is only done when needed, after clicking DFU. I can live with a permanent fast interval as our device is not power limited, but I still want to play nice with the phone, both for power and compatibility. Is it good to suggest min 10 and max 100 ms connection interval, or what do you suggest ? If a complete service discovery is needed before writing the DFU attribute, why was it faster with the manual write to the DFU attribute, as opposed to the DFU button ?

Sven

[Vidar Berg]

sjerlhagen said:

If a complete service discovery is needed before writing the DFU attribute, why was it faster with the manual write to the DFU attribute, as opposed to the DFU button ?

 This is something that could have been implemented more efficiently. When you press the button, the app starts searching for the CCCD for the buttonless DFU characteristic from the beginning of the attribute table instead of limiting the search to the handle range for the buttonless service as it does when you do it manually. The handle range for each service is found through the primary discovery at the beginning of the connection.

Here's the part showing the primary service discovery:

With regards to connection intervals, I guess you can leave it to the phone to decide considering you don't have a tight power budget. I.e., you don't have to send connection parameter update requests to the phone. Phones will usually select an interval between 30-50 ms by default in my experience. And there are phones that will start with 7.5 ms intervals until the discovery is complete, then automatically switch to a longer interval, or accept interval requested by peripheral.  

Apple provides some recommendations for selecting connection parameters in section 25.6 of this document: https://developer.apple.com/accessories/Accessory-Design-Guidelines.pdf.

[sjerlhagen]

Thanks, now I understand.