Bonding Information not stored in Flash memory

RE: Bonding Information not stored in Flash memory

Niclas Heitz — Mon, 19 Mar 2018 11:28:45 GMT

I had the same problem.

Did you include /components/softdevice/common/nrf_sdh_soc.c?

This solved the issue for me.

For some reason neither the compiler nor the linker are complaining if it is missing.

Also it can happen, that the optimizer can remove it, as mentioned here:

devzone.nordicsemi.com/.../fds-not-able-to-write-in-sdk-14

RE: Bonding Information not stored in Flash memory

naman.trivedi — Thu, 01 Mar 2018 05:17:02 GMT

I did the same. There were two differences:

1. I used static library (.a) for SDK files. The sample application compiles the files and links objects directly. I had compiled every files necessary for my application. ( SDK file list is same for my application and Sample App.)

2. I did not include Makefile.common in my application.

RE: Bonding Information not stored in Flash memory

Matt — Wed, 28 Feb 2018 16:01:28 GMT

Would a simple diff do if we are just talking about Makefiles?

RE: Bonding Information not stored in Flash memory

naman.trivedi — Wed, 28 Feb 2018 14:22:34 GMT

Yes I was doing same. I had my own make system which didn't work. We need to use SDK's make system. Still knowing the exact root cause is to be done. I will debug it further to know the exact root cause and post here for others knowledge!

RE: Bonding Information not stored in Flash memory

Austin — Wed, 28 Feb 2018 10:38:40 GMT

FDS depends on being able to observe events and registers an event handler using NRF_SDH_SOC_OBSERVER. If the observers aren't working correctly as you've eluded to in your question, then pairing data will not be stored correctly as FDS will not be receiving all expected events. If you're using the nRF5 SDK make system and linker scripts, use of NRF_SDH_SOC_OBSERVER and friends should just work. The linker scripts did change between SDK versions so check that all the appropriate sections are present in the linker scripts. I had a similar issue to this with a custom make system where I compiled the SDK to a library (.a) and then attempted to link this library to a final executable with a main.c. Linking .a files containing the SDK does not work correctly in the presence of NRF_SDH_SOC_OBSERVER usage in all cases, because when linking, only object files that have referenced symbols are included in the link. If I remember correctly, for FDS there are no directly referenced symbols from the file in which NRF_SDH_SOC_OBSERVER is used and so the FDS event handler and friends do not appear in the final binary. This is a silent failure which you can only really detect easily be looking in the disassembly of the output file to ensure that all the expected number of event observers have been registered in the observer link sections.

RE: Bonding Information not stored in Flash memory

naman.trivedi — Wed, 28 Feb 2018 06:22:12 GMT

I tried several ways and finally issue was resolved. I had my own Makefile for the project. Now, I used sample application Makefile from SDK and compiled my project which solves the issue. I need to find root cause yet but I have the solution now.

RE: Bonding Information not stored in Flash memory

Vidar Berg — Tue, 27 Feb 2018 13:18:06 GMT

Just be sure, is nrf_sdh_soc.c included in your build? Just realized that's possible to build a project without this source file as there are no compile time dependencies for it. This could explain why you are not seeing SD soc events.

RE: Bonding Information not stored in Flash memory

Vidar Berg — Mon, 26 Feb 2018 09:00:13 GMT

Please provide a stripped down version of the project so I can debug it here. You can create a new private support ticket if you don't want to share it in an open forum.

RE: Bonding Information not stored in Flash memory

naman.trivedi — Mon, 26 Feb 2018 08:50:25 GMT

Any update on this question?

RE: Bonding Information not stored in Flash memory

naman.trivedi — Fri, 23 Feb 2018 12:37:49 GMT

I already did this. I found this bug from another ticket on nordic devzone and I put the

"p_fs->p_flash_info = &m_flash_info;" line outside if condition. The issue is still present after this. I can see that pds_peer_data_store is called, and it returned success, then why would FDS handler of peer manager not be called?

RE: Bonding Information not stored in Flash memory

Vidar Berg — Thu, 22 Feb 2018 17:39:14 GMT

There's a bug in the fstorage module that prevents multiple instances from being initialized correctly. I suspect that this could be the problem. You can modify the init function nrf_fstorage.sd so that p_flash_info is always set when a new instance is registered :

static ret_code_t init(nrf_fstorage_t * p_fs, void * p_param)
{
    UNUSED_PARAMETER(p_param);
    
   p_fs->p_flash_info = &m_flash_info;

    if (!nrf_atomic_flag_set_fetch(&m_flags.initialized))
    {
        
   /*p_fs->p_flash_info = &m_flash_info;*/ 
#if NRF_SDH_ENABLED
        m_flags.sd_enabled = nrf_sdh_is_enabled();
#endif

        (void) NRF_ATFIFO_INIT(m_fifo);
    }

    return NRF_SUCCESS;
}

Fix will be included in upcoming SDK release.

It's should not be a problem that you are using an older softdevice on the peripheral.

RE: Bonding Information not stored in Flash memory

naman.trivedi — Thu, 22 Feb 2018 16:22:47 GMT

