RTOS/CC2630: CC2630/CC2650 End Device not send Beacon Request forever after lose connection with parent.

If you mean to back off 1 minutes, you should use “-DREJOIN_BACKOFF=60000” instead of “-DREJOIN_BACKOFF=1000”.

I am sorry, I mean 1 second, but after sometime lost parent it not send beacon request again, i care about that because it could not reconnect to the network when ZNP power back.

Other than REJOIN_BACKOFF, do you change anything in CC2650/CC2630 SampleSwitch?

I disable ZSTACK_MANUAL_START, ZCL_EZMODE and HOLD_AUTO_START build tag, change default channel from 11 to 13.

Those settings won’t affect rejoin beacon requests. I suggest you to trace/debug the device status when this issue happens.

I also read this, may be it is a bug in the kernel and i can do anything  :

It has been long time ago but TI not fixed it, CC2630/2650 is active product. I also try to apply Jason fixed but it is the same.

I am not sure if your case is the same to the one in the link you point out so you need to trace/debug your case and provide more information.

I change to:

-DREJOIN_BACKOFF=10000
-DREJOIN_SCAN=60000

mean it scan for 1 minute and back off 10 seconds, but some time back off stay for 20 seconds, you can see in the image. I try capture with CC2531 USB, because debug long time some time it disconnected.

It is random happen with many device in out network, now i just connected 1 ED to reproduce it.

Do you use custom board? If yes, I would suggest you to check your 32K crystal.

Yes, it is custom boards, but i check 5 of them, still the same.

Why you think it cause by 32k crystal? It repeat like 3 times 10 seconds, 1 time 20 second.

If you use the following settings, what do you observe?

-DREJOIN_BACKOFF=60000
-DREJOIN_SCAN=60000

It is the same, first two back is 1 minutes and then 2 minutes, longer capture it will back to 1 minutes. You can see the from the ID 106 in the attach file.

back_off.zip

Thank you, i will try.