Bonding Information not stored in Flash memory

[naman.trivedi]

I am using nrf52 with SDK 14.2.0 and SD is S132.

The issue I am facing is that after Central is paired with one peripheral and bonding is done, the bonding information is not stored by central and so the next time when the already bonded peripheral tries to connect with the Central, it follows pairing and bonding procedure. Below are the peer manager events that I am getting:

1. PM_EVT_CONN_SEC_PARAMS_REQ

2. PM_EVT_CONN_SEC_SUCCEEDED

3. PM_EVT_CONN_SEC_PARAMS_REQ

4. PM_EVT_CONN_SEC_SUCCEEDED

The above events are coming for new device as well as already paired device.

Also, one issue I think is I am never getting PM_EVT_PEER_DATA_UPDATE_SUCCEEDED event even after bonding is done. Also one more strange behavior is that my system event handler, which I registered using NRF_SDH_SOC_OBSERVER, is never called.

Can you please help me to resolve this issue?

[naman.trivedi]

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.

[Vidar Berg]

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. 

[naman.trivedi]

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. 

[Vidar Berg]

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)? 

[naman.trivedi]

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?

[Vidar Berg]

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.

[naman.trivedi]

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?

[Vidar Berg]

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.  

[naman.trivedi]

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. 

[Austin]

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. 

[naman.trivedi]

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!

[Matt]

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