Thread Border Router v0.10.0: NCP problem

[Reto]

Dear experts,

I've been playing around with Thread since nRF5 SDK for Thread v0.8.0, cloud_coap_client. I use your Border Router example with NCP example running on nRF52840_Preview_DevKit and a RaspberryPi B.

Since I've changed to SDK Thread v0.10.0 with the NCP example of SDK vor Thread v0.10.0 --> my nRF Thread Topology Monitor v0.8.0-1.alpha does not connect to the Boarder Router. As soon as I am switching the NCP of the Border Router back to v0.9.0, everything works fine.

My monitor CLI-Thread-Node, which I am using as monitor, runs the v0.10.0 example (not the v0.9.0). Also the image on the RaspberryPi is from v0.10.0 (I checked, and I saw that the RaspberryPi image of Border Router v0.9.0 is identical to v0.10.0 --> IS THIS MAYBE THE ISSUE?)

I am wondering what the reason is for this behavior? Can you give me any advice what I may did wrong? Or if this is a bug?

Thank you for any hint. Reto

[Piotr Szkotak]

Hi Reto, Thank you for your interest in the Thread Border Router. I have tested TTM v0.8.0-1.alpha with SDK and BR v0.10.0 - it seems to work fine. I see all nodes in the TTM and it is possible to connect CLI to the NCP and ping global addresses.

Could you reflash both kits with the v0.10.0 and the --chiperase flag passed to the nrfjprog during flashing (nrfjprog -f NRF52 --chiperase --program _build/nrf52840_xxaa.hex --reset)?

In case the issue is still present please elaborate a bit more on it and attach logs if you think they would help to track the issue. Exact steps to reproduce would be a great hint as well.

I see that the image has been generated with a correct commit, there is also a binary difference between the 0.9.0 and 0.10.0 img files. I wouldn't look for the issue there.

Kind Regards, Piotr Szkotak

[Piotr Szkotak]

Hi Reto, Thank you for the detailed explanation. I see that you are trying some non default configuration - that way may be harder to isolate the issue. Personally I would start from powering all kits from the debug USB port and set them to be Full Thread Devices. You are right about the usage of the persistent storage, thread network configuration is kept there. There are two ways of cleaning it: "nrfjprog --chiperase" followed by flashing a hex file or without reflashing "factoryreset" CLI command. I would use it on all nodes before further tests, especially on this particular node that does not work at all now.

When it comes to the Extended MAC set to 0 it seems that it is shown for the node that is executing the command as you said. It seems like a minor display bug as the "extaddr" command shows the correct MAC.

I would also make sure that the nRF5x-Command-Line-Tools are in the newest version.

To sum up:

1. Always perform chiperase before flashing a new firmware.
2. Try to power from the USB instead of 1.8V
3. Update nrfjprog.

The next possible steps are using a Thread sniffer or tcpdump on the NCP tunnel interface to see if the DNS request gets there and if it is, if the response is sent.