first secure connection after DFU fails. SDK17 S113

RE: first secure connection after DFU fails. SDK17 S113

Allen — Fri, 12 Feb 2021 18:37:23 GMT

FDS_VIRTUAL_PAGES did not have the same configuration for the boot loader and the application. This difference was the root of this issue.

RE: first secure connection after DFU fails. SDK17 S113

Einar Thorsrud — Thu, 12 Nov 2020 08:35:23 GMT

Hi,

[quote user="ajcurtis"]

1. Reducing FDS_VIRTUAL_PAGES causes peer_manager initialization to fail.

It is unclear to me the relationship between virtual pages and physical pages. It sounds like they are independent. (it is state above that it may grow) On the other hand it appears from the source code that they number of physical pages is directly related to the number of virtual pages.

[/quote]

This issue is not related to the size of the virtual pages, as they anyway need to be a multiple of the physical pages (in practice you typically configure it so that a virtual page is the same as a physical page). (Also, reducing the number of pages can cause fds initialization and thus peer manager initialization to fail. If it actually does not not depends on if the swap page was removed or not. If only data page(s) were deleted, you would "just" lose data.).

Just as a side note it is unlikely that the virtual page size is different than the virtual page size. It does not make sense for most application, as that would waste mor flash on the swap page. And the only benefit would be to support very large records.

[quote user="ajcurtis"]

2. The proposed solution is to erase the pages prior to peer manager initialization.

The peer manager is not part of our application. It is part of the SDK. How do we know what pages to erase? peer_data_storage.h defines PDS_FIRST_RESERVED_RECORD_KEY and PDS_LAST_RESERVED_RECORD_KEY. Do we find the ID for all keys in this range and delete them?

[/quote]

You know that the FDS pages are immediately below the bootloader, counting downwards as many pages as you have configured in your sdk_config.h. You cannot know at which page data is contained, regardless of if it is stored by the peer_manager or another user, as data will be shifted around during the life cycle of a device as it performs garbage collection without searching for FDS records (like FDS itself does).

If you don't need to keep the data, then you can simply delete all FDS pages blindly. If not, then you can search for the data and temporarily store them somewhere else. That would be up to you though. You would not be able to use FDS directly if it cannot be initialized, but you could use code from the FDS implementation. I do not know enough about your use case and requirements to say if this is sensible or not, though.

[quote user="ajcurtis"]3. pm_init() calls pds_init() which calls fds_init(). To erase the peer manager information we would need to fds_init() first. It looks like this will be fine. Just verifying.[/quote]

Yes. FDS is intended to support multiple "users" and it is perfectly legal to initialize it more than once (it will simply return NRF_SUCCESS and trigger the event indicating it is initialized again for any subsequent calls to fds_init()).

[quote user="ajcurtis"]4. Is there a generic way to determine how FDS_VIRTUAL_PAGES was previously configured? It appears that this macro is used to calculate the number of physical pages. Is is possible to read the FDS pages and determine the end and therefore the previous value of FDS_VIRTUAL_PAGES?[/quote]

Yes, that should be possible. During initialization FDS will tag all pages with an FDS page header. So if you don't know how many pages the previous firmware configured you can search through all pages. If the first word is 0xDEADC0DE (FDS_PAGE_TAG_MAGIC) and the second tag is either 0xF11E01FF (FDS_PAGE_TAG_SWAP) or 0xF11E01FE (FDS_PAGE_TAG_DATA), then the page is an FDS page (at least FDS will consider it as one). So if you search downwards from just below the bootloader, and count the number of times you find this pattern you will know the virtual page count.

[quote user="ajcurtis"]

5. Where are these pages located? How does the number of FDS pages affect soft device flash size, application flash size or flash available for dual boot DFU operation?

Currently our application only supports dual boot DFU mode. The remaining flash for application growth is becoming an issue.

[/quote]

FDS pages are always located immediately below the bootloader (or at the very end of the flash if a bootloader is not present).

