Peer manager causes fault due to invalid connection handle.

[Dmitriy L1]

Hello all!

I'm trying to optimize power consumption for project based on nRF51802 and external host MCU. My current platform and toolchain:

1. nRF51802 as Bluetooth controller at custom board.

2. Segger Embedded Studio. Release 3.34b.

3. Soft Device S130 V2.0.1.

4. SDK version 12.3.0.

All had been working fine while it wasn't using peer manager library. I do need it since nRF51802 supposed to be put in sleep mode and it should store bonding information for further connections. Device freezes on pairing stage for first pairing occurence or on restoring secured connection in rare cases when bonding procedure was successfull. 

After some debugging I found that "sm_smd_evt_handler" is fed by event with zero connection handle, however connection is already established and GAP related functions doesn't rise any errors. I wonder how it can be as all events submitted by SoftDevice are common for all handlers. I know that handlers order in event dispatcher does matter, I think I put them correct. 

Please see details below. 

Any help would be apreciated! 

static void ble_evt_dispatch(ble_evt_t * p_ble_evt)
{
    ble_conn_params_on_ble_evt(p_ble_evt);
    ble_conn_state_on_ble_evt(p_ble_evt);    
    pm_on_ble_evt(p_ble_evt); 
    ble_evt_handler(p_ble_evt);
   
}

[haakonsh]

Connection handle 0 is the fist connection handle to be assigned. Your first connection will always be assigned to 0. 

I think the order of your event handlers are correct as well. 

Do you have any more debug information ?

[Dmitriy L1]

Thanks for response!

I've been confused with connection handle 0 since function wasn't able to resolve handle to connection role and returned error.

After some playing around handlers I don't observe freezing anymore. However device doesn't keep bonding information.

Passkey popup appears each time device resumed from sleep mode. Should I create another ticket or it can be discussed here?

[haakonsh]

I'll try to help you as best I can

First we should verify that you can write the bond information to flash. You'll need to find the address of the stored information and read out the content. 

[Dmitriy L1]

I tried to compare hex dumps of entire SoC memory, there were no writes at all. Later I found reason why - there were few duplicate event handlers like was described here:

https://devzone.nordicsemi.com/f/nordic-q-a/35433/configuring-peer-manager-for-bonding

Now device is able to save bonding info, but it became unstable. It can accept first connection after powering up and goes to hardfault on second attempt. I can't find were it crashes. 

[haakonsh]

I would try to focus on the retrieval of the bonding information from flash by the peer manager. Find out what is different from the first to the second connection establishment attempt. How far into the process do your get on the second attempt before you crash?

Do you have any debug information from the crash?