This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

OTA DFU speed / Bonbed OTA DFU with nrfutil

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

Parents Reply Children
  • 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)?

  • 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?

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

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

  • 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

Related