Tool/software:
I use CC2652 as coordinator, CC2340R5 as end device, with rx always on, and only one end device joined in the network.
Then I send private zcl commands every 50ms, with 64 bytes zcl payload from either sides to the other. The device crashs sometimes, and run to Exception_handlerSpin().
I want to confirm that is the current V8.4 SDK has this issue at high load.
the log is in attachment.
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
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.
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 Senjin,
Please allow me 24 more hours to validate the updated libraries and send them to you through private e-mail.
Regards,
Ryan
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