nRF RPC: Protocols serialization server

The Protocols serialization server sample runs full Bluetooth® LE and OpenThread stacks, and it exposes selected functions from these stacks over UART.

Requirements

The sample supports the following development kits for testing the network status:

Hardware platforms	PCA	Board name	Board target
nRF54L15 PDK	PCA10156	nrf54l15pdk	nrf54l15pdk/nrf54l15/cpuapp
nRF54L15 DK	PCA10156	nrf54l15dk	nrf54l15dk/nrf54l15/cpuapp
nRF52840 DK	PCA10056	nrf52840dk	nrf52840dk/nrf52840

To test the sample, you also need another device running the Protocols serialization client sample.

For testing the Bluetooth LE API serialization, you also need to have the nRF Connect for Mobile app installed on your smartphone or tablet.

Overview

The Protocols serialization server sample implements the server part of the serialization of OpenThread and Bluetooth LE API calls between two devices that communicate with each other using the UART interface. The sample uses the Remote procedure call library (nRF RPC) and CBOR encoding to serialize function calls.

Configuration

See Configuring and building for information about how to permanently or temporarily change the configuration.

Snippets

The following snippets are available:

• ble - Enables the server part of the Bluetooth LE RPC. Also enables the Bluetooth LE Nordic UART Service.

• coex - Enables the MPSL software coexistence implementation on the server device.

• debug - Enables debugging the sample by enabling __ASSERT() statements globally and verbose logging.

• log_rpc - Enables logging over RPC.

• openthread - Enables the server part of the OpenThread RPC.

User interface

nRF52840 DKnRF54L15 DK

Button 4:

• When the log_rpc snippet is enabled: triggers a fatal error.

  This is used for testing the crash log feature.

• Otherwise: not available.

Building and running

This sample can be found under samples/nrf_rpc/protocols_serialization/server in the nRF Connect SDK folder structure.

To build the sample, follow the instructions in Building an application for your preferred building environment. See also Programming an application for programming steps and Testing and optimization for general information about testing and debugging in the nRF Connect SDK.

Note

When building repository applications in the SDK repositories, building with sysbuild is enabled by default. If you work with out-of-tree freestanding applications, you need to manually pass the --sysbuild parameter to every build command or configure west to always use it.

You can modify the list of enabled features, which by default includes Bluetooth LE support and debug logs.

Testing

After building the Protocols serialization server sample and programming it to your development kit, connect it to a second device running the Protocol serialization client sample to test either the Bluetooth LE or OpenThread functionality.

Connecting the client and server samples

The client and server devices are connected using two UART peripherals. In the protocols serialization samples, one peripheral is used for shell and logging purposes, similarly to other applications and samples, while the other peripheral is used for sending OpenThread and Bluetooth LE remote procedure calls (RPCs).

nRF52840 DKnRF54L15 DK

By default, the nRF52840 DK uses the uart0 peripheral for shell and logging purposes, and the uart1 peripheral for sending OpenThread and Bluetooth remote procedure calls (RPCs).

The uart1 peripheral is configured to use the following pins:

Server	Client	Function on server
P1.1	P1.2	RX
P1.2	P1.1	TX
P1.3	P1.4	RTS (hardware flow control)
P1.4	P1.3	CTS (hardware flow control)
GND	GND	Ground

To enable the communication between the client and the server devices, connect the pins on the two nRF52840 DKs using jumper wires. The following illustration demonstrates the pin connections:

Testing Bluetooth LE API serialization

Complete the following steps to test Bluetooth LE API serialization:

1. Connect to both kits with a terminal emulator (for example, nRF Connect Serial Terminal). See Testing and optimization for the required settings and steps.

2. Reboot both devices at the same time by pressing the RESET button on each DK.

3. Wait a few seconds until you see a message similar to the following on both terminal emulators:

   [00:00:00.842,862] <inf> nrf_rpc_host: RPC client ready
   

   This indicates that the communication between the devices has been initialized properly.

4. Run the following command on the client’s terminal emulator to start Bluetooth LE advertising:

   uart:~$ bt init
   uart:~$ bt advertise on
   

5. Start the nRF Connect for Mobile app on your smartphone or tablet.

6. Connect to the client device from the nRF Connect app.

   The device is advertising as Nordic_UART_Service.

