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

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

RxNcO — Fri, 24 Feb 2017 13:56:15 GMT

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

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

seajayshore — Wed, 17 Aug 2016 10:08:40 GMT

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!

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

Hung Bui — Thu, 04 Aug 2016 14:14:08 GMT

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.

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

seajayshore — Thu, 04 Aug 2016 11:55:42 GMT

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.

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

Hung Bui — Thu, 04 Aug 2016 11:30:52 GMT

@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.

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

seajayshore — Thu, 04 Aug 2016 10:42:42 GMT

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.

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

Hung Bui — Thu, 04 Aug 2016 09:11:27 GMT

@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.

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

seajayshore — Wed, 03 Aug 2016 17:00:51 GMT

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...

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

seajayshore — Wed, 03 Aug 2016 16:42:10 GMT

Hi Hung,

Thanks for the detailed reply. Two main questions if you can:

From your advice & link to the FAQ I've reverted my bootloader code so the default "address + 1" behaviour still occurs. Can you confirm that leaving this address incrementing is the best approach to ensure Android compatibility?

Are you sure the nRF Toolbox app works with this address increase?? It just hangs at "enabling DFU bootloader" at the moment on the iOS app version... I'll try nRF Connect to double check.

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

Hung Bui — Wed, 03 Aug 2016 11:22:28 GMT

It has been a long cases and I'm not sure which question has already been solved and which is still pending. But I can provide some information:

If the device is not bonded to a central, when it switch to bootloader, we will try to advertise when in bootloader mode with Address + 1. This is explained at question I here.
The nRFToolbox app or the nRF Connect should be able to automatically detect this and connect to the +1 address. [UPDATE]This is wrong, nRFToolbox and nRFConnect now only look for same address not the +1 address.
the peer_data is the bonding information and central address that we pass from the application to the bootloader so that the phone can rebond when the bootloader is running. This is also explained in the FAQ linked above.
We call the current DFU "Legacy DFU" because of the new more secured DFU is coming in SDK v12 very soon. Unfortunately, it's not backward compatible.

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

seajayshore — Tue, 02 Aug 2016 15:28:05 GMT

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.

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

seajayshore — Tue, 02 Aug 2016 10:57:48 GMT

Hi, I was just about to ask a question about this same problem! Looks like it's maybe a recent nuisance??

I'm using SDK v10 (as my app is part mBed based) and I see the same problem.

Using nRF Toolbox I start a DFU upload and it hangs at "Enabling DFU bootloader...". I've found that if I then kill & re-launch the nRF Toolbox app and upload to the newly-advertising "DfuTarg" it uploads fine. I guess nRF Toolbox is storing some info on the old DFUService and getting confused when it updates to the DfuTarg version.

I can also successfully upload after having "manually" started the DFU process by writing a byte to the DFU Control Point (using the iOS app LightBlue Explorer) and then going to nRF Toolbox and uploading to the newly-advertised DFUTarg device...

@Ray I'll attempt to implement your fix and see if that works if I can

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

Ray — Tue, 02 Aug 2016 07:31:51 GMT

PROBLEM SOLVED - at least for me.

Simple description: In my app's ble_evt_dispatch(), I neglected to add a call to dm_ble_evt_handler() when I was inserting the DFU code. Here's the longer explanation:

