Buttonless DFU with bonding

[Dani]

Good afternoon,

I first devoloped my app based on the nRF52840 (SDK 15.2; S140 V.6.1.0) and it was perfectly working with or without bonds.

After that, and following what it is shown in this link (https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/getting-started-with-nordics-secure-dfu-bootloader), I implemented Buttonless DFU funcntionality without bonds, and it was working fine. Now, I have tried to go ahead and doing the same DFU process with bonds, but application gets stuck when initializing DFU service: it gets stopped at 'ble_dfu_buttonless_init' function, when calling 'ble_dfu_buttonless_backend_init', and the result is 0x0008 (NRF_ERROR_INVALID_STATE). In order to test DFU with bonds, I have carried out the required modifications according to information specified in the link above:

Do you know which can be the reason of such error?

Best regards,

Dani.

[Dani]

Now, the application is working but when carrying out DFU process, it does not work --> when using 'nRF Connect' desktop application, I get the following message:

Any suggestion?

Best regards,

Dani

[Dani]

I found I was getting this message because device was in debug mode. Now, it is not in debug mode but I'm getting a different message:

Trying to guess which is the problem....

[Einar Thorsrud]

Hi Dani,

What we have discussed in the last days should hopefully solve this part of the problem:

But I have more information: up to now I was doing all the tests with the LG K4 (Android 6.0.1). I have just tested the same process with a Xiami Mi6 and now the DFU process is perfectly working. But...

What does it happen with bonding after application update? After DFU, an as it should be, my module is reseted and starts working again but, when I try to connect again with it with BLE (using the same app I normally use), it is not possible to succeed. In order to correctly connect again with it, I have to erase bonding information from the Smartphone, and then everything works. How can I manage bonding in order to avoid this situation to happen after DFU?

But not this part:

I have also tried to check behavior with 'nRF Connect' tool after this succesful DFU process: as the device is already bonded, it appears in bonded list, and when I try to connect, I only am able to see the characteristics related to DFU service (but device is not working in DFU mode, as apart of BLE connection, it is perfectly working).

..which is the same you see now. As I understand, you have verified that the device is in the application and not in the bootloader? But you only see the DFU service on the phone, and not any of the services in your application? If so, the problem is that the phone have not done a service discovery, which it should have done automatically if you use service changed properly. Is that enabled in both the application and bootloader?

Einar

[Dani]

Hi Eimar,

You said..

As I understand, you have verified that the device is in the application and not in the bootloader?

Yes, as the device is perfectly working in what regards functionality.

You said..

But you only see the DFU service on the phone, and not any of the services in your application?

Yes, after DFU is performed, device works perfectly but I only see DFU service.

You said...

 If so, the problem is that the phone have not done a service discovery, which it should have done automatically if you use service changed properly. Is that enabled in both the application and bootloader?

Yes. I have set NRF_SDH_BLE_SERVICE_CHANGED to 1 in both application and bootloader.

So, how can we go ahead?

All the best,

Dani.

[Einar Thorsrud]

Hi Dani,

Dani said:

So, how can we go ahead?

Summing up:

• The remaining issue is that you only see the DFU service after entering the application after a DFU upgrade.
• You have verified that the application and not bootloader is running.

If the application is running and you know it has other BLE services but these are not shown on the central side, this must be because the central has not done service discovery, which it should have if you have service changed. Can you try to call pm_local_database_has_changed() in your application? If you do not have any progress it would be good if you could upload your completed application project and bootloader project so that I can see (you can upload it in a private case if you don't want it public).

Einar

[Dani]

Hi Einar,

In my application, at which point should I call 'pm_local_database_has_changed'?

Regards,

Dani

[Einar Thorsrud]

Hi dani,

You can for instance call pm_local_database_has_changed() when you get the PM_EVT_BONDED_PEER_CONNECTED event, but the timing is not critical since it is buffered ant sent when the peer connects if called "too" early. See API doc for pm_local_database_has_changed() for details.

(Ideally, you should only call pm_local_database_has_changed() the first time the bonded peer connects after a DFU, though the only consequence of calling every time is that the center will perform service discovery every time, which may not be a problem). 

[Dani]

Hi Einar,

I have implemented what you have suggested:

/**@brief Function for handling Peer Manager events.
 *
 * @param[in] p_evt  Peer Manager event.
 */
static void pm_evt_handler(pm_evt_t const * p_evt)
{
    pm_conn_sec_config_t config;
	
	pm_handler_on_pm_evt(p_evt);
    pm_handler_flash_clean(p_evt);

    switch (p_evt->evt_id)
    {
        case PM_EVT_PEERS_DELETE_SUCCEEDED:
            advertising_start();
            break;
				
		case PM_EVT_CONN_SEC_CONFIG_REQ:
			config.allow_repairing = true;
			pm_conn_sec_config_reply(p_evt->conn_handle, &config);
			break;
				
		case PM_EVT_BONDED_PEER_CONNECTED:
			pm_local_database_has_changed();
			break;

        default:
            break;
    }
}

And the result is the same.

I'm using SDK 15.2.0. I do not know if there is any issue related with this and with also what is commented in this thread (https://devzone.nordicsemi.com/f/nordic-q-a/46633/peer-manager-silently-drop-service-changed-indications-if-an-att-mtu-exchange-was-happening/204968#204968)

Best regards,

Dani

[Einar Thorsrud]

Hi Dani,

I did not remember that issue, but yes, this could very well be the problem. You can check if the same thing happens in your case using a sniffer, or simply implement the fix as suggested by Vidar in that thread (which you should do anyway).

With the that fixed I cannot think of any likely reasons for this issue, but if you are still stuck, there are a few things worth doing:

• Could it be that the phone has cached the services form before you added service changed characteristic to both the bootloader and application (if ever)? If so, then you should remove the bonding information and toggle BLE off and on on the phone to clear it's cache. Then fully erase the nRF and program the bootloader and application again. In this case, the phone should be aware of the issue
• If still not sure if the phone could have cached something from before service changed characteristic was added, you could change the MAC address of the nRF (remember to do so both in app and bootloader in that case), or simply test with a new phone.
• If the above also doe snot work, then it would be useful with a sniffer trace to see what is actually happening on-air (is the service change indication sent, ...?)

Einar

[Dani]

Hi Einar,

Some new information for you:

Before implementing fix suggested by Vidar, I have directly gone to first point you have suggested in last answer: now, nRFToolbox is crashing but I have succeeded with nRF Connect application. After DFU update, the situation was the same (only DFU services were observed) but after selecting and connecting again to the bonded device, all application services appear again after going to options and selecting 'Refresh Services'.

Dani.

[Einar Thorsrud]

Hi Dani,

Dani said:

Before implementing fix suggested by Vidar, I have directly gone to first point you have suggested in last answer: now, nRFToolbox is crashing but I have succeeded with nRF Connect application. After DFU update, the situation was the same (only DFU services were observed) but after selecting and connecting again to the bonded device, all application services appear again after going to options and selecting 'Refresh Services'.

That is good. It is expected that the phone can discover all the services when you tell it to do service discovery. The problem is that this should have been automatic when you issue a service changed. What happens if you do DFU again at this point, but not "manually" select refresh service when entering the application again. Do the application's services appear then, or is it back to the old behavior?

[Dani]

Hi Einar,

Is the same: DFU works correctly but if I do not select a 'manual refresh', I'm back to same situation: only DFU services are shown.

Dani