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

Are others experiencing issues with Anrdoid MCP buttonless DFU?

I was upset early this afternoon because I was experiencing issues with buttonless DFU on Android. As is usually the case, I assumed it was my fault.

First, I reverted to old known working firmware/bootloader combinations. This was unsuccessful. After significant time trying different options, I used the ble_app_hrs on pca10028 s110 with dfu coupled with dual bank ble dfu for s110 on pca10028.

Both examples were lifted out of SDK9.

Everything works correctly with PC-based MCP. Could this be a problem with directed advertising?


EDIT

The upload SOMETIMES works using my application -- about a 30% success rate.

I also have some output from logcat (debugging nRF MCP on android 5.0.2)

11-17 10:47:50.378: E/DfuBaseService(27070): An error occurred while connecting to the device:133

This is after buttonless initiation -- when the android device tries to reconnect with the application in bootloader mode.

Here is an example of looping trying to start DFU

V 12:45:37.576 [DFU] Starting DFU service
V 12:45:37.598 [DFU] Opening file...
I 12:45:37.618 [DFU] Image file opened (21696 bytes in total)
V 12:45:37.633 [DFU] Connecting to DFU target...
D 12:45:37.969 [Broadcast] Action received: android.bluetooth.device.action.ACL_CONNECTED
I 12:45:41.971 [DFU] Connected. Services discovered
V 12:45:42.005 [DFU] Reading DFU version number...
I 12:45:42.036 [DFU] Read Response received from 00001534-1212-efde-1523-785feabcd123, value (0x): 01-00
A 12:45:42.055 [DFU] Version number read: 0.1
W 12:45:42.071 [DFU] Application with buttonless update found
V 12:45:42.086 [DFU] Reading Service Changed CCCD value...
V 12:45:42.134 [DFU] Enabling indications for 00002a05-0000-1000-8000-00805f9b34fb
D 12:45:42.152 [DFU] gatt.writeDescriptor(00002902-0000-1000-8000-00805f9b34fb, value=0x02-00)
A 12:45:42.211 [DFU] Service Changed indications enabled
V 12:45:42.255 [DFU] Restarting service...
V 12:45:42.272 [DFU] Disconnecting...
I 12:45:42.290 [DFU] Disconnected
D 12:45:42.309 [DFU] gatt.close()
D 12:45:42.358 [Broadcast] Action received: android.bluetooth.device.action.ACL_DISCONNECTED
V 12:45:42.419 [DFU] Starting DFU service
V 12:45:42.437 [DFU] Opening file...
I 12:45:42.470 [DFU] Image file opened (21696 bytes in total)
V 12:45:42.487 [DFU] Connecting to DFU target...
D 12:45:42.964 [Broadcast] Action received: android.bluetooth.device.action.ACL_CONNECTED
I 12:45:44.572 [DFU] Connected. Services discovered
V 12:45:44.593 [DFU] Reading DFU version number...
I 12:45:44.682 [DFU] Read Response received from 00001534-1212-efde-1523-785feabcd123, value (0x): 01-00
A 12:45:44.697 [DFU] Version number read: 0.1
W 12:45:44.713 [DFU] Application with buttonless update found
V 12:45:44.728 [DFU] Reading Service Changed CCCD value...
V 12:45:44.790 [DFU] Enabling indications for 00002a05-0000-1000-8000-00805f9b34fb
D 12:45:44.824 [DFU] gatt.writeDescriptor(00002902-0000-1000-8000-00805f9b34fb, value=0x02-00)
A 12:45:44.875 [DFU] Service Changed indications enabled
V 12:45:44.898 [DFU] Restarting service...
V 12:45:44.967 [DFU] Disconnecting...
I 12:45:44.987 [DFU] Disconnected
D 12:45:45.005 [DFU] gatt.close()
D 12:45:45.036 [Broadcast] Action received: android.bluetooth.device.action.ACL_DISCONNECTED
V 12:45:45.078 [DFU] Starting DFU service
V 12:45:45.095 [DFU] Opening file...
I 12:45:45.134 [DFU] Image file opened (21696 bytes in total)
V 12:45:45.149 [DFU] Connecting to DFU target...
D 12:45:45.630 [Broadcast] Action received: android.bluetooth.device.action.ACL_CONNECTED
I 12:45:47.259 [DFU] Connected. Services discovered
V 12:45:47.296 [DFU] Reading DFU version number...
I 12:45:47.370 [DFU] Read Response received from 00001534-1212-efde-1523-785feabcd123, value (0x): 01-00
A 12:45:47.385 [DFU] Version number read: 0.1
W 12:45:47.401 [DFU] Application with buttonless update found
V 12:45:47.416 [DFU] Reading Service Changed CCCD value...
V 12:45:47.461 [DFU] Enabling indications for 00002a05-0000-1000-8000-00805f9b34fb
D 12:45:47.477 [DFU] gatt.writeDescriptor(00002902-0000-1000-8000-00805f9b34fb, value=0x02-00)
A 12:45:47.557 [DFU] Service Changed indications enabled
V 12:45:47.572 [DFU] Restarting service...
V 12:45:47.590 [DFU] Disconnecting...
I 12:45:47.607 [DFU] Disconnected
D 12:45:47.629 [DFU] gatt.close()
D 12:45:47.735 [Broadcast] Action received: android.bluetooth.device.action.ACL_DISCONNECTED
V 12:45:47.751 [DFU] Starting DFU service
V 12:45:47.766 [DFU] Opening file...
I 12:45:47.782 [DFU] Image file opened (21696 bytes in total)
V 12:45:47.802 [DFU] Connecting to DFU target...
W 12:45:47.822 [DFU] Connected. DFU Service not found
D 12:45:47.837 [DFU] gatt.close()
V 12:45:47.853 Connecting to CB:B8:77:F6:7A:BE...
D 12:45:47.868 gatt = device.connectGatt(autoConnect = false)
D 12:45:48.289 [Callback] Connection state changed with status: 0 and new state: CONNECTED (2)
D 12:45:48.309 [Broadcast] Action received: android.bluetooth.device.action.ACL_CONNECTED
I 12:45:48.326 Connected to CB:B8:77:F6:7A:BE
D 12:45:48.348 wait(600ms)
V 12:45:48.985 Discovering Services...
D 12:45:49.014 gatt.discoverServices()
D 12:45:49.047 [Callback] Services discovered with status: 0
I 12:45:49.073 Services Discovered

