• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 57 subscribers
  • Views 365 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2530: Questions about data receiving

Viki Shi
Expert 3130 points
Part Number: CC2530


Hi,

A customer tested the ZNP example with CC2530 as coordinator and JN5169 as enddevice, the Stack is ZHA1.2.2. He faced the following problem:

1.Befor the device reset, rxFcsIsr got data received, but afIncomingData no. Please check the figure and capture file:

UART data outputed from rxFcsIsr():

Capture file 1:

afIncomingData没有收到数据，但rxFcsIsr有收到数据.rar

2.After device reset, both rxFcsIsr and afIncomingData got data received, Please check the figure and capture file:

终端设备数据发送2.psd

The endpoint is 0xf0. He also tested on ZIGBEE3.0 and got the same problem, please guide us how to fix this, thanks a lot.

  • 0
    Guru 735695 points

    It seems that you add something in rxFcsIsr to output data to UART to cause this issue. If you don't modify anything in ZNP, do you still see this issue?

  • 0
    TI__Guru**** 220297 points

    Hi Viki,

    Does the ZNP still send Link Statuses and respond to network messages?  Are you still able to send/receive messages through the MT interface?  Please debug the ZNP to discover whether the afIncomingData is entered or why MT_AfIncomingMsg never transfers the message over the UART interface.  As YK mentioned, if the default ZNP works well then the customer must provide more information regarding their custom application which causes the behavior.  You will need to monitor the heap/stack memory and device state when the ZNP is no longer transferring incoming AF data.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 50 points

    The ZNP still send Link Statuses and respond to network messages.Still able to send/receive messages through the MT interface.But afIncomingData() function no message received.In the same network, five devices are tested at the same time. There are three JN5169 devices and two CC2530 devices. All jn5169 devices will have the problems I mentioned before, and all CC2530 devices will not have similar problems. If the coordinator is JN5169 and the end device is JN5169, all JN5169 devices will not have similar problems. Because we have to use the third-party JN5169 equipment, so this problem must be solved.At the same time, I want to understand why the afincoming data of coordinator has data input after rejoining of jn5169, Mt_ Afincomingmsg has data output.

  • 0 in reply to QIDONG LI
    TI__Guru**** 220297 points

    Hi Qidong,

    Thank you for clarifying and providing further information.  After the JN5169 ZED joins the first time, does the ZNP report any information over the MT interface or respond to Device Announce and End Device Timeout Request messages?  Does operation ever work as expected before the JN5169 rejoins?  I do not see anything in the sniffer logs that indicate an issue, such as NWK frame counter.  Can you confirm that this behavior occurs with the default ZNP project settings and provide sniffer logs of the joining process of both a JN5169 and CC2530 ZED, followed by the rejoin after each is reset?  Can you debug the ZNP to determine whether afIncomingData is entered during the faulty state?  If so then you could debug the code to figure out where/why it fails.

    Regards
    Ryan