calling bt_conn_le_create_auto() stops notify callbacks from existing connection

[JustinL]

Hi,

We are migrating code from NRF Connect sdk 1.3.1 on nRF52840 to NRF Connect 1.6.1 on Nrf5340.  Using SoftDevice as BLE controller on both.

Our existing code uses a whitelist and auto connection to periodically check for devices to connect to. Once connected we receive a continuous stream of data from each connected device via bt_gatt_subscribe and notify callbacks.

What we are seeing on the nRF5340 is once the first device is connected and starts getting data on the notify callback, as soon as the next call to bt_conn_le_create_auto() happens the notify callbacks for the existing connect stop. This happens even when we have only one peripheral i.e. it is not a second connection that causes the problem, just the resumption of scanning via the auto-connect call.   

The BLE configuration is:

CONFIG_BT_CTLR_LLPM=n

CONFIG_BT_DEVICE_NAME="VRS"
CONFIG_BT=y
CONFIG_BT_DEBUG_LOG=y
CONFIG_BT_SMP=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_CENTRAL=y
CONFIG_BT_MAX_CONN=4

CONFIG_BT_SCAN=y
CONFIG_BT_SCAN_FILTER_ENABLE=y
CONFIG_BT_SCAN_UUID_CNT=1

CONFIG_BT_GATT_CLIENT=y
CONFIG_BT_GATT_DM=y

CONFIG_BT_LL_SOFTDEVICE_VS_INCLUDE=y
CONFIG_BT_LL_SOFTDEVICE=y
CONFIG_BT_HCI_VS_EVT_USER=y
CONFIG_HEAP_MEM_POOL_SIZE=2048
CONFIG_BT_GAP_PERIPHERAL_PREF_PARAMS=n

Do you know what we might be doing wrong?

[JustinL]

Also, it is nothing we are doing in the notify callback. We are sure of this because simply sending a log msg and returning immediately from the callback results in the same problem. 

[JustinL]

In addition, we have just tested switching from SoftDevice BLE controller to the Zephyr controller for the hci_rpmsg net cpu and the problem disappears.

[Sigurd]

Hi,

That is strange. You only set CONFIG_BT_LL_SW_SPLIT=y in hci_rpmsg.conf , and then it worked ?

I can try to reproduce it here. Did you call bt_conn_le_create_auto() in the connected callback? 

[JustinL]

Hi,

Yes, the only change was CONFIG_BT_LL_SW_SPLIT=y in hci_rpmsg.conf.

We do not call bt_conn_le_create_auto() in the connected call back. We call it periodically in our main loop. 

Would it be more stable to call it from the connect callback? We can try that.

[JustinL]

Hi,

We have tried moving the auto connect call to the connected callback with no difference.

We have noticed that once bt_conn_le_create_auto() is called notify only happens every 4s which is actually the supervision timeout we have set. 

The connection interval is set at 7.5ms. We see on the BLE sniffer that central makes no connection events until the 4s elapse. 

This leads us to think that what is happening is that the scanning radio activity is being prioritised above the connection interval anchors until the supervision timeout. 

So maybe this is a scheduler conflict. Is there anyway to configure a less aggressive scanning from auto connect? Since each notify is just one packet every 7.5ms there should be a lot of available radio time for scanning if it were to fit around the connection events.

Would there be other problems if we set the supervision timeout to the lowest possible (10ms)? Seems like an odd way to get scanning and short interval notifications working together?

Thanks,

Justin 

[Sigurd]

Hi,

I tried using the central_hr example in zephyr to reproduce this, but it seem to work fine when I called bt_conn_le_create_auto().
Attachment: 4061.central_hr.rar

Maybe you can help modify this, so it reproduces the issue?

I don't think this is a scheduling conflict. The scheduler handles this scenario. Could perhaps be an assert in the SoftDevice Controller on the network core? Do you have a debug log from the network core?

JustinL said:

Would there be other problems if we set the supervision timeout to the lowest possible (10ms)?

That would not be a good idea. You miss 1-2 packets, e.g. due to due to RF interference, and the link is disconnected/timeouted, and you need to re-connect.