7. Observe a message similar to the following on the client’s terminal emulator:

   LE conn param updated: int 0x0027 lat 0 to 42
   

8. Send data over the RX characteristic of the UART service using the nRF Connect app.

9. Observe a message similar to the following on the client’s terminal emulator:

   bt_nus: on_receive: Received data, handle 0, conn 0x200023c4
   

Testing OpenThread API serialization

Complete the following steps to test OpenThread API serialization:

1. Connect to both kits with a terminal emulator (for example, nRF Connect Serial Terminal). See Testing and optimization for the required settings and steps.

2. Reboot both devices at the same time using the RESET button on each DK.

3. Wait a few seconds until you see a message similar to the following on both terminal emulators:

   uart:~$ [00:00:03.392,517] <dbg> NRF_RPC: nrf_rpc_init: Done initializing nRF RPC module
   

   This indicates that the communication between the devices has been initialized properly.

4. Run the following command on the client’s terminal emulator to bring up the OpenThread interface on the server device:

   uart:~$ ot ifconfig up
   Done
   [00:02:28.980,041] <dbg> NRF_RPC: cmd_ctx_alloc: Command context 0 allocated
   [00:02:28.980,102] <dbg> NRF_RPC: nrf_rpc_cmd_common: Sending command 0x00 from group 0x01
   [00:02:28.980,133] <dbg> nrf_rpc_uart: send: Sending frame
                                          80 00 ff 01 01 f6
   ...
   

5. Run the following command on the client’s terminal emulator to bring up the corresponding Zephyr network interface on the client device:

   uart:~$ net iface up 1
   Interface 1 is up
   

6. Verify that the Zephyr network interface has been automatically configured with OpenThread’s link-local address:

   uart:~$ ot ipaddr
   fe80:0:0:0:6c26:956a:813:1e33
   Done
   ...
   
   uart:~$ net iface  show
   
   Interface net0 (0x200012c8) (<unknown type>) [1]
   =========================================
   MTU       : 1280
   Flags     : NO_AUTO_START,IPv6,NO_ND,NO_MLD
   Device    : ot_rpc (0x2b748)
   IPv6 unicast addresses (max 5):
         fe80::6c26:956a:813:1e33 autoconf preferred infinite
   

7. Start Thread and become a leader:

   uart:~$ ot thread start
   Done
   ...
   
   uart:~$ ot state leader
   Done
   

8. Verify that the Zephyr network interface has automatically received OpenThread’s mesh-local addresses:

   uart:~$ net iface  show
   
   Interface net0 (0x200012c8) (<unknown type>) [1]
   =========================================
   MTU       : 1280
   Flags     : NO_AUTO_START,IPv6,NO_ND,NO_MLD
   Device    : ot_rpc (0x2b748)
   IPv6 unicast addresses (max 5):
         fe80::6c26:956a:813:1e33 autoconf preferred infinite
         fdde:ad00:beef:0:e503:abfd:1c8d:2664 autoconf preferred infinite meshlocal
         fdde:ad00:beef::ff:fe00:fc00 autoconf preferred infinite meshlocal
   

   This happens because the client registers a notification callback for OpenThread state changes at the server device and it continuously refreshes the client’s IPv6 address list when that changes on the server side.

9. Retrieve the operational dataset of the Thread network:

   uart:~$ ot dataset active -x
   0e080000000000000000000300000b35060004001fffe00208dead00beef00cafe0708fddead00beef00000510f7893f15a55d8adeacad288c38bf32cc030a4f70656e546872656164010240120410d48d777a474f80e61aa5680de764bd6d0c0402a0f7f8
   Done
   

10. To send a UDP packet to a peer device and UDP port 5555, run the following command:

    uart:~$ net udp send fe80:0:0:0:6c26:956a:813:1e34 5555 AAAA
    Message sent
    

11. To open the UDP port 5555 and listen for incoming UDP datagrams from peer devices, run the following command:

    uart:~$ net udp bind fe80:0:0:0:6c26:956a:813:1e33 5555
    

Note that all IPv6 addresses shown here are just examples and will be replaced with the actual IPv6 addresses of the peer devices.

Dependencies

This sample uses the following sdk-nrfxlib library:

• Remote procedure call library (nRF RPC)