BLE DFU Speed difference between SDK14.2 and SDK15.3

[SciTER Development Team]

Config1:
MCU : nRF52840
SDK : SDK15.3
Softdevice : s340_nrf52_6.1.1_softdevice (SDK15.3)
Phone: iOS version 12.1

Config2:
MCU : nRF52832
SDK : SDK14.2
Softdevice : s332_nrf52_5.0.0_softdevice (SDK14.2)
Phone: iOS version 12.1

We have use SDK Bootloader example code for both SDK14.2 and SDK15.3 for BLE DFU. Our bootloader is based on the BLE secure bootloader example from SDK14.2 and SDK15.3

Now if we use SDK14.2 then it will take max 2 minute for BLE application upgrade.
and if we use SDK15.3 then it will take around 12 to 15 minute for BLE application upgrade.

Note: Application file size which is used in both upgrade is same.

so my question is for SDK15.3 boothloader example code takes more time then SDK14.2 bootloader example code.
Why it takes more time?

I use same app and mobile device in both condition.

Thanks,
Sandip Divani

[Himansu]

Hi,

I have taken sniffer log for issue and updating here.

We have use iphone 11 with latest iOS. so, DFU time is reduce and achieve 175 seconds. still we want to reduce this time. Please suggest any method or any other parameter we can change in phone app or bootloader. so, we can achieve less time compare to 175 seconds. Pleas suggest any applicable solution for achieve minimum time for app update.

We have do 3 test and result and sniffer log file name here.

MCU : nRF52840
SDK : SDK15.3
Softdevice : s340_nrf52_6.1.1_softdevice (SDK15.3)

DFU Test Cases and Sniffer log
Test#	Peripheral	Central	Conn Interval	DFU App Size	Observered Param	DFU Time	Sniffer Log File Name
1	nRF52840 Chipset	nRF52840 DevKit	Conn. Interval = 30 msec	241 KBytes	PHY1M, Conn. Interval = 30 msec	158 sec	Test1_nRFDevKit.pcapng
2	nRF52840 Chipset	nRF52840 DevKit	Conn. Interval = 7.5 msec	241 KBytes	PHY1M, Conn. Interval = 7.5 msec	122 sec	Test2_nRFDevKit_Set7p5ConnInt.pcapng
3	nRF52840 Chipset	iPhone 11		241 KBytes	PHY2M, Conn. Interval = 90 msec	174 sec	Test3_iPhone11.pcapng

Thanks,

Himansu

Test3_iPhone11.pcapng

Test2_nRFDevKit_Set7p5ConnInt.pcapng

Test1_nRFDevKit.pcapng

[Hung Bui]

Hi Himansu, 
I can see that at test 2 you are achieving quite a good speed of transmitting. However I don't see using data length extension. This resulted in that the length of a packet is only 23 bytes (27 with the header). If you can update the data length extension (LL_LENGTH_REQ) you may be able to achieve faster DFU transmitting. 

Regarding case 3, I think what can be improved here is that instead of requesting min interval of 7.5ms (which will not be accepted by iOS) you can try to request min 30ms max 50 ms for example. Then you will have more chance being granted 30ms , this is much better than 90ms as in your trace. 

In addition, there was quite a lot of retransmission in the trace, seems that the communication was interfered quite a lot or the antenna/radio was not tuned on the NRF52840 DUT board you have. I don't see that problem in the test 1 and test 2. 

[Himansu]

Hi,

Query: How to Enable Data Length Extension using Application nRF Util?

- Peripheral Device:
nRF52840 Chip-set

- Central Device:
nRF52840 DevKit

- Central Device controlled using Application nRF Util which is useing for testing:
github.com/.../pc-nrfutil

- Used Command:
nrfutil dfu ble -ic NRF52 -pkg E:\App.zip -p COM6 -n "DFU" -f -mtu 247

Regards,

Himansu

[Hung Bui]

Hi Himasu, 

If you are using nrfutil, please make sure you used the latest version and the softdevice you used for the firmware is >3 . You can find the code where longer data length is requested here: https://github.com/NordicSemiconductor/pc-nrfutil/blob/master/nordicsemi/dfu/dfu_transport_ble.py#L170

On the bootloader side we don't set a certain data length but simply follow what's requested and max supported. Check BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST event inside ble_evt_handler() in nrf_dfu_ble.c