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 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.

[Reto]

Hi Piotr.

Thanks for your update. It runs now. What I did:

• I changed to USB-powered operation of the nRF52840 PDK

• I performed "nrfjprog -f -NRF52 -e"

• I changed to 1.8V power

• I run my custom code which is based on your CoAP cloud example (via Eclipse)

Everything is ok now. Don't know why. I tried a "--chiperase" earlier, it didn't work. What is the difference between "--chiperase" and "-e"? Thank you, Reto

[ovrebekk]

Hi Reto

Functionally the two are the same, but --chiperase can only be used in combination with the --program command. -e can be used independently.

Best regards