Enabling BT_CENTRAL breaks MESH advertising

[adamfowleruk]

Describe the bug
I have an application scenario where I'm creating a MESH Gateway. This will connect to LE devices, but also be part of a MESH in a particular location. I had a working MESH sample, I then added a pre-existing BLE scanning API to it and then MESH advertising post provisioning failed. I stripped back all the changes until I now find that a single change in the config, not even including any additional code, breaks MESH advertising. This change is CONFIG_BT_CENTRAL=y.

To Reproduce
Steps to reproduce the behavior:

1. Check out the herald code and open this folder in VSCode (or similar) https://github.com/adamfowleruk/herald-for-cpp/tree/feature-113/herald-mesh-relay
2. Build the app and deploy to nRF52840 DK
3. Provision the device using the nRF MESH phone app
4. Once provisioned, observe in RTT logs that connections are opened (The phone nRF Mesh app) and remain open when BT_CENTRAL is set, causing MESH extended advertising to fail.

Expected behavior
I would expect that enabling BT_CENTRAL on its own does not break MESH advertising unless I deliberately (and foolishly) keep another connection open in my application outside of the MESH library. Ideally, the MESH library would proactively close any connections preventing it from advertising. (I have max connections set higher than 1)

Impact
A showstopper for my use case unfortunately as I need the central role and not the observer role so I can connect to nearby Herald LE-only apps. I'm building a Smart Hospitals app for Herald, a project within Linux Foundation Public Health.

I cannot determine the cause of the issue from logging. I shall try reading through the mesh c files for any changes that occur due to BT_CENTRAL being defined tomorrow. Any suggestions would be very grateful.

Logs and console output
Here are some RTT logs

[00:24:14.128,936] <dbg> app.main: Herald Relay main thread still running
[00:24:15.951,782] <inf> thread_analyzer: Thread analyze:
[00:24:15.951,995] <inf> thread_analyzer:  SDC RX              : STACK: unused 672 usage 352 / 1024 (34 %); CPU: 1 %
[00:24:15.952,087] <inf> thread_analyzer:  BT ECC              : STACK: unused 264 usage 880 / 1144 (76 %); CPU: 0 %
[00:24:15.953,704] <inf> thread_analyzer:  BT RX               : STACK: unused 5264 usage 880 / 6144 (14 %); CPU: 0 %
[00:24:15.953,979] <inf> thread_analyzer:  BT TX               : STACK: unused 1096 usage 440 / 1536 (28 %); CPU: 0 %
[00:24:15.954,071] <inf> thread_analyzer:  thread_analyzer     : STACK: unused 88 usage 424 / 512 (82 %); CPU: 0 %
[00:24:15.954,315] <inf> thread_analyzer:  0x200050e0          : STACK: unused 856 usage 168 / 1024 (16 %); CPU: 0 %
[00:24:15.954,589] <inf> thread_analyzer:  sysworkq            : STACK: unused 1080 usage 968 / 2048 (47 %); CPU: 0 %
[00:24:15.954,772] <inf> thread_analyzer:  MPSL signal         : STACK: unused 576 usage 448 / 1024 (43 %); CPU: 0 %
[00:24:15.954,833] <inf> thrU: 0 %
[00:24:15.954,925] <inf> thread_analyzer:  idle 00             : STACK: unused 216 usage 104 / 320 (32 %); CPU: 97 %
[00:24:15.955,322] <inf> thread_analyzer:  main                : STACK: unused 1592 usage 456 / 2048 (22 %); CPU: 0 %
[00:24:16.061,981] <dbg> bt_conn.bt_conn_prepare_events: 
[00:24:16.062,011] <dbg> bt_conn.conn_prepare_events: Adding conn 0x20002d90 to poll list
[00:24:16.062,561] <dbg> bt_conn.bt_conn_prepare_events: 
[00:24:16.062,561] <dbg> bt_conn.conn_prepare_events: Adding conn 0x20002d90 to poll list
[00:24:16.063,171] <dbg> bt_conn.bt_conn_prepare_events: 
[00:24:16.063,171] <dbg> bt_conn.conn_prepare_events: Adding conn 0x20002d90 to poll list
[00:24:16.063,842] <dbg> bt_conn.bt_conn_prepare_events: 
[00:24:16.063,842] <dbg> bt_conn.conn_prepare_events: Adding conn 0x20002d90 to poll list
[00:24:16.064,514] <dbg> bt_conn.bt_conn_prepare_events: 
[00:24:16.064,514] <dbg> bt_conn.conn_prepare_events: Adding conn 0x20002d90 to poll list
[00:24:16.109,466] <dbg> bt_conn.bt_conn_prepare_events: 
[00:24:16.109,497] <dbg> bt_conn.conn_prepare_events: Adding conn 0x20002d90 to poll list
[00:24:16.110,046] <dbg> bt_conn.bt_conn_prepare_events: 
[00:24:16.110,046] <dbg> bt_conn.conn_prepare_events: Adding conn 0x20002d90 to poll list
[00:24:16.110,656] <dbg> bt_conn.bt_conn_prepare_events: 
[00:24:16.110,656] <dbg> bt_conn.conn_preparm
[00:24:16.111,267] <dbg> bt_conn.bt_conn_prepare_events: 
[00:24:16.111,297] <dbg> bt_conn.conn_prepare_events: Adding conn 0x20002d90 to poll list
[00:24:16.111,358] <dbg> bt_conn.bt_conn_set_state: disconnected -> connect-adv
[00:24:16.111,389] <dbg> bt_conn.bt_conn_ref: handle 0 ref 1 -> 2
[00:24:16.111,907] <dbg> bt_conn.bt_conn_prepare_events: 
[00:24:16.111,907] <dbg> bt_conn.conn_prepare_events: Adding conn 0x20002d90 to poll list
[00:24:16.111,968] <wrn> bt_hci_core: opcode 0x2039 status 0x09
[00:24:16.111,968] <err> bt_adv: Failed to start advertiser
[00:24:16.111,968] <dbg> bt_conn.bt_conn_set_state: connect-adv -> disconnected
[00:24:16.111,999] <dbg> bt_conn.bt_conn_unref: handle 0 ref 2 -> 1
[00:24:16.111,999] <dbg> bt_conn.bt_conn_unref: handle 0 ref 1 -> 0
**[00:24:16.111,999] <err> bt_mesh_adv_ext: Advertising failed: err -111**
[00:24:16.112,030] <wrn> bt_mesh_gatt: Fam
[00:24:16.129,028] <dbg> app.main: Herald Relay main thread still running
[00:24:16.129,028] <dbg> app.main: Publishing presence message...
[00:24:18.129,119] <dbg> app.main: Herald Relay main thread still running
[00:24:20.129,211] <dbg> app.main: Herald Relay main thread still running
[00:24:20.955,413] <inf> thread_analyzer: Thread analyze:

Environment (please complete the following information):

• OS: MacOS
• Toolchain: Zephyr version: 2.7.99 (/opt/nordic/ncs/v1.9.1/zephyr), build: v2.7.99-ncs1-1
• Commit SHA or Version used: 2.7.99

Additional context
BT_CENTRAL setting merged in from /config/receiver.conf in the CMakeLists.txt file for the relay app.
App is based on the light server sample.

[carlescufi]

cc @cvinayak

[cvinayak]

@adamfowleruk You are using the nRF Connect SDK supplied SoftDevice Controller for which you can report the issue here: https://devzone.nordicsemi.com/

My guess, would try to increase CONFIG_BT_MAX_CONN and check

[carlescufi]

This is an nRF Connect SDK issue as mentioned by @cvinayak.