NRF52840 Openthread Radio Coprocessor (RCP) through SPI

[MauriceWillemsen]

Hello,

We are using Raspberry Pi + NRF52840 as Borderrouter for Openthread using Radio Coprocessor design.

However we are facing stability issues on the RCP where it resets regularly, making our network unstable.

The RCP image on the NRF52840 is built with https://github.com/openthread/ot-nrf528xx which is still based on NRF5 sdk. This had the option for communication over SPI.

We are investigating to move to newer updated firmware based on the nrf connect sdk, as the coprocessor design is there as a sample within nrf connect sdk. https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/samples/openthread/coprocessor/README.html

However this doesn't seem to support communication over SPI, only UART or USB. As we are bound with our hardware to the SPI interface of the raspberry pi, we cannot switch.

Is there a way we could make this work again over SPI using nrf connect sdk?

[Hieu]

Hello MauriceWillemsen,

Unfortunately, there is no built-in support for SPI backend on the NCS OpenThread coprocessor sample. Do you have a Nordic sales contact? If this feature is critical for you, perhaps you can start a conversation with our sales contact to see what options we have.

Hieu

[MauriceWillemsen]

Hello,

Okay so there is no SPI available. 

We are trying to see if the switch to UART is worth the hardware upgrade of our PCBs.

We made a test with new dev boards: 

-- NRF52840 USB Dongle

-- NRF52840DK development kit.

With NCS v2.9.1

we made a built on coprocessor example:

nrf/samples/openthread/coprocessor

west build -p always -b nrf52840dk_nrf52840

west build -p always -b nrf52840dongle_nrf52840

The dongle we run on a raspberry pi with:

sudo ot-daemon -d 2 'spinel+hdlc+uart:///dev/ttyACM0' --verbose

This works perfect. No more stability issues on RCP. No logs on 'TX timeout' or 'RCP failure detected' 

ot-daemon-ncs[4166]: Running OPENTHREAD/thread-reference-20230706; POSIX; Apr 16 2025 14:03:06
ot-daemon-ncs[4166]: Thread version: 4
ot-daemon-ncs[4166]: Thread interface: wpan0
ot-daemon-ncs[4166]: RCP version: OPENTHREAD/ncs-thread-reference-20241002; Zephyr; Apr 22 2025 16:34:00

The development kit we run on raspberry pi with:

sudo ot-daemon -d 2 'spinel+hdlc+uart:///dev/serial0' --verbose

We activated serial uart on the raspberry pi

This mostly is not starting communication with the RCP. Or it fails quite soon, after some commands on ot-ctl:

ot-daemon-ncs[4166]: Running OPENTHREAD/thread-reference-20230706; POSIX; Apr 16 2025 14:03:06
ot-daemon-ncs[4166]: Thread version: 4
ot-daemon-ncs[4166]: Thread interface: wpan0
ot-daemon-ncs[4166]: RCP version: OPENTHREAD/ncs-thread-reference-20241002; Zephyr; Apr 22 2025 16:34:00
ot-daemon-ncs[4166]: 00:00:03.116 [W] Platform------: Daemon read: Connection reset by peer
ot-daemon-ncs[4166]: 00:00:05.183 [W] Platform------: Daemon read: Connection reset by peer
ot-daemon-ncs[4166]: 00:00:26.832 [W] Platform------: Wait for response timeout
ot-daemon-ncs[4166]: 00:00:26.832 [W] Platform------: RCP failure detected
ot-daemon-ncs[4166]: 00:00:26.832 [W] Platform------: Trying to recover (1/2)
ot-daemon-ncs[4166]: 00:00:28.835 [W] Platform------: Wait for response timeout
ot-daemon-ncs[4166]: 00:00:30.837 [W] Platform------: Wait for response timeout
ot-daemon-ncs[4166]: 00:00:30.837 [W] Platform------: RCP failure detected
ot-daemon-ncs[4166]: 00:00:30.837 [W] Platform------: Trying to recover (2/2)
ot-daemon-ncs[4166]: 00:00:32.839 [W] Platform------: Wait for response timeout
ot-daemon-ncs[4166]: 00:00:34.842 [W] Platform------: Wait for response timeout
ot-daemon-ncs[4166]: 00:00:34.842 [W] Platform------: RCP failure detected
ot-daemon-ncs[4166]: 00:00:34.842 [C] Platform------: Too many rcp failures, exiting
ot-daemon-ncs[4166]: 00:00:34.842 [C] Platform------: RecoverFromRcpFailure() at radio_spinel_impl.hpp:2075: Failure



What am i doing wrong. Is the UART connection between RCP and RPi correct?

P0.06 to RPI GPIO15

P0.08 to RPI GPIO14

GND to GND

There is some communication, sometimes it starts and connects to the network, but than fails with RCP failures. Sometimes it can read RCP version, but than fails. Mostly it doesn't start.

For our hardware boards, we want to do the changes to support UART, but we need to have it as stable as the USB version. But we encounter these issues for now.

[MauriceWillemsen]

Okay, I got it to work, apparantely is used hardware flow control and I needed to connect for UART:

GPIO14 ︎ P0.08 (TX)

GPIO15 ︎ P0.06 (RX)

GPIO17 ︎ P0.07 (CTS)

GPIO16 ︎ P0.05 (RTS)

This is however nowhere in the documentation, would be good to add pinout overview on the documentation, how to connect RPi to nrf52840DK

But the question that remains for me:

I cannot give the RCP a reset through a pin, it seems like P0.18/Reset is configured as GPIO pin instead of reset pin on the NRF52840 side. 

How can I adapt the sample, to use this pin as reset pin, so I can reset the RCP from RPi

[Hieu]

Hi,

It's great that you figured out what is wrong with the communication, and even better that you are happy with the performance.

Regarding using P0.18 as the reset pin, you will need to enable CONFIG_GPIO_AS_PINRESET. The simplest way is to do so in prj.conf.

Hieu

[MauriceWillemsen]

that config seems deprecated in NCS-v2.9.1

tried it as well with:

&uicr {
gpio-as-nreset;
};

This should be active on the coprocessor

But it seems like a issue with the Development board.

As well I have issues on higher speeds than 115200. Might as well be due to the dev board setup with wires. 

We will change our PCB and add communication wires for uart. We will see if that will be more steady, and we can increase the speed.