RTOS/CC2652R: CC2652R with newest SDK 2.30.00.xx but not work well

behold li

Part Number: CC2652R
Other Parts Discussed in Thread: Z-STACK

Tool/software: TI-RTOS

There are have two bugs:

1. After a long period of work, the CC2652R end device cannot issue the Data Request instruction forever until power up again.

2. when it's working properly, it can't be send out group cast(recall scene) sometimes.

Attachment is ubiqua capture log:

Customer TCLK: 5A:69:67:42:65:65:41:6C:6C:69:61:6E:63:65:30:3A

Customer network key: 01:02:03:08:09:32:78:86:01:02:03:08:09:32:78:86

packet ID 52 and 53 not issue Recall Scene but only Data Request,

packet ID 58 and 59 not issue Recall Scene but only Data Request

not issue recall scene bug.zip

over 5 years ago

0 Ryan Brown1 over 5 years ago

TI__Guru**** 202106 points

Hi behold,

Thank you for the feedback, the second bug is a known issue which is being addressed January's SDK update. How long of a period before the ZED does not send Data Requests, and have you further debugged the MCU status? Does it respond to commands from its parent? Do you have a sniffer log available for this behavior?

Regards,
Ryan

0 behold li over 5 years ago in reply to Ryan Brown1

Expert 2745 points

Power up,end-device work about 72+ hours or more time continually,may be occur first bug.

0 Ryan Brown1 over 5 years ago in reply to behold li

TI__Guru**** 202106 points

Was this problem only observed once or does it occur multiple times? Is this behavior easily reproduceable? Will it occur faster if you decrease the poll rate?

Regards,
Ryan

0 behold li over 5 years ago in reply to Ryan Brown1

Expert 2745 points

of course,occur multiple times and easily reproduceable.

0 Ryan Brown1 over 5 years ago in reply to behold li

TI__Guru**** 202106 points

I've started a test and will let you know of any progress, I will also ask the Software Development Team if they are aware of such behavior when they return from the holiday break.

Regards,
Ryan

0 Ryan Brown1 over 5 years ago in reply to Ryan Brown1

TI__Guru**** 202106 points

I was unable to reproduce the error after continuously running the CC2652R SDK v2.30 light ZC & switch ZED examples for a week with a poll rate of 1 second.

Regards,
Ryan

0 Lawrence Lin over 5 years ago in reply to Ryan Brown1

Genius 4755 points

Hi Ryan,
Could I know what the purpose and meaning of poll rate are here??

And whether we can modify the poll rate?? How could we modify poll rate in the SDK of V2.30 if yes??
Thanks

0 YiKai Chen over 5 years ago in reply to Lawrence Lin

Guru 735455 points

Poll rate means how fast a end device wakes up to polling its parent node for data. You can use Zstackapi_sysConfigWriteReq to set poll rate in CC2652R Z-Stack.

0 Lawrence Lin over 5 years ago in reply to YiKai Chen

Genius 4755 points

Hi YK,
Do we have default poll rate for the example code of zed_switch in the SDK V2.30?
Thanks

0 YiKai Chen over 5 years ago in reply to Lawrence Lin

Guru 735455 points

All the default poll rate settings are defined in f8wconfig.opts.

0 Lawrence Lin over 5 years ago in reply to YiKai Chen

Genius 4755 points

Hi YK,
Noted.
Thanks

0 behold li over 5 years ago in reply to Ryan Brown1

Expert 2745 points

The default poll rate(1000ms) may be not suitable for battery power end-device scenario,so we have to change from 1000 to 14400000 ms(240 minutes)

/* The number of milliseconds to wait between data request polls to the coordinator. */
/* 60*4=240 minutes */
-DPOLL_RATE=14400000

By the way,what time the newest SDK for CC26xx may be issue,we are very much looking forward.

0 Ryan Brown1 over 5 years ago in reply to behold li

TI__Guru**** 202106 points

I will re-test using this longer poll duration, to the best of my knowledge there are no changes in the v2.40 that address ZED polling. The default child aging timeout (NWK_END_DEV_TIMEOUT_DEFAULT) is 256 minutes, although there are 16 minutes to spare I would make sure that the coordinator is not having the ZED leave the network.

Regards,
Ryan

0 behold li over 5 years ago in reply to Ryan Brown1

Expert 2745 points

240 minutes not exceed default 256 minutes,I am sure coordinator does not leave end-device 256 minutes timeout,but long time running,end-device must be not issue Data Request forever.

0 Ryan Brown1 over 5 years ago in reply to behold li

TI__Guru**** 202106 points

I've observed similar behavior along with a few other concerns, I am discussing with the Software Development Team and will let you know of updates as they occur.

Regards,
Ryan

0 Lawrence Lin over 5 years ago in reply to Ryan Brown1

Genius 4755 points

Hi Ryan,

According to your testing, you just tried to expand the time of poll rate from 1 second to 240 minutes. Then, this issue could be duplicated.

I wonder whether this issue will happen or not if my poll rate is 1 minutes in my End-Device with new SDK of 2.30?? Dose Long poll duration cause this issue? How long of poll duration will cause this issue?

Another question:

