nRF Mcp Dfu freezes when »Number of packets« is set greater than about 356 packets

[John Miller]

Hey there,

today I'd tested around with the Dfu service.

• Peripheral is nRF51822 running Sdk 5.2.0 bootloader example (Softdevice 6)
• Central is Android 4.3 running nRF Mcp 1.9.1
• Testfile (nRF51822 Application) is Hrs Example (about 43k binary size)

In the settings of Mcp I found some Dfu options and I determined that the »Number of packets« value has an affect to the update data throughput.

My Android device connects with 48,75 ms connection intervall and transferes mostly about 4 packets at each connection intervall. So, the max throughput is theoreticly at

4 x 20 Byte / 48,75 ms = about 1.641 Byte/s

But when metering the Dfu throughput, I got just about 1.000 Byte/s. Well, after changing »Number of packets« from 20 to 300, I got about 1.600 Byte/s - nice.

But then, when I set »Number of packets« to greater values (e.g. to 400), the Dfu upload freezes at 16 % - and the same when I switching off the option »Packets receipt notification procedure«.

For »Number of packets«, I determined a treshold value of 356. This means that Dfu works with values up to 356, but for greater values the Dfu freezes at 16 %.

Ok, I don't expect higher throughput with higher »Number of packets« values. I'd just detected that issue and would report it.

Btw: Is this the right place for that kind of topics or should I rather put that in an issue tracker?

[Balaji Srinivasan]

Hi John and Joe,

The root cause of the issues most probably lies in the application using the app_scheduler module the SDK. The application is not fast enough to pull out all the events from the scheduler queue because there is just too many BLE events generated by the SoftDevice (because of too many BLE packets being received in short time).

In John's case, its the bootloader that is not fast enough (Each time it receives a firmware data packet, it needs time to process it and store it. That takes time.). That is the very reason why the 'Packet Receipt Notification' was introduced in the DFU application - to allow the application to tell the central that it is ready to receive the next set of firmware packets. And it looks like with John's connection interval, 300 is the maximum value for 'Number of packets' (This indicates the number of packets after which the Packet Receipt Notification is sent). Side note: I turned off the Packet Notification on my android app and I found out that my DFU will always get stuck at 76%.

In Joe's case, the Read operation sent from the central, introduces a delay and that allows his application to pull out all the events from the Scheduler queue (this can be considered similar to the 'Packet Receipt Notification' of the DFU example).

It is a good feedback for the android/ios app development team. The app can warn the user about setting too high value for 'Number of Packets' field.

Also the SDK team is aware of this and will explore the possibility addressing this in the scheduler module in the upcoming releases.

Cheers, Balaji