Losing Bonding and FDS info on DFU

RE: Losing Bonding and FDS info on DFU

Randy Lee — Mon, 06 Dec 2021 22:51:11 GMT

After some experiments, it looks like this is what's going on here.... I've put this code in and I think it's working correctly from here..

RE: Losing Bonding and FDS info on DFU

Randy Lee — Mon, 06 Dec 2021 19:40:32 GMT

One of the errors I had, I did a search on and came up with something you've answered before to some extent.. https://devzone.nordicsemi.com/f/nordic-q-a/38663/keep-getting-failed-to-secure-connection-error/156832#156832

I already had some cod in there to prevent this but changed it to

pm_conn_sec_config_t conn_sec_config = { .allow_repairing = true };

And I can now run commands from my App against this thing (albeit with an Android request for pairing).

I'm going to follow that thread a bit more...

RE: Losing Bonding and FDS info on DFU

Randy Lee — Mon, 06 Dec 2021 17:24:59 GMT

Experiment this morning:

* flashed with prior version of the code using Segger jlink lite.
* Connected up the app (Android app on a Samsung tablet) and bound the device (so now I should have bonding information to this tablet).
* Drop the app
* Use nRFconnect to kick into bootloader mode
* Us nRFconnect to do DFU to Current version of the code
* Connect back up with JLink RTT viewer

nRFconnect was asking to pair, so paired (twice)

