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

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

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.

  • Hi Chris,

    I'm sorry that I wasn't up to date. We had some modification and now how the thing works is that in our SDK bootloader when we switch from application to the bootloader, we will send the address of the central device we connected to to the bootloader. And the bootloader will use that address to do directed advertising to that address. And there is no +1 in the address of the bootloader.

    The +1 only happens when we start the bootloader from a button or at the beginning when there is no app.

    And the app on the phone will not look for the address +1 but the same address with the application, instead.

    I'm sorry for the confusion.

    In your case with mbed, I guess since there is no data passed from the application to the bootloader (there are 2 cases, pass only address, and pass address and bond information), the bootloader will start up as you hold a button and advertise with +1 address and this will cause the nRF Toolbox and nRF Connect not recognize the bootloader.

    The solution is to either remove the +1 (make sure to enable Service changed characteristic) or to modify the DFU library so that it also look for address+1 after a timeout if it couldn't find the bootloader at the same address.

  • Hi Hung,

    I've been away and just come back to this. Thanks v. much for all the clear information. I think you have explained exactly what is happening.

    I will look at updating/changing the way our mbed app launches bootloader so we can pass information, but until then everything is working fine since we knew about the +1 address changing.

    Thanks for confirming that the nRF Toolbox is just now working with the address change, that explains the problems I was having.

    Thanks again!

  • Hi guys!! I'm trying the same DFU update thing and I get the same symptoms. mBed BLE API, nrf SDK 10, Arduino/gcc/g++ toolchain

    Any news on this problem? Regards

Related