CC2340R5: Send packets, and the callback function sometimes doesn't execute

Hi Senjin,

Can you quantify "extremely rare cases", as in this is x per one thousand packets?  Are any network conditions (noisy environment, busy radio channel, several devices in the network, etc) required for recreating the problem?  Are there any remedies which avoid the callback failure, such as increasing the data packet interval, decreasing the data bytes per packet, increasing the serial port speed/queue, disabling the serial port, etc?  Are you able to implement a workaround which would allow you to detect a missing callback (ex send counter or timer expiration) from which you can record the callback failure and release the memory?  What in your opinion would be the optimal way to recreate this behavior using the default TI examples?  Are you using the latest v8.40.02.01 F3 SDK to observe this behavior?

Regards,
Ryan

Hi Ryan,

1, This problem can be encountered when sending 20k packets of data.

2, It is not clear whether the wireless environment and channel are related. I tested it in office environment with only one ZC and one ZED.

3, Not remedies are confirmed right now

4, I don't think it's necessary implement a workaround, because when this problem occurs, it will continue to occur, and even if I release the memory it doesn't make sense.

5, I can send you the source file of my CC2340 ZED reduction version and CC2652 ZC hex firmware, so that you can easily test to reproduce this problem. Do you need that?

6, I am using v8.40.02.01 F3 SDK and have updated the patch you sent me via email. 

1. Does this mean that the issue will occur at a consistent packet count (i.e. 20k) or can it occur earlier/later than this value?

3. Please consider trying a few of my suggestions to generate additional observations.

4. Thanks for clarifying, I hadn't understood before that the issue will continue to happen consecutively after the first instance.

5. I would appreciate the reduced version of the CC2340 ZED source code to further debug the issue, but will this require a PC host connection to test?  I'd prefer a standalone CC2340R5 ZED + CC2652R ZC environment which is not dependent on a PC host for issue replication .

Regards,
Ryan

Hi Ryan,

1, It happens before 20k packets, randomly, and it's not certain when it happens.

3, Ok, I'll test it when I have time. 

5, Yes, PC HOST is needed and I can provide it to you.  If you need standalone CC2340R5 ZED + CC2652R ZC environment, I'll give it to you when I've modified the code.

Hi Ryan,

I need to correct a message that sending 200k packets can reproduce the problem, not 20k. 

In today's test, I increased the transmission interval from 50ms to 80ms, reduced the packet size from 64 bytes to 6 bytes, and increased the serial port baud rate from 115200 to 230400. When sending about 170k packets, the problem still appeared. Other tests are still in progress, and I'll update as soon as possible

Hi Ryan,

This may be related to my not using the zboss_r23\include file from the V8_40_02 SDK.  When I was developing based on the V8_20_00 SDK, I copied the zboss_r23\include file to my project folder. However, when I updated the SDK to V8.40, I did not update this file in time.  I need more time to verify.

Hi Ryan,

Unfortunately, I have to tell you that even though I updated the include file, I still encountered this problem when I tested for more than 6 hours.

Note: I tested in a shielded room, excluding wireless signal interference.

I plan to modify and test again, based on the source code of onoff_switch_LP_EM_CC2340R5_freertos_ticlang, making zed continuously send on/off toggle requests. During this period, CC2652P ZC does not send data.
I have added my source code to the attachment. If you have time, you can test it together.

note:Rx always on should be set to true.

5810.on_off_switch.zip

Thanks for providing this information Senjin, unfortunately further tests from my side will be postponed until next week.

Regards,
Ryan

Hi Ryan,

I used my own CC2340 ZED application to test sending a packet of data to CC2652 ZC at  intervals of 50ms , and ZC did not send data to ZED. The test lasted two and a half days without any issues. If CC2340 ZED and CC2652 ZC send data to each other, there is a problem.

Therefore, I suspect it has something to do with the receiving and processing logic of CC2340. Now I'm sharing my test source code and sniff log with you.
Among them, CC2652 ZC is based on simplelink_cc13xx_cc26xx_sdk_8_30_01_01, and the example is zc_light_CC1352P_2_LAUNCHXL_tirtos7_ticlang.

CC2340 ZED, based on simplelink_lowpower_f3_sdk_8_40_02_01, example onoff_switch_LP_EM_CC2340R5_freertos_ticlang, note that RX ALWAY ON needs to be set to true.

code and log.zip

Thank you Senjin for providing this detailed information.  Given you observations, is it logical to assume that this issue will exist on a CC2340R5 ZR project as well?  Does the project have to use the dual ZED + ZR configuration in SysConfig?  Also, is it likely that the problem will occur with a CC2340R5 ZED light only receiving on/off messages from a ZC switch at intervals of 50 ms?

I appreciate your patience as we isolate this behavior to a specific layer of the F3 SDK Zigbee stack.

Regards,
Ryan

Hi Ryan, 

I set the device to ZED only, RX ALWAYS ON in sysConfig, I have not verified if ZR has any problems at present.
I need to clarify that I am not yet sure that the problem can be reproduced using the source code I provided, which is different from my previous test of sending private ZCL commands, and I am also testing.

I'm not able to replicate with a F2 SDK ZC switch sending on/off toggle commands to a F3 SDK CC2340R5 Zigbee light every 50 ms, regardless of whether it is a non-sleepy ZED, ZR, or a combination image.  This is an instance in which the CC2340R5 is not sending ZCL messages to the F2 device, only receiving.

Thank you for the test code, I've tried evaluating with the instructions provided but am not able to replicate after 20 minutes (which should equate to more than the 20k packet failure rate, 20 packets per second is 1000 seconds or 16.7 minutes for 20k packets to be transferred). 

Thus I am struggling to replicate the issue. Please suggest any changes I can make to help simulate the challenge you have encountered.

Regards,
Ryan

Hi Ryan,

I want to correct this: testing for 20 consecutive minutes is not enough to reproduce the issue. According to my most recent experiment, it took over 6 hours to reproduce the problem.  Moreover, I used this test code last night test for about 14 hours, and this morning I also reproduced the issue. By sniff log, I observed that cc2340 ZED has stopped sending on/off command. 

Thank you for clarifying Senjin, this is closer to failure within 432k packets instead of the 20k packets which is the assumption I based my original test on.  I will need to run some longevity and perhaps overnight tests to determine whether I can observe the behavior on my setup.

Regards,
Ryan

Hi Senjin,

I am confirming that I can replicate similar behavior and observe the issue on my end, please allow more time for me to further debug and sync with the Zigbee R&D Team.

Regards,
Ryan