Yes I have fstorage instance in my app. The FDS call back of peer manager does get the INIT and GC events only. No any read write event. Also as I asked in my question, i am using device with softdevice 2 as peripheral and soft device 5.0 as central. Can that be an issue?

RE: Bonding Information not stored in Flash memory

Vidar Berg — Thu, 22 Feb 2018 14:42:07 GMT

That's good, it's trying to store the data at least.

The fstorage backend registers its own observer instance so it is not necessary add a new observer. All observers should however receive the same events.

Have you registered other FDS/fstorage instances in your app, or is it just the peer manager that uses it?Also, have you tried to see if the fds callback for the PM receives any write/update events (peer_data_storage.c->fds_evt_handler)?

RE: Bonding Information not stored in Flash memory

naman.trivedi — Thu, 22 Feb 2018 13:27:09 GMT

1. pds_peer_data_store() gets called.

2. procedure is PM_LINK_SECURED_PROCEDURE_BONDING

I have doubt on the FDS/FSTORAGE module. I have registered SOC handler using NRF_SDH_SOC_OBSERVER but that handler is never called. I believe it should be called for every flash Write operation. Can that be issue?

Also, I am using first the device as peripheral to connect to a Mobile APP, and then after this connection is broken and then I use the device as a central to connect with a peripheral.

RE: Bonding Information not stored in Flash memory

Vidar Berg — Thu, 22 Feb 2018 12:24:27 GMT

I think it would be best if you could provide a stripped down version of the project as Matt suggested earlier. But please try the following:

1. Place a breakpoint in peer_data_storage -> pds_peer_data_store() to see if it is being called after BLE_GAP_EVT_AUTH_STATUS. Make sure that any bond info is erased on both devices before you do the test.

2. Check the pm_evt_t::pm_conn_sec_procedure_t value when you receive the PM_EVT_CONN_SEC_SUCCEEDED event.

3. If you have a BLE sniffer, try to capture the initial bonding procedure.

RE: Bonding Information not stored in Flash memory

naman.trivedi — Thu, 22 Feb 2018 07:19:18 GMT

Debugging further I found that inside the SDK, /peer_data_storage.c file has registered fds_evt_handler. This handler is called only twice, one for INIT event and once for GC (Garbage Collection) event. This both are done before pairing started. I doubt the issue is with FDS? Not sure though.

RE: Bonding Information not stored in Flash memory

naman.trivedi — Thu, 22 Feb 2018 05:55:11 GMT

It was there and I tried removing pm_peers_delete from peer_manager_init but the result was same. Bonding information is not stored and I get same Peer manager events as mentioned above.

RE: Bonding Information not stored in Flash memory

Matt — Wed, 21 Feb 2018 23:50:33 GMT

Or the bonding data (long term key LTK and other stuff...) is stored in flash but somehow got wiped out later on? Do you call the peer_manager_init(erase_bonds) in your main()? If so, can you check to make sure erase_bonds is set to false?

RE: Bonding Information not stored in Flash memory

naman.trivedi — Wed, 21 Feb 2018 15:01:36 GMT

When I receive PM_EVT_CONN_SEC_SUCCEEDED event, I call pm_conn_sec_status_get to receive connection status, and in that I receive

1. conn_sec_status.bonded

2. conn_sec_status.connected

3. conn_sec_status.encrypted

all 3 of the above flags are 1. So the bonding is done but data is not stored in flash.

RE: Bonding Information not stored in Flash memory

naman.trivedi — Wed, 21 Feb 2018 14:38:30 GMT

Sorry Matt, I can't share the project due to NDA signed with client. However, if there are some specific snippets which would help you to look more into the issue, I can share that here. Hope you don't mind!

RE: Bonding Information not stored in Flash memory

Matt — Wed, 21 Feb 2018 14:32:50 GMT

Ideally it should be a whole project that the Nordic support folks can take and compile and execute right away. So make sure it's bare bone and does not contain any proprietary and sensitive info from your company :)

RE: Bonding Information not stored in Flash memory

naman.trivedi — Wed, 21 Feb 2018 14:20:05 GMT

I can share specific part of the code. Can you tell me what exactly I should share?

RE: Bonding Information not stored in Flash memory

naman.trivedi — Wed, 21 Feb 2018 14:16:39 GMT

1. Yes, SEC_PARAM_BOND is true.

2. yes, peer device also supports bonding. I am using same, nrf52 as peer device which will be in peripheral role. The peer device uses SoftDevice 2.0 and the central is using SoftDevice 5.0. Can that be an issue?

RE: Bonding Information not stored in Flash memory

Matt — Wed, 21 Feb 2018 14:11:04 GMT

So your nRF52 is running as a GAP central role? Can you share your bare minimal GAP central code here?

RE: Bonding Information not stored in Flash memory

Vidar Berg — Wed, 21 Feb 2018 14:10:44 GMT

Hi,

It sounds like the devices are being paired and not bonded. Please verify that the bond flag is set to 'true' when you initialize the PM module:

static void peer_manager_init(void)
{

...

sec_param.bond = SEC_PARAM_BOND;

...

Then check if the peer device supports bonding as well . This will be reported through the PM_EVT_CONN_SEC_PARAMS_REQ event: