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

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