dfu removes bonds

[Carlos]

Hello,

I am using secure dfu with bonds (SDKv15.3, Segger, nrF52832), it works fine however after each dfu (application only) I lose the bond information.

I have search about it and found that there are several variables that can affect to it, I think I checked all of them but the problem still remains:

1-I use nRF Toolbox from Android phone and I enabled the "keep bonds" option on the settings. Can you btw tell me what is doing exactly this option and how is this setting is transfered to the secure dfu code to remove or not the bonds?

2-The sdk_config.h on the secure download has NRF_DFU_APP_DATA_AREA_SIZE set to 12288 (I think is correct to match FDS 3*4*1024)

3-FDS on the application side (based on heart rate example) has FDS_VIRTUAL_PAGES = 3, FDS_VIRTUAL_PAGE_SIZE = 1024, where I think stores the bonds.

According to comment on sdk_config.h it is same size as 12288:

// <i> The total amount of flash memory that is used by FDS amounts to @ref FDS_VIRTUAL_PAGES * @ref FDS_VIRTUAL_PAGE_SIZE * 4 bytes.

To me knowledge all seems to be fine, but .... why I after dfu the phone and board cannot connect?

To bypass the problem I remove bonds on the board and phone and connect them after each dfu, then everything seems to work fine... till the next dfu.

Thanks,

Carlos

[bjorn-spockeli]

HI Carlos,

I agree that the NRF_DFU_APP_DATA_AREA_SIZE  looks correct. 

Can you btw tell me what is doing exactly this option and how is this setting is transfered to the secure dfu code to remove or not the bonds?

The "keep bonds" in the nrf Toolbox app refers to the bonding information on the Android device. No bonding data is transferred to the nRF device by the nRF Toolbox app.

Could you try to use the nRF Connect app to perform the DFU instead of nRF Toolbox? Do you see the same behavior there?

If you do, could you capture a sniffer trace using our nRF Sniffer v2? It will make it easier to see which peer, i.e. the nRF or the Android, that does not have the correct bonding data.

Best regards

 Best regards

Bjørn 

[Carlos]

Hello again,

I found a similar case 

https://devzone.nordicsemi.com/f/nordic-q-a/36346/a-problem-on-buttonless-dfu-bonding-valid

The effect I have is same as described here, however I didn't change MTU size...

Anyway, do you know if this issues was fixed?

During the dfu I see this logs:

