Android/IOS DFU throughput

[jspiller]

I am currently working with a dvk-bl653 working on increasing the speed of the DFU. I have a max packet size of 251 and have tried different connection intervals but only see a throughput of ~3.5 - 4.2kB/s, is this normal? What would be causing such a limitation of the speed since 2M phy has a much higher bandwidth? I used the nrf sniffer and saw many empty PDUs, would there be a way to decrease the amount of empty PDUs to increase the speed or hold off on sending one until it can confirm the reception of multiple packets? I am using the peripheral_uart sample project with a modified prj.conj file.

0250.15ms interval - S10.pcapng

4062.7ms interval - S10.pcapng

[Jørgen Holmefjord]

Hi,

The main bottleneck in the DFU throughput is the process of writing the received firmware pieces into the flash of the nRF52 device. You may tweak some parameters to try to improve it, but the numbers you are reporting are about what I would expect.

The empty PDUs are caused by no data being sent at the given connection interval. This is likely caused by the bootloader waiting for completion of the flash write before accepting more packets. The empty PDUs are still required to keep the BLE link active. If you want less empty PDUs, you need to increase the connection interval, etc.

Best regards,
Jørgen

[jspiller]

Thanks for your response, so if the flash is the main bottleneck how come flashing through J-Link would be so much faster? It takes about 10 seconds for a J-Link flash but over a minute for a DFU flash with a 227kB file.

[Jørgen Holmefjord]

Flash writes can't be executed while the CPU is running, since the Softdevice code is located in flash. If the CPU would be running during flash write/erase operations, it could try to access flash to load instructions while the flash operation is ongoing. This means that the Softdevice needs to schedule the flash write operations between any scheduled BLE events, like connection events and advertising/scanning. When the write operation is completed, the DFU client needs to wait for the next connection event to request a new packet, which needs to be transferred to the device before it can be written to flash. All these operations adds overhead which is not required when programming the flash from a debugger. The debugger can write a small application to RAM, which again will write received data to flash while receiving the next chunk over SWD, almost without any overhead.