DFU app bad handling of errors

RE: DFU app bad handling of errors

Hung Bui — Wed, 02 Apr 2014 16:04:18 GMT

@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

RE: DFU app bad handling of errors

Frank Zhao — Wed, 02 Apr 2014 14:35:40 GMT

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)

RE: DFU app bad handling of errors

Hung Bui — Wed, 02 Apr 2014 14:24:06 GMT

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)

RE: DFU app bad handling of errors

Frank Zhao — Tue, 01 Apr 2014 18:29:26 GMT

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.

RE: DFU app bad handling of errors

Hung Bui — Tue, 01 Apr 2014 16:51:48 GMT

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 ?