Start Secure DFU button in application

RE: Start Secure DFU button in application

sjerlhagen — Wed, 29 Jan 2020 15:28:38 GMT

Thanks, now I understand.

RE: Start Secure DFU button in application

Vidar Berg — Wed, 29 Jan 2020 14:46:34 GMT

[quote user="sjerlhagen"]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 ?[/quote]

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.

RE: Start Secure DFU button in application

sjerlhagen — Wed, 29 Jan 2020 13:15:33 GMT

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

RE: Start Secure DFU button in application

Vidar Berg — Wed, 29 Jan 2020 12:26:21 GMT

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?

RE: Start Secure DFU button in application

sjerlhagen — Tue, 28 Jan 2020 14:38:36 GMT

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 ?

devzone.nordicsemi.com/.../dfu_5F00_manual_5F00_no_5F00_hang.pcapng

RE: Start Secure DFU button in application

Vidar Berg — Tue, 28 Jan 2020 13:46:35 GMT

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.

RE: Start Secure DFU button in application

sjerlhagen — Tue, 28 Jan 2020 11:02:24 GMT

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.

devzone.nordicsemi.com/.../dfu_5F00_hang_5F00_2.pcapng

RE: Start Secure DFU button in application

sjerlhagen — Tue, 28 Jan 2020 08:37:33 GMT

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>

RE: Start Secure DFU button in application

Vidar Berg — Mon, 27 Jan 2020 12:33:00 GMT

Hi,

[quote user=""]enable notification for "Buttonless Secure DFU without bonds", and write 01 to it, the device directly reboots to DFU mode.[/quote]

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.