The sample is based on Zephyr’s OpenThread Co-Processor sample. However, it customizes Zephyr’s sample to fulfill the nRF Connect SDK requirements (for example, by increasing the stack size dedicated for the user application), and also extends it with features such as:
Increased Mbed TLS heap size.
Lowered main stack size to increase user application space.
No obsolete configuration options.
Vendor hooks for co-processor architecture allowing users to extend handled properties by their own, customized functionalities.
Thread 1.2 features.
The sample supports the following development kits for testing the network status:
To test the sample, you need at least one development kit. You can use additional development kits programmed with the Co-processor sample for testing network joining.
Moreover, the sample requires a Userspace higher layer process running on your device to communicate with the MCU co-processor part.
This sample uses
ot-cli as reference.
The sample demonstrates using a co-processor target on the MCU to communicate with ot-cli on Unix-like operating system. According to the co-processor architecture, the MCU part must cooperate with user higher layer process to establish the complete full stack application. The sample shows how to set up the connection between the co-processor and the host.
By default, this sample uses Spinel logging backend for sending log messages to the host device using the Spinel protocol.
This is a useful feature, because it does not require separate interfaces to communicate with the co-processor through the Spinel protocol and collect log messages.
Moreover, using the Spinel logging backend (by setting
CONFIG_LOG_BACKEND_SPINEL) does not exclude using another backend like UART or RTT at the same time.
By default, the log levels for all modules are set to critical to not engage the microprocessor in unnecessary activities.
To make the solution flexible, you can change independently the log levels for your modules, for the whole Zephyr system, and for OpenThread.
logging.conf configuration file located in the
snippets/logging/ directory as reference for this purpose.
All the interactions with the application are handled using serial communication.
You can also use your own application, provided that it supports the Spinel communication protocol.
This sample has Hardware Flow Control mechanism enabled by default in serial communication. When enabled, it allows devices to manage transmission by informing each other about their current state, and ensures more reliable connection in high-speed communication scenarios. In addition, the Co-processor sample reconfigures the baud rate to 1000000 bit/s by default.
The Co-processor sample enables a diagnostic module in a similar way as described in the Diagnostic module section of the Thread: CLI sample documentation. However, the Co-processor and CLI samples use different commands for the module, as described in the Testing section.
See Configuring your application for information about how to permanently or temporarily change the configuration.
Check and configure the following library option that is used by the sample:
CONFIG_OPENTHREAD_COPROCESSOR_RCP- Selects the RCP architecture for the sample.
The sample provides predefined Snippets for typical use cases, and to activate sample extensions.
You can find the snippets in the
snippets directory of the sample.
Specify the corresponding snippet names in the SNIPPET option when building with CMake, or as a
-S argument when using west.
For more information about using snippets, see Using Snippets in the Zephyr documentation.
The following snippets are available:
debug- Enables debugging the Thread sample by enabling
logging- Enables logging using RTT. For additional options, refer to RTT logging.
usb- Enables emulating a serial port over USB for Spinel communication with the host.
You can add support for the nRF21540 front-end module to this sample by using one of the following options, depending on your hardware:
Build the sample for one board that contains the nRF21540 FEM, such as nrf21540dk_nrf52840.
Manually create a devicetree overlay file that describes how FEM is connected to the nRF5 SoC in your device. See Set devicetree overlays for different ways of adding the overlay file.
Provide nRF21540 FEM capabilities by using a shield, for example the nRF21540 EK shield that is available in the nRF Connect SDK. In this case, build the project for a board connected to the shield you are using with an appropriate variable included in the build command, for example
SHIELD=nrf21540ek. This variable instructs the build system to append the appropriate devicetree overlay file.
To build the sample in the nRF Connect for VS Code IDE for an nRF52840 DK with the nRF21540 EK attached, add the shield variable in the build configuration’s Extra CMake arguments and rebuild the build configuration. For example:
See nRF Connect for VS Code extension pack documentation for more information.
To build the sample from the command line for an nRF52840 DK with the nRF21540 EK attached, use the following command within the sample directory:
west build -b nrf52840dk_nrf52840 -- -DSHIELD=nrf21540ek
See Programming nRF21540 EK for information about how to program when you are using a board with a network core, for example nRF5340 DK.
Each of these options adds the description of the nRF21540 FEM to the devicetree. See Working with RF front-end modules for more information about FEM in the nRF Connect SDK.
To add support for other front-end modules, add the respective devicetree file entries to the board devicetree file or the devicetree overlay file.
Make sure to enable the OpenThread stack before building and testing this sample. See Thread for more information.
This sample can be found under
samples/openthread/coprocessor in the nRF Connect SDK folder structure.
To build the sample with Visual Studio Code, follow the steps listed on the How to build an application page in the nRF Connect for VS Code extension documentation. See Building and programming an application for other building and programming scenarios and Testing and debugging an application for general information about testing and debugging in the nRF Connect SDK.
After building the sample and programming it to your development kit, complete the following steps to test it:
Connect the development kit’s SEGGER J-Link USB port to the PC USB port with a USB cable.
Get the kit’s serial port name (for example,
Run and configure ot-cli as described in OpenThread POSIX applications.
From this point, you can follow the Testing instructions in the CLI sample by removing the ot prefix for each command.
This sample uses the following Zephyr libraries: