nrfutil DFU upload extremely slow

[Florian Zierer]

as already written in other threads (two years old) the DFU upload with nrfutil is extremely slow.

Transferring the same data from a smartphone (with BLE5) takes about 20seconds, with nrfutil 2 minutes or more.

We use nrf52840 DKs for the PC side and our board.

We use the following command to run the update.

nrfutil dfu ble -ic NRF52 -pkg app_dfu_package.zip -snr $(NRF52840_SNR_BLE) -n "MY_NAME" -f -cd 0

nrfutil version 6.0.0a1

What could be the reason for the slow update. Is there anything we can do to speed this up?

[Edvin]

Hello,

So the device that is "connected" to nrfutil, the nRF52840 DK. Can you please test by using the same DK on nRF Connect for Desktop to perform the DFU? Is the speed the same there?

What nRF chip does your target use? I assume that this is not the issue, since it is faster using the smartphone.

The nRF52840 DK is erased at one point between two years ago and now? So that it is not running the nrfutil FW flashed 2 years ago? Try "nrfjprog -e" before the "nrfutil dfu ble ..."

So. 

1. Please test nRF Connect for Desktop.

2. Please try to update nrfutil to the non-alpha version 6.0.0 found here. 

Let me know about your results. 

BR,
Edvin

[Florian Zierer]

Hi Edvin,

the connectivity firmware on the nrf52840 DK was recently flashed.When using nrfConnect (2.6.2) another fw is flashed.

With nrfConnect the upload speed is similar as from a smartphone.

The target uses also nrf52840.

The non alpha version shows the same behaviour.

We tested this from Linux and Windows.

Florian

[Florian Zierer]

Hi Edvin,

It is nrfutil 6.0.0 installed from pip.

$ nrfutil -v -v -v  version
nrfutil version 6.0.0
2019-12-12 06:58:39,406 PyPi URL: pypi.python.org/.../nrfutil
2019-12-12 06:58:39,406 GitHub URL: https://github.com/NordicSemiconductor/pc-nrfutil

I just had a look at the sourcecode, and I could run nrfutil also from the github repository, so if there would be some improvements, I can test them.

Florian

[Edvin]

Hello Florian,

I took a sniffer trace today. You are correct. I compared the sniffer traces of nrfutil 6.0.0 and nRF Connect. Using nRF Connect the master (the DK that is used by nRF Connect) requests an MTU size of 247Bytes. Nrfutil also does this, but right after this request/response, nRF Connect requests LL_LENGTH_REQ (Data length extension) of 251 octets. Nrfutil doesn't do this.

I have reported this internally. I believe this issue is not present in nrfutilv5.0.0. 

FYI our nrfutil team has updated the softdevice used in nrfutil 6.0.0, which is probably why this was left out by a mistake.

Best regards,

Edvin

[Florian Zierer]

Hi Edvin,

great that you can reproduce the issue.

If I can help to test a fix, please tell me.

The problem is, that when using pc-ble-driver-py with python 3, nrfutil 6 is a dependency so its not so easy to install an older version.

[Edvin]

I understand. I have reported this to our team that write our tools. Hopefully, they will be able to patch it soon.

BR,

Edvin

[Florian Zierer]

Hi Edvin,

I just tested with nrfutil 6.0.1 and it is much better now.

Thanks for fixing it.

Florian

[Edvin]

Hello Florian,

Glad to hear that it was fixed. Again, thank you for reporting this bug.

Best regards,

Edvin

[Jussi]

Hi,

I tested to upload our firmware zip with a NRF52840DK board, and using

nrfutil 5.2.0 on linux takes ~50 seconds and nrfutil 6.0.1 on windows takes ~100 seconds.

Could this same issue be related to our problem?

I tried to use nrfutil 6.0.1 on linux to test the speed, but I can't get it to work:

pc_ble_driver_py.exceptions.NordicSemiException: MTU exchange request failed. Common causes are: missing att_mtu setting in ble_cfg_set, different config tags used in ble_cfg_set and connect.

The size of the firmware zip file is 254K. The connectivity firmware was updated to latest when using the nrfutil 6.0.1 on windows.

Br,

Jussi

[Florian Zierer]

Hi Jussi,

I see these errors also from time to time. I think more often from windows than from linux.

I suspect that it has something do, that the peripheral proposes a MTU and the central tries to send a MTU request at the same time. Then the pc-ble-driver somehow dismisses one of the message and doesn't forward the reply to the pc-ble-driver-py.

I saw this also on sniffer logs. The data packages seem to be sent correctly but the message is not delivered correctly on the PC side.

Could also be a timing issue as described in my other thread https://devzone.nordicsemi.com/f/nordic-q-a/56475/windows-notifications-stopped-with-high-mtu-in-pc-ble-driver-py

Regards,

Florian

[Jussi]

Hi Florian and thank you for the answer.

I actually also tried to set the Windows timer resolution to 1ms with a third party app, but it did not improve the upload speed. I will try to play around with MTU settings if it could improve the speed closer to same what we have on Linux.

Br,

Jussi