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

[shibshab]

What you see is as expected. As far as I know, the bottleneck is the process of storing the received data to flash on the DFU target side.

[janR]

Hi, If I use nRF Connect (v2.2.1) - Bluetooth Low Energy for Windows, and evaluation kit PCA10040, I see a speed of about 4Kbytes/sec), 4 times the speed of the Android tablet. Why is there a difference?

Regards, Jan

[shibshab]

Hm, I have only tested with iOS and nrf5832, and there I see 1kbps. If you look at a sniffer trace, and keep the DFU protocol in the back of your head, you can see whether its the transport or DFU target being the bottleneck. The DFU target will ask for more bytes when it is ready to receive it (in some way described in the DFU documentation).

[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]

Hi, and thanks,

I tried to increase the data length like this:

//Set data length
memset(&ble_cfg, 0x00, sizeof(ble_cfg));
ble_cfg.conn_cfg.conn_cfg_tag                 = CONN_CFG_TAG;
ble_cfg.conn_cfg.params.gatt_conn_cfg.att_mtu = NRF_SDH_BLE_GATT_MAX_MTU_SIZE;
err_code = sd_ble_cfg_set(BLE_CONN_CFG_GATT, &ble_cfg, ram_start);
APP_ERROR_CHECK(err_code);

NRF_LOG_DEBUG("Enabling SoftDevice.");

// Enable BLE stack.
err_code = nrf_sdh_ble_enable(&ram_start);

...

This is done in ble_stack_init(), after Service Changed config, and before enabling the BLE stack

However, it seems to assert when executing sd_ble_cfg_set(). IAR EWB will not debug the code, so I can't see the error code.

NRF_SDH_BLE_GATT_MAX_MTU_SIZE was set to 250. Am I doing it the wrong way?