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

[Dani]

Hi Einar,

First of all, thank you so much for your answers.

First, I think that I was a bit confused with FDS and fstorage.

Now, I use NRF_FSTORAGE_DEF in my application in the way I sent you. Do I need to do this? Do I need to define this boundaries?

In fact, what I really want is:

- To have 4 pages (or more) in order to preserve my application data: here I have already implemented this in order to write and read equipment parameters using functions as: nrf_fstorage_erase, nrf_fstorage_write, nrf_fstorage_read,...

- To have enough space to save bonding information allowing the device to save bonding information for several devices to which my device is able to connect to. How can I determine how much space is required for a bonding set? How can I know the number of connections (bondings) that can be saved?

Taking into account this information, which implementation do you reccommend me to follow in my application?

Best regards,

Dani.

[Einar Thorsrud]

Hi Dani,

If you have not considered it, you can store other application data using FDS as well. If you do, you do not need to touch any fstorage API. In many cases, FDS is a better choice, but not always. It depends on what you are doing. But it is key to understand what you are doing, so that the memory layout makes sense and there is no overlapping, and that the bootloader is configured accordingly.

A bond is typically about 104 bytes (26 words), but it can vary a bit. So you can fit quite a few bonds per flash page.

[Dani]

Hi Einar,

As described by you, I have done the following settings:

Aplication:

• FDS_VIRTUAL_PAGES 6 (bonding info, garbage,...)
• Flash (Data):
  • //Preserved data blocks address:
  • #define FLASH_ADR_FINAL_FLASH (u32) 0x000f2000
  • #define FLASH_ADR_INI_PAGE_1 (u32)(FLASH_ADR_FINAL_FLASH-0x1000)
  • #define FLASH_ADR_INI_PAGE_2 (u32)(FLASH_ADR_INI_PAGE_1-0x1000)
  • #define FLASH_ADR_INI_PAGE_3 (u32)(FLASH_ADR_INI_PAGE_2-0x1000)
  • #define FLASH_ADR_INI_PAGE_4 (u32)(FLASH_ADR_INI_PAGE_3-0x1000)
• NRF_FSTORAGE_DEF:
  • .start_addr = FLASH_ADR_INI_PAGE_4
  • .end_addr = FLASH_ADR_FINAL_FLASH

Bootloader:

• NRF_DFU_APP_DATA_AREA_SIZE 40960 (10 pages: 6 VIRTUAL + 4 data)

I use fstorage API (as before) in order to manage data writing and reading (preserved data)

DFU process is succesful, but after this, the problem is the same: when I try to connect again with same device (already bonded in my smartphone), it connects but services that are shown belong to DFU service:

Only if I desynchronize device in my smartphone and pair/bond it again is when I can normally connect again.

So, which is the problem? Have I been wrong?

Best regards,

Dani.

[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