OTA DFU speed / Bonbed OTA DFU with nrfutil

[roland.schenk]

I' m using the nRF51 Dongle (PCA10031) for the evaluation of the OTA DFU bootloaders of SDK15.0.0 with the NRF52840 PDK.
Using the PC tool nRFConnect V2.3.2 with the App Bluetooth Low Energy V2.1.0 the download speed is much higher than using nrfutil (V3.5.1) dfu ble -ic NRF51 -pkg dfu_app_test.zip -p COM4 -n "DfuTarg" -f.
I have seen, that nRFConnect is using Connectivity firmware V1.2.2 with 1Mbit/s on the nRF51 Dongle, while nrfutil is using Connectivity firmware V1.2.0 with 115,2kbit/s.

Is there a possibility to speed up the download with nrfutil?

A other question to OTA DFU with a bonded target device with nrfutil:
The first OTA DFU with bonds ist working fine with nrfutil. But if I try to program the same target device a second time, it won't work.

Is there a possibility to use bonded OTA DFU with nrfutil repeatedly on the same target device?

Best regards
Roland

[Bjørn Kvaale]

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 >=. 

[roland.schenk]

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?

[Bjørn Kvaale]

roland.schenk said:

I made an update of the application only. So there is no restriction to upload an application with same version.

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.

[roland.schenk]

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