Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

Mesh LPN application timing out and/or terminating

Hi,

I have a custom application that is very much based on the LPN example as well as friend nodes that have custom applications based on the light switch server example. They are running on nrf52840dk rev2 with nrf sdk 17.0.2 and s140 7.2.0 softdevice. I provision with the nrf Mesh application for Android. All devices are within a meter of each other.

The friend nodes work just fine but the LPN goes into a cycle of terminating/timing out with reason 2 (NRF_MESH_EVT_FRIENDSHIP_TERMINATED_REASON_NO_REPLY). This is the log from RTT:

00> <t:      12872>, main.c,  302, THP Sensor Model Handle: 2
00> <t:      12877>, main.c,  305, Timestamp Model Handle: 3
00> <t:      17637>, mesh_app_utils.c,   66, Device UUID (raw): 4B842A956B654A04A05B04B3FDCF6F9C
00> <t:      17642>, mesh_app_utils.c,   67, Device UUID : 4B842A95-6B65-4A04-A05B-04B3FDCF6F9C
00> <t:    6479487>, ble_softdevice_support.c,  104, Successfully updated connection parameters
00> <t:    6567957>, ble_softdevice_support.c,  104, Successfully updated connection parameters
00> <t:    6815097>, main.c,  166, Successfully provisioned
00> <t:    6815106>, main.c,  160, Node Address: 0x001B 
00> <t:    6815109>, main.c,   98, Initiating the friendship establishment procedure.
00> <t:    6824388>, main.c,  226, Received friend offer from 0x0012
00> <t:    6827948>, main.c,  267, Friendship established with: 0x0012
00> <t:    7132221>, ble_softdevice_support.c,  104, Successfully updated connection parameters
00> <t:    7156143>, main.c,  279, Friendship with 0x0012 terminated. Reason: 2
00> <t:    7156150>, main.c,   98, Initiating the friendship establishment procedure.
00> <t:    7161669>, main.c,  226, Received friend offer from 0x0014
00> <t:    7182837>, main.c,  257, Friend Request timed out
00> <t:    7182842>, main.c,   98, Initiating the friendship establishment procedure.
00> <t:    7189079>, main.c,  226, Received friend offer from 0x0011
00> <t:    7192638>, main.c,  267, Friendship established with: 0x0011
00> <t:    7226343>, ble_softdevice_support.c,  104, Successfully updated connection parameters
00> <t:    7513799>, main.c,  253, Friend poll procedure complete
00> <t:    7841995>, main.c,  279, Friendship with 0x0011 terminated. Reason: 2
00> <t:    7842001>, main.c,   98, Initiating the friendship establishment procedure.
00> <t:    7871185>, main.c,  226, Received friend offer from 0x0011
00> <t:    7892358>, main.c,  257, Friend Request timed out

In addition, this happens exactly when I start the provisioning process and it fails at the "Getting composition data..." step.

My assumptions are that the provisioner is unable to communicate with the LPN because its not supposed to start initiating friendships too early. The LPN example uses a button handler to initiate friendship after provisioning, but I use the provisioning complete callback instead:

static void provisioning_complete_cb(void)
{
    __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Successfully provisioned\n");

    /* Restores the application parameters after switching from the Provisioning
     * service to the Proxy  */
    gap_params_init();
    conn_params_init();

#if BLE_DFU_SUPPORT_ENABLED
    ble_dfu_support_service_init();
#endif

    unicast_address_print();

#ifdef  THP_SENSOR
    if (!mesh_lpn_is_in_friendship())
    {
        initiate_friendship();
    }
    else /* In a friendship */
    {
        terminate_friendship();
    }
#endif
}

Is calling initiate_friendship() here a wrong thing to do?

Related