BLE Disconnection does not work when "bt_conn_disconnect" is used

[Anirudh Agarkhed]

Build Environment - NCS 1.4.0

Board - nrf52840dk_nrf52840

Samples used - "central_hr" & "peripheral_hr"

Code changes - in "peripheral_hr" - src/main.c - replace the while(1) loop with the following code (disconnection attempt is made every 10 seconds)

while (1) {
    static int count;

    if ( !((++count%10)) ) { 
        if (default_conn) {
            int err = bt_conn_disconnect(default_conn, BT_HCI_ERR_SUCCESS);
            printk("Err RC = %d\n", err);
        }
    }
    k_sleep(K_SECONDS(1));

    /* Heartrate measurements simulation */
    hrs_notify();

    /* Battery level simulation */
    bas_notify();
}

Expected behaviour -

1. HR notifications are sent for 9 seconds.
2. Disconnection is triggered on 10th second.
3. Advertising resumes.
4. Central scans and reconnects.
5. Cycle repeats

Issues observed -

1. Return code "err" is 0, but advertising does not start.
2. Scanning does not resume on the central.

Note - When the same code is built with Zephyr 2.4.0 using the board "nrf52840dk_nrf52840", the code behaves as expected.

[Anirudh Agarkhed]

With NCS 1.4.0, when the "prj.conf" is used to disable the SoftDevice LL, the behavior is as expected. Options used to disable SoftDevice LL -

CONFIG_BT_HCI=y
CONFIG_BT_CTLR=y
CONFIG_BT_LL_SW_SPLIT=y
CONFIG_BT_LL_SOFTDEVICE=n

So the issue of disconnection seems to be with the SoftDevice.

[ovrebekk]

Hi Anirudh

Normally you have to start advertising manually when a link is disconnected. Could you try re-starting advertising and scanning in the disconnected callback?

Best regards
Torbjørn

[Anirudh Agarkhed]

The disconnected callback is not triggered in the first place. Had put in a "printk" statement to verify. When SoftDevice is disabled, that disconnected callback is triggered, and the printk statement printed, and advertising is resumed.

[Joakim Andersson]

The issue is from the disconnect reason. BT_HCI_ERR_SUCCES is not acceptable as a disconnect reason, use BT_HCI_ERR_REMOTE_USER_TERM_CONN instead.

The error code should have been propagated to the application.
I have submitted a patch to fix that, and to have the Zephyr LL validate the disconnect reason.