No transport to DfuTarg observed after "Enabling DFU Bootloader..."

[Ray]

First attempt at implementing buttonless dfu; assistance would be greatly appreciated. Using SDK v11 + s130 + nRF51822.

Please note that iphone screen captures supporting my observations can be seen here: https://goo.gl/VlYdBY

I wrote a bootloader, and successfully installed it with sd + app. It seems to be operating well and I'm able to debug, so I am capable of execution flow trace.

I created an app-only zip with good start packet using nrfutil, and added it to NRF Toolbox iOS app as a user file.

I start up my device, which is advertising for dfu properly.

In NRF Toolbox I select my file, then select my device as the target. I then tap "Upload".

The ios App begins the process. It quickly says "Starting update" followed by "Enabling DFU Bootloader...", and then it just sits there forever.

In debugging on the device, I can see that I get all the way through dfu_transport_update_start just fine, and at this point I'm in the bootloader.c wait_for_events() loop as I should be. (It eventually times out properly.)

However, oddly, while the phone is sitting there "Enabling DFU Bootloader...", the device never reaches ble_evt_dispatch() in the dfu transport - not a single time - indicating to me that the phone doesn't seem to be connecting into my device to initiate the transport.

When I use nRF Connect to see what's going on, I do see DfuTarg being advertised. When I Connect to it, I see "Legacy DFU Service" as the primary service. When I open the service, I see Legacy DFU Packet, Control Point, and Revision. (See photos for details.)

The encouraging thing is that when I do use nRF Connect to examine these things, I DO nicely get events coming into the handler at ble_evt_dispatch() within dfu_transport_ble.c. However, as I said, I get nothing coming into that handler as triggered by nRF Toolbox's DFU process.

(It is a bit odd that these things are called "Legacy DFU" given that I'm using the up-to-date SDK and the up-to-date nRF Toolbox & Connect apps. Perhaps a better version must be coming in sdkv12?)

In any case, as I said, the DFU seems to be starting nicely, but I'm blocked at this point given that the BLE transport doesn't seem to be being kicked off.

Any thoughts about what to try next would sincerely be appreciated; thanks for your time.

[Richard]

It's not very helpful, but I'm running into this currently too.

DFUPeripheral.swift just calls connect() which does:

centralManager.connectPeripheral(peripheral!, options: nil)

from the centralManager didDisconnectPeripheral callback when it is disconnected after jumping into the bootloader.

iOS however never succeeds at reconnecting to the device (it is advertising and can be connected to however) until the DFU times out and the device resets itself again, restoring the application to running.

Update 1: Looking at the addresses of the device from nRF Connect from an Android device while running the app vs running the bootloader, the address is changing: xx:xx:xx:xx:xx:xC in the app vs xx:xx:xx:xx:xx:xD in the bootloader. iOS won't be connecting because it thinks it's a different device.

I did see something in the iOS source about handling this situation for SD updates, but that code was literally "eh the address will have changed, so just use the first device found that exposes a DFU service" - not exactly something I'm willing to put into production code.

Update 2: Here's some explanations of what is happening and why: devzone.nordicsemi.com/.../ devzone.nordicsemi.com/.../

Disabling the half-dozen lines from the first link in dfu_transport_update_start() in dfu_transport_ble.c in the bootloader has resolved my issues - DFU is now working on iOS! I'm not using an encrypted link at this stage, so it is not an issue. From those links and the code, it looks like we should use bonded connections and set them up so that the bond information is shared with the bootloader in the long term.

[seajayshore]

So, because of using mbed code to call the DFU-bootloader via the BLE_API (mbed API) it seemed difficult/confusing to use Ray's fix above, but I think it's essentially the same root cause. Something unusual about the way the mbed code starts the Dfu-bootloader and some params are lost/not-communicated and then dfu_ble_peer_data_get() fails etc. (see Ray's comment 2nd from top).

My bodge that has worked was to change the line 1073 in the DFU boot loader code: addr.addr[0] += 1

to: addr.addr[0] += 0;

This allows the boot loader to run through all the same checks, fail to find params, but will not increment the MAC address therefore allowing iOS to find the same "device ID" again (which is assigned by iOS not the firmware).

It's a bodge, but this is more-or-less done in the mbed-sanctioned modified boot loader you can find on the mbed github.