Bluetooth Low Energy Remote Procedure Call

The nRF Connect SDK supports Bluetooth® Low Energy (LE) stack serialization. The full Bluetooth LE stack can run on another device or CPU, such as the nRF5340 DK network core using Remote procedure call library (nRF RPC).

Network core

The Bluetooth: Host for nRF RPC Bluetooth Low Energy sample is designed specifically to enable the Bluetooth LE stack functionality on a remote MCU (for example, the nRF5340 network core) using the Remote procedure call library (nRF RPC). You can program this sample to the network core to run standard Bluetooth Low Energy samples on nRF5340. You can use either the SoftDevice Controller or the Zephyr Bluetooth LE Controller for this sample.

Application core

To use the Bluetooth LE stack through nRF RPC, an additional configuration is needed. When building samples for the application core, enable the CONFIG_BT_RPC_STACK to run the Bluetooth LE stack on the network core. This option builds Bluetooth: Host for nRF RPC Bluetooth Low Energy automatically as a child image. For more details, see: Building and programming a sample.

Open a command prompt in the build folder of the application sample and enter the following command to build the application for the application core, with Bluetooth: Host for nRF RPC Bluetooth Low Energy as child image:

west build -b nrf5340dk_nrf5340_cpuapp -- -DCONFIG_BT_RPC_STACK=y

Requirements

Some configuration options related to Bluetooth LE must be the same on the host (network core) and client (application core). Set the following options in the same way for the Bluetooth: Host for nRF RPC Bluetooth Low Energy and application core sample:

• CONFIG_BT_CENTRAL

• CONFIG_BT_PERIPHERAL

• CONFIG_BT_FILTER_ACCEPT_LIST

• CONFIG_BT_USER_PHY_UPDATE

• CONFIG_BT_USER_DATA_LEN_UPDATE

• CONFIG_BT_PRIVACY

• CONFIG_BT_SCAN_WITH_IDENTITY

• CONFIG_BT_REMOTE_VERSION

• CONFIG_BT_SMP

• CONFIG_BT_CONN

• CONFIG_BT_REMOTE_INFO

• CONFIG_BT_FIXED_PASSKEY

• CONFIG_BT_SMP_APP_PAIRING_ACCEPT

• CONFIG_BT_EXT_ADV

• CONFIG_BT_OBSERVER

• CONFIG_BT_ECC

• CONFIG_BT_DEVICE_NAME_DYNAMIC

• CONFIG_BT_SMP_SC_PAIR_ONLY

• CONFIG_BT_PER_ADV

• CONFIG_BT_PER_ADV_SYNC

• CONFIG_BT_MAX_PAIRED

• CONFIG_BT_SETTINGS_CCC_LAZY_LOADING

• CONFIG_BT_BROADCASTER

• CONFIG_BT_SETTINGS

• CONFIG_BT_MAX_CONN

• CONFIG_BT_ID_MAX

• CONFIG_BT_EXT_ADV_MAX_ADV_SET

• CONFIG_BT_DEVICE_NAME_MAX

• CONFIG_BT_DEVICE_NAME_MAX

• CONFIG_BT_PER_ADV_SYNC_MAX

• CONFIG_BT_DEVICE_NAME

• CONFIG_CBKPROXY_OUT_SLOTS on one core must be equal to CONFIG_CBKPROXY_IN_SLOTS on the other.

To keep all the above configuration options in sync, create an overlay file that is shared between the application and network core. Then, you can invoke build command like this:

west build -b board -- -DOVERLAY_CONFIG=my_overlay_file.conf

API documentation

This library does not define a new API. Instead, it uses Zephyr’s Bluetooth API. The nRF Connect SDK currently supports serialization of the following:

• Generic Access Profile (GAP)

• Connection Management

• Generic Attribute Profile (GATT)

• Bluetooth Cryptography

The behavior of the implementation is almost the same as Zephyr’s with the following exceptions:

• The latency is longer because of the overhead for exchanging messages between cores.

• The bt_gatt_cancel() function is not implemented.

• The flags field of the bt_gatt_subscribe_params structure is atomic, so it cannot be correctly handled by the nRF RPC. The library implements the following workaround for it:

  • All flags are sent to the network core when either the bt_gatt_subscribe() or bt_gatt_resubscribe() function is called. This covers most of the cases, because the flags are normally set once before those functions calls.

  • If you want to read or write the flags after the subscription, you have to call bt_rpc_gatt_subscribe_flag_set(), bt_rpc_gatt_subscribe_flag_clear() or bt_rpc_gatt_subscribe_flag_get().