What is the theoretical maximum DFU speed that can be reached for a NRF52832 target?
What is the theoretical maximum DFU speed that can be reached for a NRF52832 target?
The theoretical maximum DFU speed is the same as the theoretical maximum throughput for a Bluetooth Low Energy link. That would be around 1.3MBPS (payload throughput).
Best regards,
Edvin
I guess that's only taking into account BLE throughput, not writing to flash, overhead etc?
I'm trying to figure out how long it would take to update say 1000 devices over BLE with a 200 kB image in ideal conditions. So, a first question is: what is the minimum time it takes to transfer this 200 kB image to an NRF52832 based device in ideal conditions?
bds said:I guess that's only taking into account BLE throughput, not writing to flash, overhead etc?
That is correct. It does take the BLE overhead into account, but not the flash write, and the swap (in case you have a double bank bootloader) and verification of the new image.
I can't give an exact answer. Did you test how long it takes to update one device? My guesstimate would be around 30 seconds per device. I could be entirely wrong. Perhaps it is 10 seconds. Perhaps it is 50 seconds. The theoretical minimum is the payload throughput speed of 1.3MBPS + the time it takes to do the flash operations (write and erase). Then you have the processing and verification time, which I guess the DFU master doesn't really need to wait for.
The question is whether you want to start tweaking parameters inside the bootloader to optimize this. I am not sure exactly what would be the bottleneck. You probably want to force a single bank bootloader (which would probably be the default if your image is 200kB). Sending larger DFU packets (large MTU) will lead to less overhead. Other than that I would say that it takes the time it takes. I have not tested with a 200kB image.
Also, what SDK are you using? nRF5 SDK or nRF Connect SDK (NCS)? In NCS you need to do dual banking, so the swap would take some extra time, but again, the DFU Master doesn't strictly need to wait for that to complete.
Best regards,
Edvin
Doesn't Nordic have any BLE OTA DFU performance test data?
Our bootloader is based on NRF5 SDK 15.2. I just tested with a 244 kB image, and it took 3 minutes 12 seconds. I used NRF Connect for desktop 3.12.0 with BLE Standalone 4.0.0 and a PCA10040 v1.1.1 NRF52832 dev kit.
bds said:Doesn't Nordic have any BLE OTA DFU performance test data?
Not that I am aware of.
I just did a test with a transfer with an application with size 53660 bytes. Including finding and connecting to the device running the ble_app_buttonless_dfu example, It took 26 seconds, but the application transfer itself only took 9 seconds.
I used nrfutil to perform the DFU, not nRF Connect for Desktop, and for this test, I used the unmodified bootloader and ble_app_buttonless_dfu example from SDK15.2.0.
Can you try to perform the same using nrfutil?
If you copy the attached text into a .bat file located in SDK15.2.0\examples\dfu\secure_bootloader\pca10040_ble\armgcc\, it should be quite quick to test.
mkdir files make -j9 make -j9 -C ..\..\..\..\ble_peripheral\ble_app_buttonless_dfu\pca10040\s132\armgcc del files\buttonless.hex copy ..\..\..\..\ble_peripheral\ble_app_buttonless_dfu\pca10040\s132\armgcc\_build\nrf52832_xxaa.hex files\buttonless.hex del files\settings.hex nrfutil settings generate --family NRF52 --application files\buttonless.hex --application-version 1 --bootloader-version 1 --bl-settings-version 1 files\settings.hex nrfjprog -e nrfjprog --program ..\..\..\..\..\components\softdevice\s132\hex\s132_nrf52_6.1.0_softdevice.hex --verify --snr 682324508 nrfjprog --program _build\nrf52832_xxaa_s132.hex --verify --snr 682324508 nrfjprog --program files\settings.hex --verify --snr 682324508 nrfjprog --program files\buttonless.hex --verify --snr 682324508 nrfjprog --reset --snr 682324508 nrfutil pkg generate --application files\buttonless.hex --application-version 2 --hw-version 52 --sd-req 0xAF --key-file ..\..\..\private.key files\dfu_image.zip timeout 5 nrfutil dfu ble -pkg files\dfu_image.zip -ic NRF52 -p COM14 -n "Nordic_Buttonless"
Obviously, replace the serial number with your own target DK, and replace COM14 with the connectivity device (already flashed with the correct firmware if you have used it with nRF Connect for Desktop -> Bluetooth Low Energy).
Best regards,
Edvin
I didn't find the time yet to exactly replicate your test, but I did something similar.
I repeated the same DFU procedure with a 195016 bytes application with our SDK 15.2 based bootloader (minor modifications from the SDK example) with different DFU master tools (5 repetitions for every tool).
With:
It seems there is a lot of difference in DFU speed depending on the master tool used...
I'd like to build a PC or Raspberry Pi based solution with at least the same performance (preferable better) as the IOS app. I'm guessing even better performance should be possible since on IOS, the connection interval, number of packets per connection interval and MTU are limited. Correct?
I didn't find the time yet to exactly replicate your test, but I did something similar.
I repeated the same DFU procedure with a 195016 bytes application with our SDK 15.2 based bootloader (minor modifications from the SDK example) with different DFU master tools (5 repetitions for every tool).
With:
It seems there is a lot of difference in DFU speed depending on the master tool used...
I'd like to build a PC or Raspberry Pi based solution with at least the same performance (preferable better) as the IOS app. I'm guessing even better performance should be possible since on IOS, the connection interval, number of packets per connection interval and MTU are limited. Correct?
Interresting that the iPhone was that much better. I wouldn't expect it.
The key to increasing the transfer speed is to optimize the connection parameters for this purpose.
I don't know if the case is that you already have 1000 devices deployed that you need to upate. In that case, I believe I would simply start updating them, and you would be done by now. If the case is that you plan to have 1000 devices in field, then you may start looking into this now, but you can also consider deploying devices with a bluetooth Mesh bootloader, which then makes it possible to update all the devices at once. It is quite slow, but it will take about an hour, and all your devices would be updated at once.
To increase the speed, the trick is to have a connection interval about of about 50ms, a large MTU (247 = max), send as large packs as possible. I would think that nrfutil already did that about as efficiently as possible. What is the connectivity board you are using with nrfutil and nRF Connect for Desktop?
nRF Connect for Desktop is closed source, so it is not possible to change anything there (but I imagine you don't want to sit and click through all 1000 updates.
nrfutil is open source (although I must admit I have never built it myself):
https://github.com/NordicSemiconductor/pc-nrfutil
So you should be able to tweak parameters there. Also note that you "can't" use an nRF51DK (you can, but it will not have the same throughput).
Also, the DFU libraries used in nRF Connect for Android or iOS are also available. iOS version here. So it is also possible to write a custom app, either using nrfutil and a connectivity DK, or using a mobile phone, that can iterate through and update all the devices.
Best regards,
Edvin