I also want to know whether this issue will occur on the SDK of V2.20 with simplelink_zigbee_sdk_plugin_2_20_00_06??

Thanks

0 behold li over 5 years ago in reply to Lawrence Lin

Expert 2745 points

Oops,this issue must be reproduce easily.Only change poll rate form 1000ms to 240minutes

0 Lawrence Lin over 5 years ago in reply to behold li

Genius 4755 points

Hi Behold
According to your responses, if my poll rate less than 240 minutes, this issue will not occur?. Or The issue just cannot be reproduced easily but it still exist?
Thanks

0 behold li over 5 years ago in reply to Lawrence Lin

Expert 2745 points

this bug(not issue Data Request forever with long period) must be reproduced every times.I'm confirm this is a bug.

0 Ryan Brown1 over 5 years ago in reply to Lawrence Lin

TI__Guru**** 202106 points

Lawrence,

I'm currently testing with a POLL_RATE of 66000 (1 minute and 6 seconds) to confirm that this is not a type cast issue and have so far not seen any problems. Until we discover the root cause we will not know the poll rate duration which begins to fail. I am not aware of any changes from v2.20 to v2.30 that affect the poll rate other than the fact that it was accidentally cast as a uint16_t instead of uint32_t, which limited the poll rate to 65535 (1 minute and 5.5 seconds). However it is recommended that you evaluate the newest SimpleLink SDK available, it is not yet known whether this behavior has already been addressed in the upcoming v2.40 SDK.

Regards,
Ryan

0 behold li over 5 years ago in reply to Ryan Brown1

Expert 2745 points

Hi Ryan,I can confirm v2.20 have this issue too,and very easy to reproduce with long time running with 240 minutes poll rate,I don't think poll rate could not more than 240 minutes.

0 Ryan Brown1 over 5 years ago in reply to behold li

TI__Guru**** 202106 points

As previously explained, the poll rate in v2.20 is already limited to uint16_t so anything above 65 minutes is already not feasible.

Regards,
Ryan

0 Ryan Brown1 over 5 years ago in reply to behold li

TI__Guru**** 202106 points

Hi behold,

I apologize for the delay and confusion, but after the Software Development Team was unable to recreate the issue I discovered that my test which I though replicated the behavior was actually due to a separate rejoin problem. We have thus been unable to witness an end device ceasing to send poll requests at the value of POLL_RATE. Are you sure that your instance has no additional procedure involved such as a device rejoin? It would be beneficial if you could provide a sniffer log of the problem but until then I will mark the thread as resolved.

Regards,
Ryan

0 behold li over 5 years ago in reply to Ryan Brown1

Expert 2745 points

Hi Ryan,please don't close this thread,I will capture newest ubiqua log in the immediate future.

0 behold li over 5 years ago in reply to Ryan Brown1

Expert 2745 points

Hi Ryan:

Attachment is newest capture log with ubiqua(ZED don't issue Data Request forever),at the same time,recall scene is work well.

don't issue Data Request forever.zip

0 YiKai Chen over 5 years ago in reply to behold li

Guru 735455 points

It seems that your ZED restarts suddently at packet number 563 and try to send out beacon requests to join. However, ZED doesn't do polling in time to get network key so coordinator sends leave request to ZED. Do you add "ZC sends ZEDs Leave Reqs after MAC Association" patch at processors.wiki.ti.com/.../Zigbee_Known_Issues_and_Proposed_Fixes to your coordinator when you test this?

0 Ryan Brown1 over 5 years ago in reply to YiKai Chen

TI__Guru**** 202106 points

Even the beginning of the log shows that the ZED is not acknowledging or responding to ZC packets even though the receiver is supposedly on when idle, this is a known issue with RFD_RCVC_ALWAYS_ON=TRUE and is currently being investigated.

Regards,
Ryan

0 behold li over 5 years ago in reply to Ryan Brown1

Expert 2745 points

YiKai Chen

"ZC sends ZEDs Leave Reqs after MAC Association" patched on ZC (Z-Stack 3.0.2 version)

Ryan Brown1

1. if change default RFD_RCVC_ALWAYS_ON=TRUE on CC2652R newest SDK 2.30.00.xx,
that may be caused a issue could not joining network successful sometimes,at start 913 packet,0xB400 has joined network successful,but poll rate not work well whenever send out recall scene.
2. If don't change default RFD_RCVC_ALWAYS_ON,there have a the problems mentioned above.

0 Ryan Brown1 over 5 years ago in reply to behold li

TI__Guru**** 202106 points

True, you would need the ZED to send a data request in order to receive the recall scene information. As stated previously, we are investigating the ZED receiver always on issue.

Regards,
Ryan

0 Aries Lord over 5 years ago

Genius 5250 points

It is likely that your End Device has child-aging timeout.

0 behold li over 5 years ago in reply to Aries Lord

Expert 2745 points

poll rate mechanism on SDK 2.30.xx could not work well in some cases,if we received new CC2652R Revision E preproduction,we will porting application to SDK 2.40 version and test continually.

Zigbee & Thread

Zigbee & Thread forum

RTOS/CC2652R: CC2652R with newest SDK 2.30.00.xx but not work well