This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Transfer speed secure DFU SDK14

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

  • 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. */

  • #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?

  • 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

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

  • 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?

Related