Zephyr + OpenThread Radio Co-Processor (RCP)

[Louis]

I successfully used the OpenThread nRF52840 USB dongle support provided by the OpenThread project to implement the radio coprocessor functionality.

However, I had no success whatsoever trying to do the same with the release 1.7 of the nRF Connect SDK.

west build -b nrf52840dongle_nrf52840 -- -DOVERLAY_CONFIG="overlay-usb.conf;overlay-rcp.conf;overlay-logging.conf;overlay-vendor_hook.conf"

The border router reports:

user.crit otbr-agent[4788]: [CRIT]-PLAT----: HandleRcpTimeout() at /usr/src/debug/ot-br-posix/0.2+gitAUTOINC+5de1086daa-r0/git/third_party/openthread/repo/src/lib/spinel/radio_spinel_impl.hpp:2169: RadioSpinelNoResponse

when it tries to talk to the dongle. Indeed, I also tried to port the nRF5340DK to the design targeted at a physical UART interface with the same result and I do see outgoing requests which are never answered by the RCP based on what I see on a scope. Same result with different baud rates with or without hardware flow control.

Is the functionality supported within the zephyr-based nRF Connect SDK and are there plans to also port the functionality to the nRF5340? Thanks.

[Sigurd Hellesvik]

Hi Louis

It should bepossible to run the RCP on the nRF5340.

But before porting the RCP, let's make sure it works on either of the supported nRF52840 Dongle or nRF52840DK.
For the correct configurations for using the coprocessor with the OpenThread Border Router, see Configuring a radio co-processor.

Are you able to make the dongle work with these  configurations?

Regards,
Sigurd Hellesvik

[Louis]

Thanks,

overlay-thread_1_2.conf overlay-usb.conf was certainly missing, but still the same result with the nRF52840 Dongle repeating the exact steps documented here. We just ordered the nRF52840DK. 

[Sigurd Hellesvik]

Hi

Are you using the same commit id for the Border Router as explained in the guide?

Regards,
Sigurd Hellesvik

[Louis]

Sorry for the late response. I built the border from yocto using meta-oniro. I first updated to the new (1.8) release of the nRF Connect SDK. The dongle started to answer, but complained that the API were not compatible. So, I also upgraded to a newer openthread release on the router side and managed to get both the nRF52840 USB dongle and nRF52840DK (USB and UART) up and running with the border router. I tried to add support for the nRF5340DK:

--- /opt/nrfconnect-sdk/nrf/samples/openthread/coprocessor/boards/nrf5340dk_nrf5340_cpuapp.overlay	1970-01-01 00:00:00.000000000 +0000
+++ ./coprocessor/boards/nrf5340dk_nrf5340_cpuapp.overlay	2022-01-25 12:32:53.177692122 +0000
@@ -0,0 +1,24 @@
+&uart1 {
+    status = "okay";
+    current-speed = <460800>;
+    status = "okay";
+    hw-flow-control;
+    rts-pin = <37>;
+    cts-pin = <36>;
+    tx-pin = <33>;
+    rx-pin = <32>;
+    cts-pull-up;
+    rx-pull-up;
+};
+
+/ {
+	chosen {
+		zephyr,ot-uart = &uart1;
+	};
+};

and the complication:

west build -p always -b nrf5340dk_nrf5340_cpuapp  -- -DOVERLAY_CONFIG="overlay-rcp.conf $ZEPHYR_BASE/../nrf/samples/openthread/cli/overlay-thread_1_2.conf" -DCONFIG_XOROSHIRO_RANDOM_GENERATOR=y

but compilation fails:

