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. 

[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

[Louis]

Thanks,

Improoved RX sensitivity, not output power, was what we were looking for with the nrf5340. nRF21540 it will be,