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.

[seajayshore]

Perhaps my issue comes from the way the mbed BLE_API calls the bootloader:

            // Call bootloader_start implicitly trough a event handler call
        // it is a work around for bootloader_start not being public in sdk 8.1
        ble_dfu_t p_dfu;
        ble_dfu_evt_t p_evt;

        p_dfu.conn_handle = params->connHandle;
        p_evt.ble_dfu_evt_type = BLE_DFU_START;

        dfu_app_on_dfu_evt(&p_dfu, &p_evt);

Seems the peer_data never really gets passed...

[Hung Bui]

@Chris Shaw: I'm sure it's the way it worked with our DFU bootloader in the SDK. However I'm not so sure about the mbed bootloader. Note that there is a requirement on the DFU revision value, on the bootloader it should be DFU_REV_MINOR = 0x08 and on the application DFU_REV_MINOR = 1.

I would need to a sniffer trace to be able to tell what happens exactly.

[seajayshore]

The bootloader I'm compiling & using is a very slighty changed version of the SDK v10 DFU example for S110. I'm only changing the way LEDs are turned on/off & avoiding using a button.

I've also now added the revision characteristic to my application with value 0x0100 as it wasn't there before. nRF Connect reads this number/version correctly

I've also made sue the IS_SRVC_CHANGED_CHARACT_PRESENT parameter is set to 1 in both app & bootloader and is setting-up the service-changed characteristic OK. When uploading with nRF Connect I never actually see an update/indicate on this characteristic however... maybe this indicates a problem? But the example Heartrate in SDK does exactly the same...

I think my problem is a difference in how mbed DFUService calls the bootloader. It never uses the ble_dfu_on_ble_evt function and uses dfu_app_on_dfu_evt instead... Don't know what the difference is.

[Hung Bui]

@Chris: Please correct me if I'm wrong, the problem you have now is that when the bootloader start, it change the address by +1 and the nRFToolbox or NRFConnect doesn't want to connect to that bootloader automatically ?

But you still can manually connect to the bootloader and do DFU update ?

Do you have the same issue when testing with our stock bootloader example and HRM_DFU example in the SDK ?

I think we many need to create a new question (case) to described the issue more clear.

[seajayshore]

Correct!

My app + my bootloader requires me to manually start the DFU bootloader (by writing something to the ControlPoint provided in the application code) and then reconnecting to the new DfuTarg (now with a new DeviceID on iOS) then nRF Toolbox can update DFU OK. If I start the process from nRF Toolbox then it gets stuck at "enabling dfu mode..." where I think it's trying to find the new DfuTarg...

When using the HRM_DFU example and either the SDK-example DFU bootloader or my slightly modified version of the example, nRF Toolbox completes without a problem. But in this case the DeviceID doesn't change between app->bootloader, so perhaps nRF Toolbox is not handling the DeviceID change ok...

Yes, I'll make a new issue shortly if you think it'd be best.