Transfer speed secure DFU SDK14

[janR]

Hi,

I wonder what transfer speed can be expected on a BLE DFU update on a nRF52832 based device in the following condition?

-SDK14.0 Secure DFU, nRF52832, Android tablet (Oreo, Bluetooth 5.0), nRF Connect

We are currently facing a transfer speed of about 1 Kbytes/sec, which sounds way too low. On a 350 Kbytes file, it will take almost 6 minutes to transfer.

Regards, Jan

[MartinBL]

Hi

Here are some thoughts from one of the DFU gurus:

There are no hidden tricks, unfortunately. I think SDK version 12.3.0 went as fast as 3.5kb/s, but this was degraded to 1.5kb/s after some changes in SDK 13 and improved again in SDK 14 up to 4.5kb/s.

There are many variables to take into account and the unfortunate thing is that the transfer might fail if only one of the variables is updated and the rest is not. This is because the current DFU protocol does not implement any kind of flow control.

The variables that can be tweaked are NRF_FSTORAGE_SD_MAX_WRITE_SIZE (smaller), connection interval (smaller is faster), and event length might help too. I think the latter depends on which SDK version you are running, since increasing the event length basically steals time from flash access, which is the real bottleneck when we approach higher speeds. It might however help on crippled implementations running as low as 1.5kb/s.

Connection interval is the obvious thing to tweak here because I reckon most Android phones will request a higher interval and the bootloader does not request it by itself. It just accepts whatever the peer requests. That would explain why some phones run faster than others against the same fw implementation.

@janR, can you try to increase the data length as suggested here, but set the data length in ble_stack_init() in addition to setting the value in sdk_config.h? I was made aware that increasing the value in sdk_config.h alone doesn't configure the Softdevice with long lengths from the get-go.

[janR]

Now I have looked at the communication between the devices with a BLE sniffer.

I have traced a DFU update with tablet running nRF Connect, and a DFU update with PCA10040 with nRF Connect - Bluetooth Low Energy.

• Tablet running nRF Connect: 1Kbytes/sec transfer speed, connection interval 48.75ms, 27 bytes/packet.
• PCA10040 with nRF Connect - Bluetooth Low Energy: 4Kbytes/sec transfer speed, connection interval 7.5ms, 27 bytes/packet.

It seems like the connection interval is the big difference, 48.75ms versus 7.5ms. In addition, when the tablet does the update, it sends 4 packets/connection interval constant. The PCA10040 seems to send various number of packets, I have seen up to 7 packets/connection interval.

The tablet (or the PCA10040) does not seem to take the 250 bytes MTU configuration into consideration anywhere.

When I look at the sniffer trace, it seems like the tablet initially decides a connection interval at 7.5ms (the tablet sends a LL_CONNECTION_UPDATE_IND), but after a short while (about 500ms) change it's mind, and decides 48.75ms (it sends a new LL_CONNECTION_UPDATE_IND). It then uses this interval through the entire update. This does not happen with the PCA10040.

The max and min connection interval is set to 7.5ms in the bootloader, but I am not sure if these settings are used? The 48.75ms (or 7.5ms on PCA10040) is kept unchanged regardless of what the max and min connection interval is set to.

Anyway it seems like the worst problem is the tablet, not the bootloader.

Any idea how to come around this?