RE: first secure connection after DFU fails. SDK17 S113

Allen — Wed, 11 Nov 2020 23:03:13 GMT

This is all very interesting. Let me try to bring this down to my reality.

1. Reducing FDS_VIRTUAL_PAGES causes peer_manager initialization to fail.

2. The proposed solution is to erase the pages prior to peer manager initialization.

3. pm_init() calls pds_init() which calls fds_init(). To erase the peer manager information we would need to fds_init() first. It looks like this will be fine. Just verifying.

4. Is there a generic way to determine how FDS_VIRTUAL_PAGES was previously configured? It appears that this macro is used to calculate the number of physical pages. Is is possible to read the FDS pages and determine the end and therefore the previous value of FDS_VIRTUAL_PAGES?

5. Where are these pages located? How does the number of FDS pages affect soft device flash size, application flash size or flash available for dual boot DFU operation?

Currently our application only supports dual boot DFU mode. The remaining flash for application growth is becoming an issue.

RE: first secure connection after DFU fails. SDK17 S113

Einar Thorsrud — Wed, 11 Nov 2020 11:44:47 GMT

[quote user="mrono"]If the pages aren't empty how does the application know it is safe to erase them?[/quote]

Except for the bootloader when it is doing a dual bank update, the only thing that can write to the flash is the application that you (who is developing it) is responsible for. So you need to know the flash layout, and as you make the application you need to let the application "know" whatever it needs to know. That is basically it. In other words: If you never use a flash page for anything (directly or indirectly via FDS or something else), then you know it is safe to erase. And you decide what your applications "knows" as you write it.

RE: first secure connection after DFU fails. SDK17 S113

mrono — Wed, 11 Nov 2020 11:31:34 GMT

Thank you.

Just to clarify further: Assuming a 'typical' nRF52 flash layout. Nordic's secure Bootloader, FDS, softdevice and application. No extra flash sections, no other writers to flash than bootloder and FDS. FDS never shrinks, only grows.

So assuming these conditions, is it possible that we end up in a situation where FDS can't grow? The scenario I described above occurred to me as a possibility, but I'm not even sure if the bootloader leaves stuff into bank 1 after copying it to bank 0.

Because if there is a need to increase the size of FDS then there is a need to use those pages as well. So this:

[quote userid="7377" url="~/f/nordic-q-a/66754/first-secure-connection-after-dfu-fails-sdk17-s113/279462#279462"]you would have to delete the new flash page(s) before you initialize FDS.[/quote]

.. is a bit difficult for the application. If the pages aren't empty how does the application know it is safe to erase them?

RE: first secure connection after DFU fails. SDK17 S113

Einar Thorsrud — Wed, 11 Nov 2020 11:08:11 GMT

Hi,

I was not clear enough in my previous post.

[quote user="mrono"]So are you saying that even if one has always reserved the correct amount of pages in both the bootloader and application, and never reduced the number of pages, that increasing the number of pages is still not necessarily safe?[/quote]

No, increasing the amount of pages is safe. But you may not be able to actually use the new page(s) for anything useful unless you make sure it is erased before FDS is initialized. That is because FDS will stay away from pages that do not have the FDS page tag but have other content. So it will simply not be used by FDS. But again: this is only if the additional flash pages are not erased (contain other than FF...).

[quote user="mrono"]

I guess the problematic scenario is a case where at some point the application size is just right to completely fill the empty flash using a dual bank update. The next updates are still successful even if size increases, as the update switches to a single bank. But now stale code is left in the last pages that would be used if the FDS needs to grow?

Am I on the right track here? And the only solution is that the application deletes a page in flash that is not empty but supposedly unused?

[/quote]

Yes. In this case you would have to delete the new flash page(s) before you initialize FDS. So the logic to do that should be part of the new app you are updating to (which use more FDS pages).

[quote user="mrono"]Is there a way for the application to know if the page is truly unused, or if it is part of the application itself (ie the flash is truly full)?[/quote]

