OTA DFU speed / Bonbed OTA DFU with nrfutil

RE: OTA DFU speed / Bonbed OTA DFU with nrfutil

roland.schenk — Wed, 22 Aug 2018 11:06:16 GMT

Hello,

The problem is not storing the private & public keys for the firmware signature and bootloader.

The problem is that the pairing/bonding keys (IRK, LTK, ...) are stored in the Flash of the targed device by the peer manager. But on the PC side the nrfutil tool doesn't save the pairing/bonding keys (IRK, LTK, ...) and tries to perform a new pairing/bonding at each connect to the same targed device. This will be refused by the targed device, because there are already pairing/bonding keys (IRK, LTK, ...) stored from the previous pairing/bonding.

Is there a solution to store pairing/bonding informations on the PC using nrfutil? Or is there a possibility to solve this problem in another way?

Best regards

Roland

RE: OTA DFU speed / Bonbed OTA DFU with nrfutil

Bjørn Kvaale — Fri, 15 Jun 2018 12:42:58 GMT

[quote user="roland.schenk"]I made an update of the application only. So there is no restriction to upload an application with same version.[/quote]

I fully agree with this.

If you generate a new public & private key combo, you need to rebuild the bootloader (see link). The bootloader that is on your target device has been programmed with a public & private key & will only recognize a dfu from these keys. If you use a new private & public key, the old bootloader on the device will not acknowledge these new keys.

My suggestion is to store the private & public keys on your computer.

RE: OTA DFU speed / Bonbed OTA DFU with nrfutil

Bjørn Kvaale — Fri, 15 Jun 2018 11:51:11 GMT

It is unfortunately not possible to use pc_ble_driver_sd_api_v3 on the nrf51 dongle. The last version supported for the nrf51 is the v2.

RE: OTA DFU speed / Bonbed OTA DFU with nrfutil

roland.schenk — Tue, 12 Jun 2018 11:34:34 GMT

To the second question about OTA DFU with a bonded device:
I made an update of the application only. So there is no restriction to upload an application with same version.
I think the problem is, that the pairing/bonding information is n' t stored on the PC using nrfutil for OTA DFU. In the target device the pairing/bonding infos are stored. If the PC nrfutil tries to pair the same target deviece a second time with a new key, it will fail.
Is there a solution to store pairing/bonding informations on the PC using nrfutil?

RE: OTA DFU speed / Bonbed OTA DFU with nrfutil

roland.schenk — Tue, 12 Jun 2018 09:53:08 GMT

To the question about OTA DFU upload speed:
I have made some additional measurements for an application upload of 42KBytes:
PC nRF Connect:               45s
PC nrfutil:                             60s
Android nRF Connect       6s

With the nRF sniffer I observed the uploads and I have seen, that PC nRF Connect always uses 10ms connction interval, and PC nrfutil uses 15ms connection interval, even if the max. connection interval is set t0 10ms.
With nRF sniffer I have seen, that the real fast upload with the android nRF Connect is realized by setting the MTU size to 247. On PC nRF Connect and nrfutil this is not done.

Looking at the python source code of nrfutil, I found in dfu_transport_ble.py that the MTU size is only increased if the nrf_sd_ble_api_ver is >= 3. In my case the pc_ble_driver_sd_api_v2 is used.

How is it possible to use pc_ble_driver_sd_api_v3 with increased MTU size with nrfutil and the nRF51 Dongle (PCA10031)?

RE: OTA DFU speed / Bonbed OTA DFU with nrfutil

Bjørn Kvaale — Tue, 05 Jun 2018 12:13:26 GMT

This devzone case could be useful for you. As the last link & this link state: the easiest solution is to lower the connection interval in the nrfutil code to increase the dfu speed.

Regarding your second question, this should definitely be possible. Just beware that if you are updating the bootloader, you need to follow the validation rules posted under the subsection "Acceptance rules for version" in this link. The reason is that the new FW version needs to be > than old FW version for the bootloader. For the application, it is >=.