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. 

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

[naman.trivedi]

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.