You will know the size of the app when you build it, but I do not think the app can automatically know that an area is truly unused (perhaps you have some code there that writes to some flash above the end address of the app etc?). But you can know, so that should be OK. As long as you have control of the memory map of your application, you should be good and have the information you need.

Another approach here is to modify the FDS implementation so that it would not care if a page is empty or not, but simply erase it if it does not have the FDS page tag but is part of the reserved pages.

RE: first secure connection after DFU fails. SDK17 S113

mrono — Wed, 11 Nov 2020 10:19:32 GMT

I'm not the original poster (sorry Allen for this sidetrack), but this latest reply seems to have a major impact so I'd like to ask for clarification.

[quote userid="7377" url="~/f/nordic-q-a/66754/first-secure-connection-after-dfu-fails-sdk17-s113/279419#279419"]So the only way to get a predictable and consistent behavior when updating an existing product via DFU while changing the number of FDS pages is to delete all those pages before you initialize FDS. In that case all data will be lost, but FDS will initializes the empty pages and you will be good to go.[/quote][quote userid="7377" url="~/f/nordic-q-a/66754/first-secure-connection-after-dfu-fails-sdk17-s113/279419#279419"]1. If you add an additional FDS page, this may or may not be empty. If the page is empty, it will be initialized by FDS and used. If it is not empty, it will not be used (see line 706-711 in fds.c in SDK 17.0.2.[/quote]

So are you saying that even if one has always reserved the correct amount of pages in both the bootloader and application, and never reduced the number of pages, that increasing the number of pages is still not necessarily safe?

Am I on the right track here? And the only solution is that the application deletes a page in flash that is not empty but supposedly unused? Is there a way for the application to know if the page is truly unused, or if it is part of the application itself (ie the flash is truly full)?

RE: first secure connection after DFU fails. SDK17 S113

Einar Thorsrud — Wed, 11 Nov 2020 08:34:05 GMT

Hi,

Changing the number of FDS pages through DFU does not work out of the box. Basically, there are two different scenarios:

1. If you add an additional FDS page, this may or may not be empty. If the page is empty, it will be initialized by FDS and used. If it is not empty, it will not be used (see line 706-711 in fds.c in SDK 17.0.2.

2. If you remove FDS pages, then you may remove data and/or swap pages (those shift around after every garbage collection so you can never know). If you remove data page(s), you risk loosing data such as bonding information. If only data pages are deleted, you "just" loose data. If the swap page is removed, fds_init() will return the FDS_ERR_NO_PAGES error.

So the only way to get a predictable and consistent behavior when updating an existing product via DFU while changing the number of FDS pages is to delete all those pages before you initialize FDS. In that case all data will be lost, but FDS will initializes the empty pages and you will be good to go.

RE: first secure connection after DFU fails. SDK17 S113

Allen — Tue, 10 Nov 2020 17:26:29 GMT

There is one additional twist to this problem.

I have verified that the reset issue is due to a mismatch between the the reserved flash size.

when the size of FDS_VIRTUAL_PAGES is increased, the first attempt to make a BLE connection causes a reset. However it recovered with the next boot.
when the size of FDS_VIRTUAL_PAGES is decreased, the device goes into a reset loop where pm_init() returns NRF_INTERNAL_ERROR.

Is there a way to correct this problem? It appears the bonds need to be deleted before the peer manager is initialized to work.

RE: first secure connection after DFU fails. SDK17 S113

Allen — Wed, 14 Oct 2020 00:50:03 GMT

dfu_data_types.h has this code which confused me. The constant 3 should actually be number of pages or something to make it clearer.

#ifndef NRF_DFU_APP_DATA_AREA_SIZE
#define NRF_DFU_APP_DATA_AREA_SIZE (CODE_PAGE_SIZE * 3)
#endif

--------------------------------------------------------------------------------------------------

Changing the number of FDS_VIRTUAL_PAGES pages to 3, to match the bootloader NRF_DFU_APP_DATA_AREA_SIZE 12288, did resolve the problem!

Thank you for the help!

RE: first secure connection after DFU fails. SDK17 S113

Einar Thorsrud — Mon, 12 Oct 2020 16:18:18 GMT

Hi,

Then this cold be the problem. NRF_DFU_APP_DATA_AREA_SIZE is in bytes, and each flash page is 1024 words = 4096 bytes (this is where the 4 comes from in your calculation, and 3 is the number of pages). Your value of 12288 matches 3 FDS pages, not 4.

RE: first secure connection after DFU fails. SDK17 S113

Allen — Mon, 12 Oct 2020 16:11:52 GMT

Application sdk_config.h
#define FDS_VIRTUAL_PAGES 4

Bootloader sdk_config.h

#define NRF_DFU_APP_DATA_AREA_SIZE 12288

This is the current configuration. I believe they match. 1024 page size * 4 num pages * 3 = 12288?

Not sure why it is x3

RE: first secure connection after DFU fails. SDK17 S113

Allen — Mon, 12 Oct 2020 16:04:05 GMT

Einar,

I believe you hit on the issue. I remember increasing the number of FDS pages from 4 to 5. There was a problem which was resolved with this changed. I need to go back and evaluate this again.

Will keep you posted.

RE: first secure connection after DFU fails. SDK17 S113

Einar Thorsrud — Mon, 12 Oct 2020 09:22:07 GMT

Hi,

[quote user="ajcurtis"]The original logs had service changed enabled for both the application and the bootloader. Later I disabled the service changed notification in the application. There was no change in the bond behavior either way.[/quote]

You should always have service changed enabled both in the bootloader and application. If you don't use it, then you should remove it in both. (If not, you can end up in a situation where the phone will not do service discovery because it waits for the service changed indication, as it discovered the service changed characteristic before, when device was in the bootloader). I do not think this is related to the issue at hand, though.

[quote user="ajcurtis"]I believe deleting the bonds on Android would work. However that is not a viable solution for our product. Right now we would rather ship with this defect provided it recovers on the next boot.[/quote]

I agree that is not a viable solution for most products. However, this suggests that the bonding information is lost or corrupted, so it is relevant information.

[quote user="ajcurtis"]Which FDS configuration is of concern? Here are the option from sdk_config.h. No appdata reserved.[/quote]

I assume this is from the application's sdk_config.h. Here you reserve 5 pages. Is that the case for both the old and new firmware?

App data flash pages are reserved differently in different SDK versions. IN the SDK 14 bootloader, this is DFU_APP_DATA_RESERVED, which you typically set as a project vide define or by modifying nrf_dfu_types.h. In SDK 17 this is the NRF_DFU_APP_DATA_AREA_SIZE. In both cases these must be configured to match the number of FDS pages.

If this is not the problem, then I would very much like to see your application and bootloader projects, both old and new to compare and see if anything sticks out.

RE: first secure connection after DFU fails. SDK17 S113

Allen — Sun, 11 Oct 2020 03:24:27 GMT

Which FDS configuration is of concern? Here are the option from sdk_config.h. No appdata reserved.

#define FDS_ENABLED 1

#define FDS_VIRTUAL_PAGES 5

#define FDS_VIRTUAL_PAGE_SIZE 1024

#define FDS_VIRTUAL_PAGES_RESERVED 0

#define FDS_BACKEND 2

#define FDS_OP_QUEUE_SIZE 4

#define FDS_CRC_CHECK_ON_READ 0

#define FDS_CRC_CHECK_ON_WRITE 0

#define FDS_MAX_USERS 4

The original logs had service changed enabled for both the application and the bootloader. Later I disabled the service changed notification in the application. There was no change in the bond behavior either way.

I will test going from SDK17 S113 7.0.1 to SDK17 S113 7.2.0

I believe deleting the bonds on Android would work. However that is not a viable solution for our product. Right now we would rather ship with this defect provided it recovers on the next boot.

RE: first secure connection after DFU fails. SDK17 S113

Einar Thorsrud — Wed, 07 Oct 2020 11:03:01 GMT

Hi,

From older post

[quote user="ajcurtis"]Could the issue be passing the bond information back to the application from the bootloader when the DFU is complete? [/quote]

No. bonding information only goes from application to bootloader when starting the DFU, but not from the bootloader to application. It is not touched.

[quote user="ajcurtis"]After more testing, it appears the reset issue reported is related to a bond mismatch between the host and device. There seems to be several failure modes:[/quote]

I do not get a full understanding from the logs, but I think I may have read them too quickly before. It could be that bonding information is deleted during the DFU update. You could verify the FDS page configuration in the application and the reserved appdata in the bootloader. This does not fit what we see with the GATT write, though.

Some questions, which it would be good to get answered:

Have you looked into uploading a project that can reproduce this on a DK?
Do you have service changed enabled in both the bootloader and application?
You mention tha tyou deleted bonding information in Windows, and then you did not see any issues. What was that issue?
What happens if you delete bonding information on the Android device?
Do you only see this issue when doing DFU from SDK 14 to SDK 17? What if you DFU in the same SDK 17 or SDK 14 application again (you need to change the version number in the .zip, though)? Same issue?

RE: first secure connection after DFU fails. SDK17 S113

Allen — Tue, 06 Oct 2020 23:42:26 GMT

After more testing, it appears the reset issue reported is related to a bond mismatch between the host and device. There seems to be several failure modes:

Tesing from Windows

1. Host maintains the bond negotiated for DFU: (both sides have previous bonds)
PM_EVT_LOCAL_DB_CACHE_APPLY_FAILED
0> PMM: CONNECTED, stored 0 peers
this never crashed but we have a 30 second timer to complete a connection

2. Host bond is deleted, device has original bond:
This reproduces the reset condition reported. However when it resets it gets PM_EVT_CONN_SEC_FAILED and loops, never completing the connection

If the bonds are deleted on both sides when the DFU operation is completed, everything works.

RE: first secure connection after DFU fails. SDK17 S113

Allen — Tue, 06 Oct 2020 19:33:28 GMT

Another detail that I should point out is that this is a DFU upgrade of the entire chip.

from SDK14, S132 v5.0 to SDK17, S113 v7.2.0

Everything is different, including the format of the bootloader settings file.

RE: first secure connection after DFU fails. SDK17 S113

Allen — Tue, 06 Oct 2020 19:17:49 GMT

Here is a log from a Windows DFU process. The main difference is that in Windows we delete the bonds on both sides after the DFU operation. (work around Windows bug) This works fine.

Could the issue be passing the bond information back to the application from the bootloader when the DFU is complete?

0> REBOOT (59)
0> Bluetooth Name NM04-000078
0> Board Type D045
0> Model Type ETM
0> FPGA Ver Model 4 Version 4
0> Firmware Ver 2.1.399
0> Firmware Type FIELD
0> SoftDevice Ver 7.2.0
0> BootLoader Ver 7 (INSTALLED)
0> Mfg Data Ver 4
0> Sys Config Ver 12
0> API Versions OK
0> Bluetooth Enabled
0> UART Enabled
0> Stimulation Enabled
0> Acceleration Disabled (0)
0> Force Error Disabled (0)
0> Electrode Map Field 8 Contact
0> Reboot Reason DFU
0>
0> 0:00:00.000 BLE terminated
0> BLE: Local BDADDR xE49C814C1039
0> PM: PM_EVT_PEER_DELETE_SUCCEEDED
0> PM: Bond deleted.
0> 0:00:01.446 PWR: Entering normal power
0> 0:00:01.449 STIM STATE: x02
0> 0:00:01.449 ADV: Sys=FFFFFFFF Dev=0 VBat=3956 Amp={63 63 63 63} Sched=00/FF Err=00 Col=02 Prg=F Ins=0 Post=0 Stim=1 LowP=0 LowB=0 Sess=1 BLE=1 Buzz=0
0> 0:00:01.573 STIM EVENT[01]: x0E
0> 0:00:01.574 STIM STATE: x03
0> SD: 26 BLE_GAP_EVT_ADV_SET_TERMINATED
0> 0:00:02.110 Detected ID x00000244 (Patient x00000244, Reference xFFFFFFFF)
0> 0:00:02.110 update_implant_trim_data
0> 0:00:02.111 Trim not found
0> 0:00:02.113 Connected to patient device x00000244
0> 0:00:02.113 STIM EVENT[02]: x0F
0> 0:00:02.114 STIM STATE: x0E
0> 0:00:02.119 STIM EVENT[03]: x2B
0> 0:00:02.119 STIM STATE: x06
0> 0:00:02.147 ADV: Sys=FFFFFFFF Dev=0 VBat=3956 Amp={63 63 63 63} Sched=00/FF Err=00 Col=02 Prg=F Ins=1 Post=0 Stim=2 LowP=0 LowB=0 Sess=1 BLE=1 Buzz=0
0> SD: 26 BLE_GAP_EVT_ADV_SET_TERMINATED
0> SD: 10 BLE_GAP_EVT_CONNECTED
0> BLE: Remote xD43B041E1733
0> NCE: bd_addr1 xE49C814C1039
0> NCE: bd_addr2 xD43B041E1733
0> PK: device passkey B2A6E8A253D24B8D
0> BLE: GAP connected. Unauthenticated timer restarted
0> 0:00:06.232 BLE terminated
0> SD: 55 BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST
0> SD: 24 BLE_GAP_EVT_DATA_LENGTH_UPDATE
0> SD: 3A SD_BLE_GATTC_EXCHANGE_MTU_REQUEST
0> 0:00:06.331 ADV: Sys=FFFFFFFF Dev=0 VBat=3956 Amp={63 63 63 63} Sched=00/FF Err=00 Col=02 Prg=F Ins=1 Post=0 Stim=2 LowP=0 LowB=0 Sess=1 BLE=0 Buzz=0
0> SD: 26 BLE_GAP_EVT_ADV_SET_TERMINATED
0> SD: 11 BLE_GAP_EVT_DISCONNECTED
0> 0:00:09.759 BLE: Disconnect Reason x0013 (TERM BY HOST)
0> PMM: DISCONNECTED, active 0xFFFFu keep_bond_state 186785
0> 0:00:09.817 ADV: Sys=FFFFFFFF Dev=0 VBat=3956 Amp={63 63 63 63} Sched=00/FF Err=00 Col=02 Prg=F Ins=1 Post=0 Stim=2 LowP=0 LowB=0 Sess=1 BLE=1 Buzz=0
0> SD: 26 BLE_GAP_EVT_ADV_SET_TERMINATED
0> SD: 10 BLE_GAP_EVT_CONNECTED
0> BLE: Remote xD43B041E1733
0> NCE: bd_addr1 xE49C814C1039
0> NCE: bd_addr2 xD43B041E1733
0> NONCE: rand_num 9445BE12
0> PK: device passkey B2A6E8A2524F381F
0> BLE: GAP connected. Unauthenticated timer restarted
0> 0:00:31.052 BLE terminated
0> SD: 55 BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST
0> 0:00:31.133 ADV: Sys=FFFFFFFF Dev=0 VBat=3956 Amp={63 63 63 63} Sched=00/FF Err=00 Col=02 Prg=F Ins=1 Post=0 Stim=2 LowP=0 LowB=0 Sess=1 BLE=0 Buzz=0
0> SD: 24 BLE_GAP_EVT_DATA_LENGTH_UPDATE
0> SD: 3A SD_BLE_GATTC_EXCHANGE_MTU_REQUEST
0> SD: 13 BLE_GAP_EVT_SEC_PARAMS_REQUEST
0> PM: PM_EVT_CONN_SEC_START
0> PM: PM_EVT_CONN_SEC_PARAMS_REQ
0> SD: 1A BLE_GAP_EVT_CONN_SEC_UPDATE
0> SD: 19 BLE_GAP_EVT_AUTH_STATUS
0> PM: PM_EVT_CONN_SEC_SUCCEEDED
0> PM: Connection secured. Procedure: 1 Role: 1 conn_handle: 0
0> PMM: CONNECTED, stored 1 peers
0> PM: PM_EVT_PEER_DATA_UPDATE_SUCCEEDED
0> pdb_write_buf_get id=0 err=0
0> sd_ble_gatts_sys_attr_get id=0 err=0
0> pdb_write_buf_store id=0 err=0
0> local_db_update_in_evt err=0
0> PM: PM_EVT_PEER_DATA_UPDATE_SUCCEEDED
0> PM: PM_EVT_PEER_DATA_UPDATE_SUCCEEDED
0> SD: 35 SD_BLE_GATTC_CHAR_VALUE_BY_UUID_READ
0> SD: 12 BLE_GAP_EVT_CONN_PARAM_UPDATE
0> SD: 36 SD_BLE_GATTC_READ
0> PM: PM_EVT_PEER_DATA_UPDATE_SUCCEEDED
0> SD: 26 BLE_GAP_EVT_ADV_SET_TERMINATED
0> SD: 52 BLE_GATTS_EVT_SYS_ATTR_MISSING
0> PM: PM_EVT_LOCAL_DB_CACHE_APPLIED
0> SD: 12 BLE_GAP_EVT_CONN_PARAM_UPDATE
0> SD: 50 BLE_GATTS_EVT_WRITE
0> B gcm_ble_evt_handler EVT_WRITE
0> pdb_write_buf_get id=0 err=0
0> sd_ble_gatts_sys_attr_get id=0 err=0
0> pdb_write_buf_store id=0 err=0
0> local_db_update_in_evt err=0
0> E gcm_ble_evt_handler EVT_WRITE
0> on_write:453 resp 0
0> on_write:561 resp 0
0> PM: PM_EVT_PEER_DATA_UPDATE_SUCCEEDED
0> SD: 50 BLE_GATTS_EVT_WRITE
0> B gcm_ble_evt_handler EVT_WRITE
0> pdb_write_buf_get id=0 err=0
0> sd_ble_gatts_sys_attr_get id=0 err=0
0> pdb_write_buf_store id=0 err=0
0> local_db_update_in_evt err=0
0> E gcm_ble_evt_handler EVT_WRITE
0> on_write:453 resp 0
0> on_write:561 resp 0
0> PM: PM_EVT_PEER_DATA_UPDATE_SUCCEEDED
0> SD: 51 BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST
0> on_write:453 resp 1
0> BLE_NUS_EVT_HOST_PASSKEY_DATA
0> BLE: ble_host_passkey[16]=B4 F7 72 7E FF 8C BF 32 0E AB 5A 7A 6F A9 B0 96
0> NCE: bd_addr1 xD43B041E1733
0> NCE: bd_addr2 xE49C814C1039
0> PK: passkey 0EAB5A7A6FA9B096
0> PK: ptr 0EAB5A7A6FA9B096
0> CDB: oldest table[0].timestamp = 51
0> CDB: table[0].addr = 68EB8938A770, .timestamp = 38158
0> CDB: oldest table[1].timestamp = 4294967285
0> CDB: table[1].addr = 5A5F58810DBC, .timestamp = 23936
0> CDB: oldest table[2].timestamp = 4294967293
0> CDB: table[2].addr = 4ED340F5FCA343on_write:561 resp 1
0> status 0 err_code 0
0> SD: 50 BLE_GATTS_EVT_WRITE
0> B gcm_ble_evt_handler EVT_WRITE
0> E gcm_ble_evt_handler EVT_WRITE
0> on_write:453 resp 0
0> BLE_NUS_EVT_RX_DATA
0> 0:00:32.830 BLE detected
0>
0>
0> on_write:561 resp 0
0> 0:00:32.833 Sess Start
0> Session Type=Programming
0> BLE: Connection in session. Session timer restarted
0> 0:00:32.833 STIM EVENT[04]: x09 (255)
0> 0:00:32.833 ACK: 001000
0>
0> PMM: ENTER_UNPROTECTED, active id=x0000
0> PM_PEER_DATA_ID_APPLICATION 4
0> data_id 4
0> PM: PM_EVT_PEER_DATA_UPDATE_SUCCEEDED
0> SD: 57 BLE_GATTS_EVT_HVN_TX_COMPLETE
0> SD: 50 BLE_GATTS_EVT_WRITE
0> B gcm_ble_evt_handler EVT_WRITE
0> E gcm_ble_evt_handler EVT_WRITE
0> on_write:453 resp 0
0> BLE_NUS_EVT_RX_DATA
0>
0> on_write:561 resp 0
0> 0:00:32.921 Rd Ver
0> Firmware=2.1.399 SecurityVer=2 AdvertiseVer=4 UnrestictedVer=9 RemoteVer=4 ProgrammingVer=14 EngineeringVer=12 FPGAModel=4 FPGAVer=4 ImplantVer=1 Bootloader=7 SD_FWID=x0102 SD_Ver=7.2.0 Model=ETM Type=FIELD_BLE_UART
0> 0:00:32.921 ACK: 002016
0>
0> SD: 57 BLE_GATTS_EVT_HVN_TX_COMPLETE

RE: first secure connection after DFU fails. SDK17 S113

Einar Thorsrud — Tue, 06 Oct 2020 19:14:47 GMT

Hi,

[quote user="ajcurtis"]The PM library knows about the peer. pm_peer_id_get() returns the correct peer ID for the specified connection handle.[/quote]

Yes the peer manager library knows about the peer and according to the log the connection is secured (which happens using the stored bondign information) also the first time, before the error happens.

[quote user="ajcurtis"]The error isn't identified until a BLE_GATTS_EVT_WRITE event. The BLE event handler in gatt_cache_manager ultimately causes the error when updating the local DB.[/quote]

I see. So pdb_write_buf_store() returns NRF_ERROR_INVALID_PARAM (7) because the peer ID is not allocated, or so it seems. Is there a timing factor there? What happens if you delay the GATT write?

[quote user="ajcurtis"]It assumed that the bond used for the secure DFU is preserved and used when the new firmware loads.[/quote]

Yes, the bond is preserved provided you have configured the application and bootloader correctly (so that the bootloader is configured to stay away of the FDS pages). This does not seem to be the problem though: the link is secured, so the boning information is clearly present.

Do you have any code that can reproduce this on the DK?

RE: first secure connection after DFU fails. SDK17 S113

Allen — Tue, 06 Oct 2020 18:42:39 GMT

Yes, it is very strange.

The PM library knows about the peer. pm_peer_id_get() returns the correct peer ID for the specified connection handle. My initial assumption was that this would fail and I would need to manually add the peer using pm_peer_new().

The error isn't identified until a BLE_GATTS_EVT_WRITE event. The BLE event handler in gatt_cache_manager ultimately causes the error when updating the local DB.

I should also note that this is on Android. It assumed that the bond used for the secure DFU is preserved and used when the new firmware loads.

RE: first secure connection after DFU fails. SDK17 S113

Einar Thorsrud — Tue, 06 Oct 2020 12:58:03 GMT

Hi,

I do not have an explanation for this strange behaviour. There should not be any difference between the first and second time the application runs after reset, and it is odd that the peer manager does not find the bonding information in flash the first time but it suddenly reappears after a reset. Are you able to reproduce this on a DK? Can you share the project so that I can have a look and test on my side?