Got (these are [mostly] my internal debug statements printing things but some of these are Nordic debug statements:

00> [1638809628.058] Reboot into bootloader in 1 sec...
00> [3624999905.013] POR Vbat: (3.00V)
00> <debug> nrf_sdh_freertos: Creating a SoftDevice task.
00> <debug> ble_scan: Adding filter on RWStudentID name
00> <info> app: USB power detected
00> <debug> nrf_sdh_freertos: Enter softdevice_task.
00> [3624999905.266] Whitelist: File found
00> [3624999905.266] Whitelist: File read successfully
00> [3624999905.266] Whitelist: Whitelist file found. peer_id=0
00> [3624999905.267] Whitelist: File found. Writing data into it
00> [3624999905.267] Whitelist: Write succeeded.
00> <info> app: USB ready
00> [1630337702.317] temperature: 22.0C
00> [1630337702.317] Vbat: 100% (3.41V)

* Bring App back up

The App is showing stuff coming from the device but attempting to connect and send a command is showing (on Segger RTT viewer):

00> [1630338002.415] Vbat: 100% (3.39V)
00> <warning> peer_manager_gcm: The local database has changed, so some subscriptions to notifications and indications could not be restored for conn_handle 0
00> <warning> peer_manager_handler: Local DB could not be applied: conn_handle: 0, peer_id: 0
00> <debug> nrf_ble_gatt: Requesting to update ATT MTU to 247 bytes on connection 0x0.
00> [1630338050.927] BLE: Peer connected
00> [1630338051.061] BLE: Allow repairing: 0
00> <info> peer_manager_handler: Connection security failed: role: Peripheral, conn_handle: 0x0, procedure: Bonding, error: 133
00> <warning> peer_manager_handler: Disconnecting conn_handle 0.
00> <debug> nrf_ble_gatt: ATT MTU updated to 247 bytes on connection 0x0 (response).
00> [1630338051.151] BLE: Data len is set to 0xF4(244)
00> <debug> nrf_ble_gatt: Peer on connection 0x0 requested a data length of 251 bytes.
00> <debug> nrf_ble_gatt: Updating data length to 27 on connection 0x0.
00> <error> nrf_ble_gatt: sd_ble_gap_data_length_update() (request) on connection 0x0 returned NRF_ERROR_INVALID_STATE.
00> [1630338051.012] POR Vbat: (3.35V) [<- my log indicating reset path]
00> <debug> nrf_sdh_freertos: Creating a SoftDevice task.
00> <debug> ble_scan: Adding filter on RWStudentID name
00> <info> app: USB power detected
00> <debug> nrf_sdh_freertos: Enter softdevice_task.
00> [1630338051.250] Whitelist: File found
00> [1630338051.250] Whitelist: File read successfully
00> [1630338051.250] Whitelist: Whitelist file found. peer_id=0
00> [1630338051.251] Whitelist: File found. Writing data into it
00> [1630338051.251] Whitelist: Write succeeded.
00> [1630338051.256] Device service: Version=0.8.4.2, Family=90, ProgramChecksum=2213D3E4
00> [1630338051.259] Whitelist: File found
00> [1630338051.259] Whitelist: File read successfully
00> [1630338051.259] BLE: Whitelist contains a peer. Start advertising.
00> [1630338051.259] Whitelist: Applied whitelist with addr_cnt=1 irk_cnt=1
00> [1630338051.264] temperature: 23.0C
00> [1630338051.264] Vbat: 100% (3.45V)
00> [1630338051.270] LOG: 221,18,0x00,0x00
00> <info> app: USB ready
00> [1630337462.277] POR [<- my log indicating reset path]

There appears to be several places where I'm overrunning the output buffers here, but the interesting thing to note here is extra POR events that shouldn't be there.

This has something or other to do with the DFU, but not at all clear to me what...

RE: Losing Bonding and FDS info on DFU

Randy Lee — Mon, 06 Dec 2021 17:13:42 GMT

This is plenty complex behaviour so let me note what I've done here.... Not sure I understand what's going on exactly.. First off, I've attached the dump you've requested. Then let me explain what I did...devzone.nordicsemi.com/.../3264.flash.txt

RE: Losing Bonding and FDS info on DFU

Randy Lee — Fri, 03 Dec 2021 13:49:46 GMT

I don't think it's failing.... Looking at the code, it should hang if it does and I'm not seeing hangs. I'll have to verify that when next I can run a debugger there but I'm pretty sure it isn't.

RE: Losing Bonding and FDS info on DFU

Vidar Berg — Fri, 03 Dec 2021 13:42:57 GMT

The peer manager should only delete bonding information when the application explitely requests it through pm_peer_data_delete()/pm_peers_delete(), or if you have run out of FDS space and call pm_handler_flash_clean()/pm_handler_flash_clean_on_return().

I initally assumed that pm_init() failed after DFU because that's usally what happens if the bootloader has corrupted the filesystem. Is that not what happens in your case?

RE: Losing Bonding and FDS info on DFU

Randy Lee — Fri, 03 Dec 2021 13:25:55 GMT

Theory: Because the bootloader isn't requiring bonding, the peer manager is deleting what bonding info it has here so when my application comes back online, there is no bonding info saved. Is it possible that the bootloader isn't erasing the are but that other things are deleting what's there because it doesn't need it?

RE: Losing Bonding and FDS info on DFU

Randy Lee — Fri, 03 Dec 2021 13:14:24 GMT

no need. none of that data is proprietary... Or even interesting to anything but Nordic code.

RE: Losing Bonding and FDS info on DFU

Vidar Berg — Fri, 03 Dec 2021 13:07:46 GMT

You too, thanks. Do you want me to make the ticket private in the meantime?

RE: Losing Bonding and FDS info on DFU

Randy Lee — Fri, 03 Dec 2021 13:06:21 GMT

Yah, I can do that... It'll probably be Monday before I can get it tho so hang tight. Have a good weekend..

RE: Losing Bonding and FDS info on DFU

Vidar Berg — Fri, 03 Dec 2021 13:01:41 GMT

Thanks for confirming. So it must be something else then. Are you able to share a dump of the flash content here or in a private ticket so I can take a look?

Reading flash with nrfjprog

> nrfjprog --memrd 0x0 --n 0x100000 > flash.txt

RE: Losing Bonding and FDS info on DFU

Randy Lee — Fri, 03 Dec 2021 12:54:42 GMT

yes, This is set in the sdk_config.h file for the bootloader:

#define NRF_DFU_APP_DATA_AREA_SIZE 12288

the SDK file nrf_dfu_types.h has:

#define NRF_DFU_APP_DATA_AREA_SIZE (CODE_PAGE_SIZE * 3)

RE: Losing Bonding and FDS info on DFU

Vidar Berg — Fri, 03 Dec 2021 12:50:07 GMT

Hello,

The bootloader should not be able to write into the application data as long as the NRF_DFU_APP_DATA_AREA_SIZE setting in your bootloader's sdk_config file corresponds to the size of your FDS area allocated by the app. So please double-check that NRF_DFU_APP_DATA_AREA_SIZE is indeed set to 12288 in your bootloader project.

I see you mentioned using the DFU_APP_DATA_RESERVED define, but please note that this symbol was renamed to NRF_DFU_APP_DATA_AREA_SIZE in this SDK version.

Best regards,

Vidar