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]

Another possible way is debugging the second Cloud COAP Client. You can always start the J-Link RTT Viewer and check logs. Additional ones can be added with the NRF_LOG_INFO() macro. Setting breakpoints would also do. I would focus on the dns_response_handler and hostname_resolve function.

[Reto]

Hi Piotr,

1. Yes. The Thread network goes down every time I start the 2nd COAP client
2. I use RaspberryPi v0.10.0 with NCP 0.10.0 (as you told me I should).
3. I think the hostname_resolve is executed every time, because I debug it (Eclipse)
4. The order: I cannot tell if the order is the reason. At the moment, I am not able to connect a particular board, even if it is the only COAP client.
5. I have the Topology Monitor running all the time (CLI client loaded on a development board).

I run the nRF in the 1.8V mode. Meaning: the switch VEXT--nRF is set to ON and I supply the 1.8V from an external supply. Does maybe the order of power-up (1st nRF 1.8V, then debugging-circuit 5V) make a difference? I observed that it didn't work, and as soon as I connected the USB cable the hostname_resolve() was succesfull. Very strange...

Thank you so much for your support!

[Reto]

Is there something written into the non-volatile memory of the Thread nodes around or in the Border Router? I mean, it looks to me like if there is a problem with the routing of the packets from my Thread node to the internet?

Reason to believe this: as I started using a brand new development board, things worked well. But after flashing the 2nd time my FW onto this new board, things stopped working again. Same issue with the:

hostname_resolve(m_app.p_ot_instance, m_cloud_hostname);

Thank you very MUCH!

[Reto]

Note: I have to add that I changed the device type of my COAP client example to SLEEPY END DEVICE and back to normal device (router). But it doesn't work with either configuration (SED or router). I don't know if this may is a problem?

[Reto]

My boards config:

• V0.9.1 (monitor)
• V0.9.1, V0.9.0 --> trieb both (NCP)
• V0.9.0 (COAP clients)

I use ETHERNET, not Wi-Fi on the Raspberry Pi 3 Model B Rev 1.2.

Problem still persists...