This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

DFU app bad handling of errors

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.

  • Hi Frank ,

    Could you let me know the size of your hex ? I don't think it was the size of the hex file that cause the issue. I suspect that it was the rate of transmitting DFU packets was too fast that filled the pstorage queue.

    Do you have a sniffer trace and check for the connection interval when updating the firmware ?

    Which central device did you use for testing ? What was the preferred connection interval you used in the bootloader firmware ?

  • Yes, I already knew it is the fact that the rate of transmitting is causing the pstorage queue to fill, not really the size

    The test was done with a hex that exceeded 80KB (which I know exceeds the dual bank limits, but I modified the DFU code to behave as if it was single bank)

    In fact, I can get it working by increasing the connection interval, but it ends up taking so long that I don't have the patience to complete the testing

    The central device is a Samsung Galaxy Note 3, Android 4.3

    I believe the the connection interval was 12 to 15 ms during the tests that failed.

  • 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)

  • 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)

  • @Frank: You are correct that the bootloader send the notification when it receives and queue the packet, not when it actually finish flashing the packet. I am sorry for the confusion.

    However, it pretty strange that you have the queue full when receiving only one packet per connection interval (I assume so because the notification usually's sent in the next connection interval)

    Have you tried to use our stock DFU example ? Would the same issue occur ?

    Actually we haven't seen this issue when using DFU with 10 packet notification on various central devices tested here, including iPad mini, iPhone 5S, Samsung S4, S3, Nexus 4, 7 etc.

    Could you send us your DFU firmware ? It would be easier to identify the issue if we could reproduce here

Related