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.

[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