nRF5340 Advertising stopped without any indication


We are using nRF5340 DK and the nRF Connect SDK Version 2.6.1.

We are developing a mesh network. Our requirement is the one device can connect to three other devices. Using one connection as a peripheral and up to two connections as a central for mesh connections.

We are using extended advertising.

When the master tries to connect to the slave, it receives a disconnection event with reason 19. However, on the slave side, there are no connection or disconnection events; but the advertising has stopped, and the following hci errors have occurred in the slave side:

 <err> bt_hci_core: bt_hci_le_enh_conn_complete: No pending conn for peer FF:F5:55:5A:D6:6A (random)
 <err> bt_hci_core: hci_acl: Unable to find conn for handle 6
<wrn> bt_hci_core: bt_hci_host_num_completed_packets: Unable to look up conn with index 0xff

After these errors occur, advertising stopped.

Here I have attached adv start function

struct bt_le_adv_param adv_param ={
            .id = BT_ID_DEFAULT,    
            .sid = setId,   /* Supply unique SID when creating advertising set */        
            .secondary_max_skip = 0U,            
            .interval_min = ADV_INTERVAL_MIN,
            .interval_max = ADV_INTERVAL_MAX,
            .peer = NULL,


    /* Create a non-connectable non-scannable advertising set */
    err = bt_le_ext_adv_create(&adv_param, NULL, &adv[setId]);
    if (err) {
        printk("Failed to create advertising set %d (err %d)\n", setId, err);
        return err;

    /* Set extended advertising data */
    err = bt_le_ext_adv_set_data(adv[setId], ad_ext, ARRAY_SIZE(ad_ext), NULL, 0);
    if (err) {
        printk("Failed to set advertising data for set %d " "(err %d)\n", setId, err);
        return err;

    /* Start extended advertising set */
    err = bt_le_ext_adv_start(adv[setId], BT_LE_EXT_ADV_START_DEFAULT);
    if (err) {
        printk("Failed to start extended advertising set %d "  "(err %d)\n", setId, err);
        return err;

1. What could be causing this issue?

2. How can we determine if the advertising is still active?

  • If you on the central device experience the following disconnect reason:

    Then that means the peripheral is disconnecting intentionally by calling bt_conn_disconnect() with the BT_HCI_ERR_REMOTE_USER_TERM_CONN disconnect reason. I would have looked at where that may be happening.


  • Thanks for the response.

    As you mentioned, the disconnection is occurring internally, so there is no indication at the application layer. Consequently, I was unable to reconnect because advertising on the slave side has stopped.

    This issue occurs every second time a connection is made. After the initial connection, the master node disconnects and attempts to reconnect, leading to this problem in slave side.

    Attached are the connection count details for reference.


    Could you please check why advertising has stopped on the slave side?

    Is there any way to verify if the current advertising is active or not?


    The connection error occurred on the slave side, and advertising stopped because of the bt_conn_unref(conn) function. After removing this function from the disconnection handler, the connection issue was resolved. 

    Could you please check why disconnections are occurring internally and why advertising has stopped on the slave side when we use the bt_conn_unref(conn) function in the disconnection handler?

  • I can see that the peripheral count is 2, which means that it's possible to have 2 peripheral role connections (e.g one advertising and one in a connection). Are you 100% sure you have full control over the "conn" object that you provide to the bt_conn_unref(), and that for instance you are not actually providing the wrong one (e.g. that you are by accident provding the advertiser reference and not the connection reference when calling bt_conn_unref).


  • Hi

    I was using the bt_conn_unref(conn) function in the disconnection handler, but I hadn't used the bt_conn_ref(conn) function in the connection handler. After adding the bt_conn_ref(conn) function in the connection handler, the issue was resolved.

    I'll test further and let you know if any more issues arise.

Reply Children