This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Thread Border Router v0.10.0: NCP problem

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

Parents
  • 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

  • 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!

Reply
  • 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!

Children
No Data
Related