DFU app bad handling of errors

[Frank Zhao]

I am trying to bootload an extremely large hex file using a slightly modified DFU (modified from SDK v5.2.0's example)

The problem is that the hex is so large that eventually, pstorage's task queue is filled, and returns a no-memory error

The Android app "nRF Toolbox" v1.5.2 simply spits out a reset command back, which makes it impossible to load my hex

Please fix the app or the firmware example such that it actually waits for the previous flash write to complete, or gracefully handle busy conditions.

[Hung Bui]

Hi Frank,

11.25ms to 15ms is the default connection interval range in our DFU example. From what I know, it's safe if the number of packet per connection interval is about 3-4 packet per conn interval. Could you run a sniffer and find how many packets were sent per conn interval ?

One solution for this is to use the Packet Receipt Notification to make sure the device has successfully received and stored the data packets in flash before the master sends the next ones. It's a pretty new feature of the DFU bootloader, please have a look in the SDK documentation. (Examples-> Bootloader/DFU -> DFU Transport layer -> BLE)

[Frank Zhao]

I have already set the number of packet to 1, this is due to a previous problem I've had https://devzone.nordicsemi.com/index.php/ios-nrf-loader-timeout-during-upload

I have the latest example code from SDK v5.2.0 (latest as of this post) and it is clear that the notification is sent on line 337 and 356 of dfu_transport_ble.c and it happens even if the flash operation isn't finished yet. (because pstorage_raw_store is not blocking, it simply places stuff in a queue)