DFU transfer speed reduced to half: [email protected]/s vs. [email protected]/s

[Moritz]

Hi,

we are using are more or less unmodified version of the Secure DFU bootloader example. Especially all BLE/Softdevice configuration in "libraries/bootloader/ble_dfu/nrf_ble_dfu.c" is unchanged.

Using the nRF Connect PC application(v2.0.1) as peer we see a average speed of:

• 3.5kB/s with SDK 12.2 and Softdevice S132_v3.1.0

• 1.8kB/s with SDK 13.0 and Softdevice S32_v4.0.4

I'm guessing that this is related to the more conservative standard bandwith configuration in SDv4, but following the migration guide and setting a configuration that corresponds to the old BLE_CONN_BW_HIGH bandwidth configuration doesn't really improve it. It gets just more jagged, but maybe I did something wrong:

Does anybody see the same behaviour and can anything be done about it?

[MartinBL]

Hi,

DFU requires a lot of read and write operations to flash. The new firmware image is received and stored and there are also some flash operations to store progress information etc. Access to flash is restricted by the Softdevice so if the application or bootloader requires access to flash it has to go through the SD Flash API. The API schedules the operations while still maintaining the BLE link at the expense of bandwidth. The dips in the throughput are occurring when chunks of received data are written to flash.

Between SDK 12 and 14 a lot has happened in the flash handling APIs. Unfortunately, it seems like in this case it has actually resulted in degraded performance. This was not intended or something the SDK team predicted. Naturally, the ability to do fast DFUs is important to a lot of customers and we are actively looking at ways to improve it.