CC2530: Send Command Successful but No transmission

It seems there’s memory leak in your application. I would suggest you to check if your application has memory leak first.

Hey YK,

Thanks for the quick reply

I have checked for potential memory leak cases and have taken precautions. I dont think there is a memory leak issue.

Regards,

Suhrith

Hey Suhrith,

How often do you transmit the zcl_Send[ReportCmd/WriteRequest] and are you able to send any more packets successfully after the first instance of the issue?  What is the failure rate involved and does behavior improve if you pause for a while or reset the device after the problem occurs?  Several workarounds are possible, including checking the MAC_MCPS_DATA_CNF callback, enabling APS ACKs, or parsing report/write responses.  Can you provide any sniffer logs with comments that explain/identify the issue?  Several improvements have been made to Z-Stack since v2.6.1 and it would be worth reviewing the Release Notes bugs identified in v3.0.2 as well as the versions in Z-STACK-ARCHIVE.

Regards,
Ryan

Hey Ryan,

1) How often do you transmit the zcl_Send[ReportCmd/WriteRequest] 

Once in every 5 minutes and whenever there is a change in sensor value we transmit the zcl_Send[ReportCmd/WriteRequest] 

2) are you able to send any more packets successfully after the first instance of the issue?

Yes

3) What is the failure rate involved

Once its stop communicating 100% failure rate

4) does behavior improve if you pause for a while or reset the device after the problem occurs

Yes, the device works fine if rebooted

5) Can you provide any sniffer logs with comments that explain/identify the issue?

I will attach the sniffer logs soon

Regards,

Suhrith

Hi Suhrith,

As YK said, this appears to be a memory leak.  An example of this is described in the Z-Stack 3.0.x Known Issues Wiki Page: http://processors.wiki.ti.com/index.php/Zigbee_Known_Issues_and_Proposed_Fixes#Memory_Leak_in_zcl.c 

I suggest that you use difference compare software to notice the changes in the ZCL files between Z-Stack 2.6.1, Z-Stack HA 1.2.2a, and Z-Stack 3.0.2.

Regards,
Ryan

Hello Suhrith,

Do you have any updates?

Regards,
Ryan

Hey Ryan,

I reviewed the changes in Z-Stack 2.6.1, Z-Stack Home, Z-Stack 3.0.x, there are many changes done to the zcl.c files

After tests I have figured out that, Occupancy change Multicast from the Master to the 8 remaining nodes is successful for the first 70-80 times

Then the Master stops multicasting

I am having difficulty in recreating the exact failure scenario again (to provide logs), I am still working on it, will update 

Regards,

Suhrith

Hey Ryan,

I have added the sniffer logs for the issue mentioned:

0083.test2.psd

I will need NWK keys as all packets are encrypted, or a sniffer log with the device joining process included.  Your previous answers are also contradictory, stating that you are able to send more packets after the issue first occurs yet there is a complete failure rate.  Further IAR debugging may be required to identify the issue but as mentioned before it would be optimal to upgrade the stack version.

Regards,
Ryan