void ble_evt_dispatch(ble_evt_t *p_ble_evt) {

// Make sure that we process DM events, else connections won't be registered with DM.  
// The most significant result of this is that DFU won't work; it won't leave an "Enabling..." state.                                   
// because the DM needs to be looked up.  Call stack:                                                                                   
// dfu_app_on_dfu_evt(), when evt_type == BLE_DFU_START                                                                                 
//  bootloader_start(p_dfu->conn_handle), which is valid                                                                                
//   dfu_app_peer_data_set(conn_handle), which is supposed to set peer_data                                                             
//    dm_handle_get(conn_handle, &m_dm_handle), ...                                                                                     
//      looks up handle in connection table associated with dm_                                                                         
// ...so where does it get put INTO this connection table?                                                                              
//  dm_ble_evt_handler(p_ble_evt) is supposed to be called by your own ble_evt_dispatch                                                 
//   BLE_GAP_EVT_CONNECTED adds it.                                                                                                     
// The bug was that I failed to have this call to dm_ble_evt_handler() in my ble_evt_dispatch.                                          

dm_ble_evt_handler(p_ble_evt);

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

Richard — Tue, 02 Aug 2016 05:28:53 GMT

This is my first time doing a DFU app also unfortunately.

This page in the docs covers the bonding setup though: infocenter.nordicsemi.com/index.jsp

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

Ray — Tue, 02 Aug 2016 04:56:45 GMT

That is truly fascinating. Let me explain something else that I've found, and perhaps you might have an explanation for this:

I got the most basic hrs app running with identical softdevice/bootloader/etc, and interestingly it got past the Enabling step and well into downloading - which gave me something to A/B test against.

What I found was that when using the hrs example, in dfu_transport_update_start() in dfu_transport_ble.c, the behavior was different between HRS and my app.

In HRS, the call to dfu_ble_peer_data_get() returns SUCCESS. The "peer_data" is apparently valid.

In my app, that call returns an error, and thus, as you say, it falls into the code that bumps the address by one.

I've never done a DFU app before, and so what I've been trying to do for the past hour or so is to figure out what this "peer data" is, and how it gets initialized.

Any further thoughts?

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

Ray — Tue, 02 Aug 2016 02:34:59 GMT

I have exactly this behavior also. It times out, and then resets/restores. Sigh.

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

Richard — Tue, 02 Aug 2016 02:24:12 GMT

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.

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

Ray — Tue, 02 Aug 2016 01:13:53 GMT

More info from xcode. If someone can spot something it would be appreciated. Basically, it is jumping just fine into the bootloader, and then the iOS app fails to reconnect to the peripheral. Of course, by the time it reconnects to the peripheral, there is a different service name (DfuTarg) and primary service UUID. Still trying to poke through the iOS code to see how it locates the peripheral under the now-different (1530) primary service UUID.

Aug  1 17:51:08 Rays-IPhone-6s nRF Toolbox[896] <Warning>: 1: Connecting to Teletype...
Aug  1 17:51:08 Rays-IPhone-6s nRF Toolbox[896] <Warning>: 0: centralManager.connectPeripheral(peripheral, options:nil)
Aug  1 17:51:09 Rays-IPhone-6s nRF Toolbox[896] <Warning>: 0: [Callback] Central Manager did connect peripheral
Aug  1 17:51:09 Rays-IPhone-6s nRF Toolbox[896] <Warning>: 5: Connected to Teletype
Aug  1 17:51:09 Rays-IPhone-6s nRF Toolbox[896] <Warning>: 1: Discovering services...
Aug  1 17:51:09 Rays-IPhone-6s nRF Toolbox[896] <Warning>: 0: periphera.discoverServices(nil)
Aug  1 17:51:10 Rays-IPhone-6s nRF Toolbox[896] <Warning>: 5: Services discovered
Aug  1 17:51:10 Rays-IPhone-6s nRF Toolbox[896] <Warning>: 1: DFU Service found
Aug  1 17:51:10 Rays-IPhone-6s nRF Toolbox[896] <Warning>: 1: Discovering characteristics in DFU Service...
Aug  1 17:51:10 Rays-IPhone-6s nRF Toolbox[896] <Warning>: 0: peripheral.discoverCharacteristics(nil, forService:DFUService)
Aug  1 17:51:10 Rays-IPhone-6s nRF Toolbox[896] <Warning>: 5: DFU characteristics discovered
Aug  1 17:51:10 Rays-IPhone-6s nRF Toolbox[896] <Warning>: 1: Reading DFU Version number...
Aug  1 17:51:10 Rays-IPhone-6s nRF Toolbox[896] <Warning>: 0: peripheral.readValueForCharacteristic(00001534-1212-EFDE-1523-785FEABCD123)
Aug  1 17:51:10 Rays-IPhone-6s nRF Toolbox[896] <Warning>: 5: Read Response received from 00001534-1212-EFDE-1523-785FEABCD123, value (0x):0100
Aug  1 17:51:10 Rays-IPhone-6s nRF Toolbox[896] <Warning>: 10: Version number read: 0.1
Aug  1 17:51:10 Rays-IPhone-6s nRF Toolbox[896] <Warning>: 1: Enabling notifiactions for 00001531-1212-EFDE-1523-785FEABCD123...
Aug  1 17:51:10 Rays-IPhone-6s nRF Toolbox[896] <Warning>: 0: peripheral.setNotifyValue(true, forCharacteristic: 00001531-1212-EFDE-1523-785FEABCD123)
Aug  1 17:51:11 Rays-IPhone-6s nRF Toolbox[896] <Warning>: 1: Notifications enabled for 00001534-1212-EFDE-1523-785FEABCD123
Aug  1 17:51:11 Rays-IPhone-6s nRF Toolbox[896] <Warning>: 10: DFU Control Point notifications enabled
Aug  1 17:51:11 Rays-IPhone-6s nRF Toolbox[896] <Warning>: 15: Application with buttonless update found
Aug  1 17:51:11 Rays-IPhone-6s nRF Toolbox[896] <Warning>: 1: Writing to characteristic 00001531-1212-EFDE-1523-785FEABCD123...
Aug  1 17:51:11 Rays-IPhone-6s nRF Toolbox[896] <Warning>: 0: peripheral.writeValue(0x0104, forCharacteristic: 00001531-1212-EFDE-1523-785FEABCD123, type: WithResponse)
Aug  1 17:51:11 Rays-IPhone-6s nRF Toolbox[896] <Warning>: 5: Data written to 00001531-1212-EFDE-1523-785FEABCD123
Aug  1 17:51:11 Rays-IPhone-6s nRF Toolbox[896] <Warning>: 10: Jump to bootloader (Op Code = 1, Upload Mode = 4) request sent
Aug  1 17:51:12 Rays-IPhone-6s nRF Toolbox[896] <Warning>: 0: [Callback] Central Manager did disconnect peripheral
Aug  1 17:51:12 Rays-IPhone-6s nRF Toolbox[896] <Warning>: 5: Disconnected by the remote device
Aug  1 17:51:12 Rays-IPhone-6s nRF Toolbox[896] <Warning>: 1: Connecting to Teletype...
Aug  1 17:51:12 Rays-IPhone-6s nRF Toolbox[896] <Warning>: 0: centralManager.connectPeripheral(peripheral, options:nil)