Android/IOS DFU throughput

RE: Android/IOS DFU throughput

Jørgen Holmefjord — Thu, 03 Mar 2022 20:27:26 GMT

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.

RE: Android/IOS DFU throughput

jspiller — Wed, 23 Feb 2022 17:05:22 GMT

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.

RE: Android/IOS DFU throughput

Jørgen Holmefjord — Wed, 23 Feb 2022 15:45:08 GMT

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