Transfer speed secure DFU SDK14

RE: Transfer speed secure DFU SDK14

janR — Tue, 06 Feb 2018 15:06:27 GMT

Hi,

I have now managed to improve speed of the secure DFU bootloader in SDK14.
Speed has improved from about 1 kbyte/sec to 3.5 kbyte sec on a Samsung tablet with bluetooth 4.2, and about 5.5 kbyte/sec on a Samsung Galaxy S8 phone with bluetooth 5.
The only change to bootloader is reducing connection interval. This is now reduced from 48.75ms to between 10 and 12ms.
There were no functionality in the SDK14 secure DFU bootloader for doing this (no negotiation were done regarding connection interval), so tablet could set whatever connection interval it wanted.
In SDK11, (which has much faster flashing) the negotiation was implemented using the ble_conn_params module.
Enabling the NRF_BLE_CONN_PARAMS in SDK14, setting min/max connection interval to 10/12, and call the ble_conn_params_init() did the trick.

Regards, Jan

RE: Transfer speed secure DFU SDK14

MartinBL — Mon, 29 Jan 2018 13:15:02 GMT

Those traces seem to confirm my suspicions. When you use the PCA10040, the two devices agree on a connection interval of 7.5ms from the get go and leave it at that. The Tablet starts off with 7.5ms, but after 40.86 seconds it sends a Connection Update Indication packet and adjusts the connection interval to 48ms.

RE: Transfer speed secure DFU SDK14

janR — Fri, 26 Jan 2018 10:45:12 GMT

Hi, and thanks for the info. I will check it up.

Here are the traces (Ellisys Bluetooth Analyzer) link text link text

RE: Transfer speed secure DFU SDK14

MartinBL — Fri, 26 Jan 2018 08:48:12 GMT

Here is a slightly more advanced blog with more thurough calculations by the way: Bluetooth 5 speed: How to achieve maximum throughput for your BLE application.

RE: Transfer speed secure DFU SDK14

MartinBL — Fri, 26 Jan 2018 08:46:58 GMT

Could you upload the traces?

RE: Transfer speed secure DFU SDK14

MartinBL — Fri, 26 Jan 2018 08:46:11 GMT

Hi,

I think this blog post might help clarify what is going on: Maximizing BLE Throughput on iOS and Android

Your tablet probably has an outdated BLE stack and/or chipset which simply can't handle more than 4 packet per connection interval. With the PCA10040 and the Softdevice there isn't really a limit for how many packets you can send per CI, as long as you stay within the borders of each connection event.

What is happening with your tablet is probably an attempt of power optimization. It starts off with a high interval to get the connection process and database discovery done as fast as possible, but afterwards it throttles the parameters back a little to a more power friendly setting. This is a pretty common procedure in a lot of devices (at least for Samsung devices I believe).

RE: Transfer speed secure DFU SDK14

janR — Thu, 25 Jan 2018 14:43:56 GMT

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?

RE: Transfer speed secure DFU SDK14

MartinBL — Thu, 25 Jan 2018 13:27:11 GMT

Difficult to say what is going on then. Some sniffer traces could help clarify what kind of parameters are actually being used.

RE: Transfer speed secure DFU SDK14

janR — Thu, 25 Jan 2018 10:40:09 GMT

Got it to run. I had to change this:

err_code = sd_ble_gap_adv_start(&adv_params, BLE_CONN_CFG_TAG_DEFAULT);

to this:

err_code = sd_ble_gap_adv_start(&adv_params, CONN_CFG_TAG);

Unforunately, the transfer speed stays at the same, about 1Kbytes/sec

RE: Transfer speed secure DFU SDK14

janR — Thu, 25 Jan 2018 10:25:21 GMT

#define CONN_CFG_TAG 1

I tried to set the tag to several values (1,2,3 and 4), but the bootloader will still not start. If I comment out the above code, the bootloader runs fine.

There is two more sd_ble_cfg_set():

// Configure the maximum number of connections.
memset(&ble_cfg, 0, sizeof(ble_cfg));
ble_cfg.gap_cfg.role_count_cfg.periph_role_count  = 1;
ble_cfg.gap_cfg.role_count_cfg.central_role_count = 0;
ble_cfg.gap_cfg.role_count_cfg.central_sec_count  = 0;
err_code = sd_ble_cfg_set(BLE_GAP_CFG_ROLE_COUNT, &ble_cfg, ram_start);

and

ble_gatts_cfg_service_changed.gatts_cfg.service_changed.service_changed = 1;
err_code = sd_ble_cfg_set(BLE_GATTS_CFG_SERVICE_CHANGED, &ble_gatts_cfg_service_changed, ram_start);

These are in the original function, and not changed. Shouldn't these have a unique tag?

RE: Transfer speed secure DFU SDK14

MartinBL — Thu, 25 Jan 2018 09:02:19 GMT

What is the value of CONN_CFG_TAG? Note the description of ble_conn_cfg_t in ble.h:

[conn_cfg_tag field] ... Must be different for all connection configurations added and not @ref BLE_CONN_CFG_TAG_DEFAULT. */

RE: Transfer speed secure DFU SDK14

janR — Tue, 23 Jan 2018 15:56:50 GMT

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?

RE: Transfer speed secure DFU SDK14

MartinBL — Tue, 23 Jan 2018 14:33:36 GMT

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.

RE: Transfer speed secure DFU SDK14

shibshab — Mon, 22 Jan 2018 11:27:11 GMT

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).

RE: Transfer speed secure DFU SDK14

janR — Mon, 22 Jan 2018 11:11:11 GMT

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

RE: Transfer speed secure DFU SDK14

shibshab — Mon, 22 Jan 2018 10:58:52 GMT

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.