nRF52840 OpenThread NCP with wpantund on Linux

[Jay]

Hi everyone,

I was wondering if the nRF52840 DK will have NCP OpenThread support for wpantund Linux (other than Raspberry Pi) or if it already exists. I flashed the nRF52840 DK with the NCP binary from the 0.10.0 Thread SDK and I built the wpantund on Ubuntu 16.04. I used the following wpantund configuration for the communication between the NCP and the host PC:

Config:TUN:InterfaceName wpan0
Config:NCP:SocketPath "serial:/dev/ttyS0,raw,b115200,crtscts=0"
Config:NCP:DriverName spinel

The program was able to establish the serial connection but the initialization failed with these errors:

wpantund[2316]: Initializing NCP
wpantund[2316]: NCP is now BUSY.
wpantund[2316]: [->NCP] CMD_PROP_VALUE_GET(PROP_PROTOCOL_VERSION) tid:1
wpantund[2316]: 	↳ 810201
wpantund[2316]: SpinelNCPInstance-Protothreads.cpp:440: Requirement Failed (IS_EVENT_FROM_NCP(event) && GetInstance(this)->mInboundHeader == mLastHeader)
wpantund[2316]: Resetting and trying again... (retry 1)
wpantund[2316]: [->NCP] CMD_RESET tid:2
wpantund[2316]: 	↳ 8201
wpantund[2316]: SpinelNCPInstance-Protothreads.cpp:430: Requirement Failed (event == EVENT_NCP_RESET)
wpantund[2316]: Resetting and trying again... (retry 2)
wpantund[2316]: SpinelNCPInstance-Protothreads.cpp:430: Requirement Failed (event == EVENT_NCP_RESET)
wpantund[2316]: Resetting and trying again... (retry 3)
wpantund[2316]: [->NCP] CMD_RESET tid:3
wpantund[2316]: 	↳ 8301
wpantund[2316]: SpinelNCPInstance-Protothreads.cpp:430: Requirement Failed (event == EVENT_NCP_RESET)
wpantund[2316]: The NCP is misbehaving: Repeatedly unable to initialize NCP. Entering fault state.
wpantund[2316]: State change: "uninitialized" -> "uninitialized:fault"

Thank you.

[m.wilniewiec]

I have exactly the same problem but on my RaspPi.

wpantund[1470]: Starting wpantund 0.08.00d (Aug  4 2017 14:47:03) . . .
wpantund[1470]: 	BUILD_VERSION = f26ee8f
wpantund[1470]: Configuration file "/etc/wpantund.conf" read.
wpantund[1470]: Ready. Using DBUS bus ":1.180"
wpantund[1470]: Running as root without dropping privileges!
wpantund[1470]: SpinelNCPInstance-Protothreads.cpp:412: Requirement Failed (IS_EVENT_FROM_NCP(event) && GetInstance(this)->mInboundHeader == mLastHeader)
wpantund[1470]: Resetting and trying again... (retry 1)
wpantund[1470]: SpinelNCPInstance-Protothreads.cpp:402: Requirement Failed (event == EVENT_NCP_RESET)
wpantund[1470]: Resetting and trying again... (retry 2)
wpantund[1470]: SpinelNCPInstance-Protothreads.cpp:402: Requirement Failed (event == EVENT_NCP_RESET)
wpantund[1470]: Resetting and trying again... (retry 3)
wpantund[1470]: SpinelNCPInstance-Protothreads.cpp:402: Requirement Failed (event == EVENT_NCP_RESET)
wpantund[1470]: The NCP is misbehaving: Repeatedly unable to initialize NCP. Entering fault state.
wpantund[1470]: State change: "uninitialized" -> "uninitialized:fault"

Im trying to run Nordic RF52840 kit (NCP example) with RbPi and github.com/.../borderrouter as it has a Border Router Agent with support for external commissioner. It seems that there are some problems with wpantund.

I have Config:NCP:SocketPath "serial:/dev/ttyACM0,raw,b115200,crtscts=1" in my /etc/wpantund.conf and I have such device in /dev. Any ideas what can go wrong?

PS. openthread/borderrouter says it is based on Thread 1.1.1 spec. I couldn't find such info for Nordic examples. Is it compatible?

[Jørgen Holmefjord]

In general, our NCP should be compatible with OpenThread's boarder router. Do you see the ttyACM0 device in /dev? If not, you might not have loaded the kernel module cdc_acm. You should also check the dmesg log while connecting the NCP.

[Karel_TandD]

As I am at too earlier a stage to offer a solution, here is my comment on this issue. I am using a Debian 9 host with the binary ot-ncp-fth.hex created from the current openthread master from github, loaded onto the nRF52840. wpantund was working ok until I did something "wrong" while using wpanctl. After that, I would get the error as described above, even after resetting, disconnecting/reconnecting re-powering etc the nRF52840 board. ONLY AFTER REPROGRAMMING THE NRF52840 BOARD did the behavior return to normal. This would imply that some setting was made to Non-volatile memory of the nRF52840 board.