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

[Reto]

Thank you Piotr for your answer and your effort. I tried it several times and it still didn't work for me. Maybe because I have also a Cloud COAP Client example running on the same network? Anyway, I cannot change my NCP to 0.10.0 now, as I am running an long-time test and it works great with 0.9.0. and I don't want to stop it right now. I will give it a try as soon as I've set up my 2nd border router.

[Piotr Szkotak]

Thank you for update. I don't think that running Cloud COAP example could break anything. Please let me know when you will have more information. If the issue is still there it needs to be sorted out.

[Reto]

Hi Piotr I tracked it down a little more in detail. The problem starts when I start the 2nd of two Cloud COAP Clients. Then the border router and all the other Thread nodes start fading away from my Thread Monitoring tool. I think the problem is, that my 2nd Cloud COAP Client executes the function:

hostname_resolve(m_app.p_ot_instance, m_cloud_hostname);

all the time. The 2nd node just don't get the hostname resolved. This seems to break down the whole Thread network.

Do you have any idea on this?

Thank you, Reto

[Piotr Szkotak]

Hi Reto, Thank you for the message.

1. Is the issue shows up every time you power on the second Cloud COAP Client?
2. What happens when you use RaspberryPi v0.9.0 image? Is it present as well?
3. Why do you think this is the hostname_resolve function is executed all the time?
4. What happens if you power on Cloud COAP Clients in a different order?
5. Do you have any Thread sniffer available?

With my limited information about your setup I have recreated it on my desk and see no issues after powering the second Cloud COAP Client. Therefore I can see two ways of getting us further towards solving this issue. First is detailed information about the setup: A) Board revision(like v0.8.0/v0.9.0), firmware version for each board(what release has been .hex/.img taken from) B) Steps to reproduce (order in which you power on devices, commands applied and so on)