<info> app: ble_evt_handler 0x10
<info> app: Connected.
<info> app: ble_evt_handler 0x14
<info> peer_manager_handler: Connection secured: role: Peripheral, conn_handle: 0, procedure: Encryption
<info> app: ble_evt_handler 0x1A
<info> app: ble_evt_handler 0x50
<info> app: Received indication state 1
<info> app: ble_evt_handler 0x50
<info> app: Writing peer data to the bootloader...
<info> app: ble_evt_handler 0x51
<info> app: Device is preparing to enter bootloadï[info> app: Device is preparing to enter bootloader mode.
<info> app: Disconnected 1 links.
<info> app: ble_evt_handler 0x53
<info> app: Device will enter bootloader mode.
<info> pwr_mgmt: Shutdown request 2
<info> pwr_mgmt: Shutdown started. Type 2
<info> app: Power management wants to reset to DFU mode.
<info> app: Power management allowed to reset to DFU mode.
<info> pwr_mgmt: SysOff handler 0x0002C401 => ready
<info> pwr_mgmt: Shutdown complete.
<info> pwr_mgmt: NVIC_SystemReset

When I connect same phone after dfu I see this logs I print event on evt_handler(this should correspond to the sniffer I sent you):

<info> app: ble_evt_handler 0x10
<info> app: Connected.
<info> app: ble_evt_handler 0x54
<info> app: ble_evt_handler 0x14
<info> peer_manager_handler: Connection secured: role: Peripheral, conn_handle: 0, procedure: Encryption
<info> app: ble_evt_handler 0x1A
<info> app: ble_evt_handler 0x12

Could you look at the sniffer log?

After that only works if I delete bond on both nrf and phone...

Thanks,

Carlos

[bjorn-spockeli]

Hi Carlos, 

Looking at the sniffer trace and the last connection I cannot see anything wrong with regards to the reencryption using the bonding data( i.e. stored encryption key). The link layer packets(i.e. LL_ENC_REQ/RSP, LL_START_ENC_REQ/RSP) are all send in the correct order and the parameters look good.

So the bonding data must be preserved during the DFU otherwise you should have gotten a LL_REJECT_IND or LL_REJECT_EXT_IND packet in return. 

The sniffer trace does not show any LL activity nor ATT activity after the link is encrypted. If the nRF device was bonded with the Android device, then it should have cached the GATT table of the application. However, it could be that you simply have to update the GATT attribute 

Does the DFU update increase or modify the GATT table of the application compared to the application that was replaced? OItherwise,the GATT attribute table handles should be the same as before the DFU. 

Can you check if the NRF_SDH_BLE_SERVICE_CHANGED define in sdk_config.h is set in the bootloader project? Could you also check if this is set in the applicaiton as well?

We do have a "refresh device cache" feature in nRF Connect. Connect to the device, then press the three vertical dots in the upper-right corner and then press "Refresh device cache". Does the Android device perform a new service discovery and display the services and characteristics after doing this?

Best regards

Bjørn

[Carlos]

Thank you Bjorn,

regarding you questions;

>>Does the DFU update increase or modify the GATT table of the application compared to the application >>that was replaced? OItherwise,the GATT attribute table handles should be the same as before the >>DFU. 

No, application is exactly same before and after because dfu, after compile I generate hex and app_package. I write hex files in the board and then I update app to the same version, so no change in the application.

>>Can you check if the NRF_SDH_BLE_SERVICE_CHANGED define in sdk_config.h is set in the >>bootloader project? Could you also check if this is set in the applicaiton as well?

Yes, it is defined on both application and bootloader.

>>We do have a "refresh device cache" feature in nRF Connect. Connect to the device, then press the >>three vertical dots in the upper-right corner and then press "Refresh device cache". Does the Android >>device perform a new service discovery and display the services and characteristics after doing this?

And here comes the good news, by doing 'refresh services' when fRF is connected or 'refresh device cache' when it is disconnected and the connect it all services appear again and it work normally.

The option name in nRF Connect changes when it is connected or disconnected but it seems to have same effect.

Can you please tell me a bit more about this option and how would it be possible to make it work without the user need to do this refresh?

Is this expected behavior or is it due to I miss something in my code?

Thank you!!

[Carlos]

Regarding my last question below:

"Can you please tell me a bit more...

...

Is this expected behavior or is it due to I miss something in my code?"

Is is there any advice?

thks

[bjorn-spockeli]

If NRF_SDH_BLE_SERVICE_CHANGED is set to 1 in both the bootloader and application, then the bootloader should issue a Service Changed notification. 

Did you compile the bootloader with NRF_DFU_BLE_REQUIRES_BONDS set to 1 in the bootloader's sdk_config.h file and did you compile your application with NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS set to 1 in the application's sdk_config.h file? 

Best regards

Bjørn

[Carlos]

Thank you Bjorn

Since its been a long time and if you only read the last question I guess you may lose the background I made a short summary.

The DFU with bonds is working fine, so yes NRF_DFU_BLE_REQUIRES_BONDS and NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS are set to 1.

Regarding NRF_SDH_BLE_SERVICE_CHANGED, yes it is set to 1 in both, as I already wrote above.

And also I provided you full logs and traces.

So the issue is why service cache refresh is needed?

I guess it may be related to Android as states in what I think is a similar issue:

https://devzone.nordicsemi.com/f/nordic-q-a/39184/refreshing-cached-services-on-bonded-peer-after-dfu

Can you please confirm it is same? And do you have any news about how to fix it or if Google will fix it (if I understood well it seems an Android issue)?

Thank you,

[bjorn-spockeli]

HI Carlos, 

I apologize for the late reply. I have been on vacation. 

I took another look at the sniffer trace you attached in case 229977 (https://devzone.nordicsemi.com/support-private/support/229977) and I see that after the DFU completes the nRF device is issuing a Service Changed notification that is confirmed by the central. So the GATT table on the phone should be up to date at that point. 

The issue in in case 39184 was related to HID reports not being available to a custom application due to these being controlled by the Android Settings App. are you using HID in your application?

[Carlos]

Thank you Bjorn,

Do you mean that this is a phone issue? I checked several Android phones and all have same issue.

If this is the case, it should happen to everybody using DFU with bonds, do you have any other claim about it?

Regading HID, I am not sure about the meaning, but I guess no, I am usin Nordic Android App nRF Toolbox / nRf Connect.

Regards,

[bjorn-spockeli]

If the nRF device has issued a Service Changed Indication and the Android device is not performing a new Service Discovery then Yes I would say it is a phone issue. No, not really, the Android DFU library which is used by nRF Connect  will try to refresh the cache if it cannot find the DFU service at the location it expects it to be in the GATT table.