EDIT

Please find attached 3 files. One contains a successful update, one contains an unsuccessful update, and another contains 3 unsuccessful updates followed by a successful update. All of which were updating my application to the same version of my application using the stock bootloader and MCP android 3.4.1

It seems as if the 'enter bootloader characteristics' are not being written before link termination for unsuccessful updates, resulting in a failure to enter bootloader mode before reconnection.

Unsuccessful update from myapp to myapp

successful update from myapp to myapp

three unsuccessful updates then a successful one from myapp to myapp


EDIT

Using MCP 3.9.0.6 I get a 100% update success rate, which points me to an issue on the mobile side. This is good because it indicates to me the problem does not lie with the firmware, but my co-workers and our partners without development dongles prefer to use the mobile app.

  • Hi Syntroniks,

    Please let me know:

    • Do you have any trouble doing DFU for the first time after you flash the bootloader and update the ble_app_hrs buttonless dfu example ? Which package .zip file did you use ?

    • After you have the buttonless example running, which package .zip file did you use to flash the next firmware

    • Which issue do you have when doing DFU on Android ?

  • Hi Hung, I saw a similar question in which you posted a very good answer here: devzone.nordicsemi.com/.../

    Yes I have trouble the first time, I used a package/zip I created using the python tool distributed with mcp.

    From my observation it seems like the central (performing the dfu) is unable to reconnect when the peripheral chooses directed advertisement for reconnect. I have verified dfu_ble_svc has some noinit ram available. I shifted around the bootloader size a bit to make room for hmac_sha256 signing.

    HMAC_KEY_ADDR: 0x0003F800

    BOOTLOADER_REGION_START: 0x00039C00

    BOOTLOADER_SETTINGS_ADDRESS: 0x0003FC00

    IROM1 Start: 0x39C00 size 0x6000

    IRAM1: 0x20002C00 size 0x5380

    IRAM2: 0x20007F80 size 0x80

  • Using the stock bootloader I still have issues. I can run the hrm app with buttonless dfu and update indefinitely. After I update to my buttonless application (same bootloader, no customization), the dfu success rate drops to ~30%.

    I have checked my implementation, pstorage is started, the device manager is configured the same way, and all events are propagated as necessary. One time master control panel got in an infinite loop of trying to invoke the bootloader

  • Hi Syntroniks,

    Please verify, would you be able to use our hrm button less dfu example to update it self with no problem indefinitely ?
    I would need to have a sniffer trace to know what happens over the air when you are doing updating with your application (when issue occurs).

  • I can verify the hrm application updates itself indefinitely if the android bluetooth stack is happy. To make the stack happy, I restarted the BT adapter. I can provide more android logcat logs if that would help. The GATT table on my application is larger than the HRM application by approx. 30%. Pairing/bonding was not used for any of the updates, but pstorage and the device manager are present in both applications. I have attached the requested captures in the main question.

Related