Dynamically configurable central/peripheral role

[MartinZ]

nRF52832 & NCS v2.6.1

I merged the NUS central and NUS peripheral FW into a single one where the user calls appropriate initialization functions to activate whether central or peripheral role.

For this to work, I had to include both CONFIG_BT_CENTRAL=y and CONFIG_BT_PERIPHERAL=y in my prj.conf.

The system works, but I get the following warning on the peripheral device whenever it connects to central:

<wrn> bt_hci_core: opcode 0x200a status 0x0d

I found out that removing CONFIG_BT_CENTRAL=y (and commenting out all central related code) makes the warning disappear.

How to avoid this message? Can I simply ignore it?

[Vidar Berg]

Hello,

The opcode is SDC_HCI_OPCODE_CMD_LE_SET_ADV_ENABLE to start the advertiser and the status indicates CONNECTION REJECTED DUE TO LIMITED
RESOURCES (0x0D). This suggests that you have already reached the max. number of peripheral connections supported by the controller.

The number of peripheral connections that can be supported are automatically reduced when BT_CENTRAL is enabled: https://github.com/nrfconnect/sdk-nrf/blob/d3a8699e25991a8f624603da278272728c913657/subsys/bluetooth/Kconfig#L23 

You can try to incrase the CONFIG_BT_CTLR_SDC_PERIPHERAL_COUNT value in your project configuration file to see if the problem persits.

Best regards,

Vidar

[MartinZ]

When I increase CONFIG_BT_CTLR_SDC_PERIPHERAL_COUNT from default 1 to 2, the build fails:

In file included from C:/ncs/v2.6.1/zephyr/include/zephyr/toolchain.h:50,
                 from C:/ncs/v2.6.1/zephyr/include/zephyr/kernel_includes.h:23,
                 from C:/ncs/v2.6.1/zephyr/include/zephyr/kernel.h:17,
                 from C:/ncs/v2.6.1/nrf/subsys/bluetooth/controller/hci_driver.c:7:
C:/ncs/v2.6.1/zephyr/include/zephyr/toolchain/gcc.h:87:36: error: static assertion failed: ""
   87 | #define BUILD_ASSERT(EXPR, MSG...) _Static_assert(EXPR, "" MSG)
      |                                    ^~~~~~~~~~~~~~
C:/ncs/v2.6.1/nrf/subsys/bluetooth/controller/hci_driver.c:55:1: note: in expansion of macro 'BUILD_ASSERT'
   55 | BUILD_ASSERT(!IS_ENABLED(CONFIG_BT_CENTRAL) ||
      | ^~~~~~~~~~~~

Then I also increased CONFIG_BT_MAX_CONN from default 2 to 3 and was able to build. But I still get the same warning.

Please note that the peripheral-central connection works despite this message, so I don't really understand what this message is telling. Is it a simple indication that the limit has been reached? If so, why didn't I get it on a peripheral-only project where the limit was 1 connection as well?

Also, the CONFIG_BT_CTLR_SDC_PERIPHERAL_COUNT description says:

Number of concurrent peripheral roles defines how many simultaneous connections can be created with the device working as a peripheral.

So I believe this should be left to 1 since I only want a single connection from a peripheral device to the central.

[Vidar Berg]

The warning indicates that the advertiser failed to start, which isn't a problem if you are already connected to the central. But it is not clear why the advertiser is being started when you establish the connection. Is bt_le_adv_start() being called in multiple places in your version?

[MartinZ]

No, I only call bt_le_adv_start() once in the initialization function that puts the device into peripheral role.

I temporarily added a log output to bt_le_adv_start() to see whenever it gets called. And it indeed only gets called once at start as described above.

[Vidar Berg]

Thanks for confirming. I was able to reproduce this issue with SDK v2.7.0. It turns out that the host attempts to restart advertising upon connection to allow for another peripheral connection when BT_MAX_CONN > 1. However, this should not happen when CONFIG_BT_CTLR_SDC_PERIPHERAL_COUNT == 1. I will report this internally.

Update: The advertisement resume feature has been deprecated in upstream zephyr: https://github.com/zephyrproject-rtos/zephyr/commit/8cfad44852845cd30336d40f61dade69ab4357db#diff-8cadc78f71e77935aca30e96bc8baebc6f8a7b87c5c3c79f6f899cf92e9da2e8 

[MartinZ]

Thank you for your feedback. In the meantime, is it safe to just ignore this warning?