/opt/nrfconnect-sdk/zephyr/drivers/ieee802154/ieee802154_nrf5.c: In function 'nrf5_stop':
/opt/nrfconnect-sdk/zephyr/drivers/ieee802154/ieee802154_nrf5.c:659:6: warning: implicit declaration of function 'nrf_802154_sleep_if_idle'; did you mean 'nrf_802154_sleep'? [-Wimplicit-function-declaration]
  659 |  if (nrf_802154_sleep_if_idle() != NRF_802154_SLEEP_ERROR_NONE) {
      |      ^~~~~~~~~~~~~~~~~~~~~~~~
      |      nrf_802154_sleep
/opt/nrfconnect-sdk/zephyr/drivers/ieee802154/ieee802154_nrf5.c:659:36: error: 'NRF_802154_SLEEP_ERROR_NONE' undeclared (first use in this function); did you mean 'NRF_802154_RX_ERROR_NONE'?
  659 |  if (nrf_802154_sleep_if_idle() != NRF_802154_SLEEP_ERROR_NONE) {
      |                                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                    NRF_802154_RX_ERROR_NONE
/opt/nrfconnect-sdk/zephyr/drivers/ieee802154/ieee802154_nrf5.c:659:36: note: each undeclared identifier is reported only once for each function it appears in
/opt/nrfconnect-sdk/zephyr/drivers/ieee802154/ieee802154_nrf5.c: In function 'nrf5_receive_at':
/opt/nrfconnect-sdk/zephyr/drivers/ieee802154/ieee802154_nrf5.c:782:2: warning: implicit declaration of function 'nrf_802154_receive_at'; did you mean 'nrf_802154_receive'? [-Wimplicit-function-declaration]
  782 |  nrf_802154_receive_at(start - TXTIME_OFFSET_US, TXTIME_OFFSET_US, duration, channel, id);
      |  ^~~~~~~~~~~~~~~~~~~~~
      |  nrf_802154_receive
/opt/nrfconnect-sdk/zephyr/drivers/ieee802154/ieee802154_nrf5.c: In function 'nrf5_config_csl_period':
/opt/nrfconnect-sdk/zephyr/drivers/ieee802154/ieee802154_nrf5.c:787:2: warning: implicit declaration of function 'nrf_802154_receive_at_cancel'; did you mean 'nrf_802154_receive_failed'? [-Wimplicit-function-declaration]
  787 |  nrf_802154_receive_at_cancel(DRX_SLOT_PH);
      |  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |  nrf_802154_receive_failed
/opt/nrfconnect-sdk/zephyr/drivers/ieee802154/ieee802154_nrf5.c:790:2: warning: implicit declaration of function 'nrf_802154_csl_writer_period_set' [-Wimplicit-function-declaration]
  790 |  nrf_802154_csl_writer_period_set(period);
      |  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[354/396] Building C object zephyr/subsys/net/ip/CMakeFiles/subsys__net__ip.dir/net_if.c.obj
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: /usr/local/bin/cmake --build /home/workspace/coprocessor/build

Finally, it will compile from the main nRF Connect branch (overlay-thread_1_2.conf doesn't seems to be required anymore):

west build -p always -b nrf5340dk_nrf5340_cpuapp -- -DOVERLAY_CONFIG="overlay-rcp.conf" -DCONFIG_OPENTHREAD_THREAD_VERSION_1_2=y -DCONFIG_XOROSHIRO_RANDOM_GENERATOR=y

with a few warnings about missing declarations:

/home/workspace/coprocessor.main/src/nrf_802154_radio_wrapper.c: In function 'nrf_802154_radio_wrapper_auto_ack_get':
/home/workspace/coprocessor.main/src/nrf_802154_radio_wrapper.c:16:9: warning: implicit declaration of function 'nrf_802154_auto_ack_get'; did you mean 'nrf_802154_time_get'? [-Wimplicit-function-declaration]
   16 |  return nrf_802154_auto_ack_get();
      |         ^~~~~~~~~~~~~~~~~~~~~~~
      |         nrf_802154_time_get
/home/workspace/coprocessor.main/src/nrf_802154_radio_wrapper.c: In function 'nrf_802154_radio_wrapper_auto_ack_set':
/home/workspace/coprocessor.main/src/nrf_802154_radio_wrapper.c:21:2: warning: implicit declaration of function 'nrf_802154_auto_ack_set'; did you mean 'nrf_802154_ack_data_set'? [-Wimplicit-function-declaration]
   21 |  nrf_802154_auto_ack_set(enabled);
      |  ^~~~~~~~~~~~~~~~~~~~~~~
      |  nrf_802154_ack_data_set

but the co-processor remains dead silent (also tried UART over USB with the same result) as it was the case with the release 1.7 of nRF Connect.

[Sigurd Hellesvik]

Hi

I am trying to make the nRF5340DK work as RCP for a border router, but has not figured it out yet.
I hope to solve this out and return with an answer tomorrow or maybe Monday.

Regards,
Sigurd Hellesvik

[Sigurd Hellesvik]

Hi

It seems to build fine for me when i build for nrf5340dk_nrf5340_cpuapp_ns in v1.8.0.
Unfortunately, I do not have an OTBR at hand, so i can not check that it works with the Border Router.

Are you able to make it work when building as ns?

Regards,
Sigurd Hellesvik

[Louis]

Did you include the overlay-thread_1_2.conf configuration file from the cli sample?

west build -p always -b nrf5340dk_nrf5340_cpuapp_ns  -- -DOVERLAY_CONFIG="overlay-rcp.conf $ZEPHYR_BASE/../nrf/samples/openthread/cli/overlay-thread_1_2.conf" -DCONFIG_XOROSHIRO_RANDOM_GENERATOR=y

I can't get it to build using the secure and non-secure target with the thread 1.2  overlay which appears to be required as documented here. Also, I previously tried to remove the thread 1.2 overlay using the nRF52840DK as a target and again, the coprocessor wouldn't respond.

In fact, I think that OpenThread is broken on the nrf5340 with the 1.8 release of the SDK. Just to make sure, I just pulled a fresh install and tried to build the cli sample with different CI options as listed here and in some cases I'll get a successful build but no prompt at runtime or a plain compilation failure (as is the case with the thread 1.2 overlay). That seems rather surprising given that a compilation failure should translate into a CI pipeline failure. 

[Sigurd Hellesvik]

Hi

Yea, the border router needs a coprocessor with Thread 1.2 to work as far as I know.

Try to remove "CONFIG_IEEE802154_CSL_ENDPOINT=y" from the overlay-thread_1_2.conf and build again for the nRF5340dk_nrf5340_cpuapp_ns.

This config option is not set for the main branch either, so it might be fine.

Keep in mind removing a dependency like this could limit the features of the RCP.

Regards,
Sigurd Hellesvik

[Louis]

Thanks,

It does compile with

west build -p always -b nrf5340dk_nrf5340_cpuapp  -- -DOVERLAY_CONFIG="overlay-rcp.conf overlay-usb.conf $ZEPHYR_BASE/../nrf/samples/openthread/cli/overlay-thread_1_2.conf" -DCONFIG_XOROSHIRO_RANDOM_GENERATOR=y -DCONFIG_IEEE802154_CSL_ENDPOINT=n -DDTC_OVERLAY_FILE="usb.overlay"

but it still doesn't answer to the border router (secure on not, native or over USB UART). However, when selecting the secure target, I do see a failed assertion :

ASSERTION FAIL @ WEST_TOPDIR/zephyr/subsys/net/lib/openthread/platform/misc.c:36

but the corresponding line is obviously not not exactly useful...

[Sigurd Hellesvik]

Yesterday I got my Raspberry Pi back.

After some trying, I have been able to replicate the same errors as you see.
And I have not managed to fix the issue.

Indeed CSL is needed for the OTBR, so we can not remove this.

The build errors are results of the SDK not supporting this.
If you want to change this, you will have to make changes to the SDK.

The error for the nRF5340dk_nrf5340_cpuapp is most likely to the configuration warning found in the build log:

warning: NRF_802154_ENCRYPTION (defined at /home/bruk/ncs/zephyr/modules/hal_nordic/Kconfig:46,
/opt/nrf-connect-sdk/nrfxlib/nrf_802154/zephyr/Kconfig.nrfxlib:18, modules/hal_nordic/Kconfig:46)
was assigned the value 'y' but got the value 'n'. Check these unsatisfied dependencies:
((!CRYPTO_NRF_ECB && NRF_802154_RADIO_DRIVER && HAS_NORDIC_DRIVERS) || (!CRYPTO_NRF_ECB &&
NRF_802154_RADIO_DRIVER) || (!CRYPTO_NRF_ECB && NRF_802154_RADIO_DRIVER && HAS_NORDIC_DRIVERS && 0))
(=n). See http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_NRF_802154_ENCRYPTION.html
and/or look up NRF_802154_ENCRYPTION in the menuconfig/guiconfig interface. The Application
Development Primer, Setting Configuration Values, and Kconfig - Tips and Best Practices sections of
the manual might be helpful too.

I tried to find what caused this error, and tracked it down to being dependent on CONFIG_HAS_HW_NRF_RADIO_IEEE802154.
Likely, this is because it is the NET core that has the radio driver, and not the APP core.
One fix would be to tell the drivers to run on both processors, but you would have to figure out how to do this.
Another solution would be to run the whole coprocessor on the NET core. Im guessing the main issue with this would be to get the UART connections working correctly.

Either way, it is complcated.
I would recommend that you just use the nRF52840 for coprocessor instead. Will this work for you?

Regards,
Sigurd Hellesvik

[Louis]

I'd say that the nRF52840 in our plan "B" if not "C" here.  nRF5340 is the front-runner thanks to its better radio specs. I'd say it's acceptable, but please keep us posted on the developments for a possible support with the next release of the SDK. 

[Sigurd Hellesvik]

Hi

I did some looking around.
At this time, we have no plans for supporting NCP on the nRF5340.

If you need more from the radio of the NCP, it supports the nrf21540dk_nrf52840, using the nRF21540 for range extension.

Regards,
Sigurd Hellesvik