CC2340R5: When transferring data at a high load, system halted occasionally

Hey Senjin,

Thanks for reporting this, I don't believe the CC2340R5 Zigbee solution has been stress tested in this regard by TI as of yet.  Will this happen for a ZR node as well?  You can call PMCTLResetSystem from Exception_handlerSpin in order to reset the device and recover from the crash.

Regards,
Ryan

thanks for your reply. Yes, this happen for ZR as well. 

The Zigbee R&D Team is continuing to investigate and I will let you know when an update is available.

Regards,
Ryan

Hi Senjin,

The Zigbee R&D Team is continuing to investigate this behavior.  How is your application triggering a data packet every 50ms? Are you using the ClockP TI Driver, a ZBOSS scheduler API, or something else?  Can you share an application file modified from an existing example for which this behavior can be replicated by TI?

Regards,
Ryan

Hi Ryan,

I use the PC APP to send packets to CC2652P ZC via UART. Then, ZC first stores the packet in the queue, retrieves it from the queue, and sends it to CC2340R ZED. ZED receives the packet from zigbee network and transmits it to the PC through UART.  Two APPs simultaneously send data packets with a 50 ms interval. 

I can only share the relevant source code for sending and add it in the attachment. 

CC2340R send packet.zip

Thank you for the additional information.  Unfortunately the sending source code does not offer much for issue replication.  I am also wondering if the issue is caused by the Zigbee stack or UART implementation.  Would you be able to disable UART or work around its usage to confirm that it isn't causing the problem?  Can you try increasing the baud rate or buffer sizes to observe whether this mitigates or delays the failure?

The Zigbee R&D Team has identified a race condition where if the application is allocating buffers via an asynchronous event (e.g. ClockP) or anything other than the ZBOSS scheduler, there can be some buffer corruption that can lead to an exception.  They plan to make changes in an upcoming release to address this.  However, it is unknown as to whether this will resolve your use case. If your application isn't checking return codes from ZBOSS APIs then please correct this and let us know if any error codes are returned. Please also ensure your are freeing buffers correctly in your Zigbee application

Regards,
Ryan

Hi Ryan,

When will the next version of the SDK be released? After the next version is released, I will test it again. If there is a crash problem, I will verify it according to your suggestions. I now have other priority jobs to deal with.

Hi Senjin,

The next SDK release is planned for the end of April but we can work with you offline to provide an updated library to test by the end of this week.  I will reach out to you via e-mail when it is available.

Regards,
Ryan

Hi Ryan

It's a good idea to provide an updated library, but I hope you team can solve the problem of orphan nodes not sleeping together before providing it. Thanks

Hi Ryan,

If the low power problem can't be solved this weekend, please give me an updated library to verify the crash problem first. 

Hi Ryan,

I tested it for half an hour, and there was no crash. It seems to be solved. You've helped me out a lot. I will do more tests tomorrow, and if I have any questions, I will consult you