• State TI Thinks Resolved
  • Locked Locked
  • Replies 44 replies
  • Answers 1 answer
  • Subscribers 57 subscribers
  • Views 1422 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC2531: Meaning of the ZDO_MSG_CB_INCOMING SeqNum?

Chris Jackson
Intellectual 650 points
Part Number: CC2531
Other Parts Discussed in Thread: Z-STACK

I'm trying to understand the transaction ID counter fields that are used in various commands. For example, the ZDO_MSG_CB_INCOMING message includes a SeqNum field which I'd assumed would be the APS sequence? However, this always seems to be 0. Likewise, when sending messages, the AF_DATA_REQUEST command has a field "transId" - how does this relate to the APS counter (or is it only used for some internal use)?

Below shows a transaction sent to an Osram bulb with a transId of 0x0F, but the response is 0x00 in the seqNumber field.

16:18:08.891  DEBUG  TX ZSTACK: ZstackAfDataRequestSreq [dstAddr=71DE, destEndpoint=00, srcEndpoint=00, clusterId=0003, transId=0F, options=[AF_ACK_REQUEST, AF_DISCV_ROUTE], radius=31, data=00 DE 71]
16:18:08.954  DEBUG  RX ZSTACK: ZstackZdoMsgCbIncomingAreq [srcAddr=71DE, wasBroadcast=false, clusterId=8003, securityUse=false, seqNumber=00, dstAddr=0000, data=00 DE 71 70 C1]

Thanks.

  • 0
    Guru 735455 points
    Try to refer to discussions in e2e.ti.com/.../2747182
  • 0 in reply to YiKai Chen
    Intellectual 650 points
    Thanks for the link YK. It doesn't seem to refer at all to the seqNumber field in the incoming message. This is really the cruz of my question as I expect that this should be the APS counter? I could be wrong, but it is always 0 from what I can see (at least for ZDO frames) and I want to be able to correlate the ZDO response received through the INCOMING message with the request that I sent. When the seqNumber is always 0, this seems difficult. We also use the APS counter for detecting duplicate packets, and again, this is failing when the number is always 0.
  • 0 in reply to Chris Jackson
    Guru 735455 points
    I had revise zcl_SendCommand to use seqNum instead of APS_Counter as transID parameter of AF_DataRequest so I can use seqNum to check APS ack when I call zcl related APIs.
  • 0 in reply to YiKai Chen
    Intellectual 650 points
    Sorry YK - I don't know what you mean here. Are you saying that one of the parameters in the zcl_SendCommand command will be reflected back in the incoming message seqNumber? Or do you mean that you modified the ZStack source to implement this?
  • 0 in reply to Chris Jackson
    Guru 735455 points
    Try to refer to sunmaysky.blogspot.com/.../how-to-check-aps-ack-in-ti-z-stack.html which shows you how to check APS ack in Z-Stack.
  • 0 in reply to YiKai Chen
    Intellectual 650 points
    Thanks, but this seems to require a custom firmware if I understand correctly. This is not possible - we need to use the standard firmware provided by TI and then interface from the host via the serial interface. Or can the same be acheived via the host interface?

    I had assumed that the seqNumber in the ZDO_MSG_CB_INCOMING host call would provide this, but from what I see, it is always 0.
  • 0 in reply to Chris Jackson
    Guru 735455 points

    Since you are using your own host system, you should check ZNP/MT command AF_DATA_CONFIRM and its TransId for APS ack.

  • 0 in reply to YiKai Chen
    Intellectual 650 points
    Yes, of course - but that is now back to my original question. We are setting the transId in the AF_DATA_REQUEST, and expecting this to be received back in the seqNumber in the ZDO_MSG_CB_INCOMING response, but as you can see in my first post, this is always 0x00.
  • 0 in reply to Chris Jackson
    Guru 735455 points

    APS ack is not received from ZDO_MSG_CB_INCOMING so seqNumber in the ZDO_MSG_CB_INCOMING response is not what you should check.

  • 0 in reply to YiKai Chen
    Intellectual 650 points
    Ok, but if the sequence number is not in the seqNumber field, where is it provided? APS sequence number is sent in all APS messages, and I would have expected it to be provided.

    If I should not check it here, please can you tell me what should be checked here?
  • 0 in reply to Chris Jackson
    Guru 735455 points

    If you mean to check transID in AF_DATA_REQUEST command, you should check ZNP/MT command AF_DATA_CONFIRM and its TransId.

  • 0 in reply to YiKai Chen
    Intellectual 650 points
    But this isn't what I want...

    I want to get the APS counter for a received ZDO message - not for the data confirm. We want for starters to do duplicate detection and for this we want to get the APS counter.
  • 0 in reply to Chris Jackson
    Guru 735455 points
    That's not the mechanism I know.
  • 0 in reply to YiKai Chen
    Intellectual 650 points
    Sorry - I'm not sure what you mean? I think your responses are related to the APS ACK - this is not my question. If there is a different mechanism for getting the APS counter on incoming frames, please can you tell me?
  • 0 in reply to Chris Jackson
    Guru 735455 points
    Maybe I misunderstand what you want. Try to check TransSeqNumber in AF_INCOMING_MSG and see if that's what you intend to get.
  • 0 in reply to YiKai Chen
    Intellectual 650 points

    The issue is related to ZDO messages, so we do not receive AF_INCOMING_MSG, instead we receive ZDO_MSG_CB_INCOMING. As I pasted in my first message we see the incoming message and the seqNumber is always 0. From the sniffer logs, the APS counter on these frames is not 0.

    For reference I past the information from the MT document below. This simply states that seqNum should be the sequence number of this frame - I assume this should be the APS counter, but maybe I'm wrong? Either way, I'm assuming it should not always be 0.

    Thanks again for your help.

  • 0 in reply to Chris Jackson
    Intellectual 650 points

    I see that this is marked as "TI thinks resolved", but I don't think there is any answer yet to the original question -  what is the meaning of the SeqNum in the ZDO_MSG_CB_INCOMING packet?

  • 0 in reply to Chris Jackson
    TI__Guru**** 202086 points

    Hey Chris,

    Feel free to reject any marked answer that does not solve your issue. After looking through Z-Stack code it appears that the SeqNum is equivalent to TransSeq which is set to cmd.Data[0] instead of cmd.TransSeqNumber inside ZDP_IncomingData, which therefore returns a Success message (0x00) as compared to an actual sequence number. I will have a Software Developer follow up on this.

    Regards,
    Ryan

  • 0 in reply to Chris Jackson
    Genius 3415 points

    This is a known issue form Z-Stack 3.0.2 that makes always the transactionID = 0x00. However this transactionID is an internal counter for the frame that doesn't go Over-The-Air and is not the APS counter. The value for the APS counter will be within the ASDU buffer so you need to know how to parse this ASDU according to the APS command.

    Which ZDO message are you sending?

  • 0 in reply to Jose Maria Alvarez
    Intellectual 650 points
    > This is a known issue form Z-Stack 3.0.2 that makes always the transactionID = 0x00.
    Will this be fixed in 3.03?

    > The value for the APS counter will be within the ASDU buffer so you need to know how to parse this ASDU according to the APS command.
    Thanks. I guess this isn't available via the serial interface... Or is there a way to receive the ASDU?

    > Which ZDO message are you sending?
    We are sending lots of them to perform binding, getting descriptors, searching for devices, enabling join, leaving etc...
  • 0 in reply to Chris Jackson
    TI__Guru**** 202086 points
    Hey Chris,

    TI has no plans to release another Z-Stack update for the CC253x platform.

    Regards,
    Ryan
  • 0 in reply to Chris Jackson
    Genius 3415 points
    Check if you have MT_AF_CB_FUNC compilation flag set to enable AF_INCOMING_MSG_EXT defined in section 3.2.1.4 of Z-Stack
    Monitor and Test API.
  • 0 in reply to Jose Maria Alvarez
    Intellectual 650 points
    As we need to use the precompiled firmware, I'm not sure if this is available?

    What is the difference between the AF_INCOMING_MSG_EXT and AF_INCOMING_MSG call - from the docs, it just mentions interpan messages. Is it possible to configure this to receive ZDO messages - I've only managed to get ZCL messages on endpoints other than 0. It would be very nice if this could be configured to receive all received messages?
  • 0 in reply to Chris Jackson
    Genius 3415 points
    You will receive an AF_INCOMING_MSG instead of AF_INCOMING_MSG_EXT when MT_AF_CB_FUNC is enabled. I made a mistake sorry about that.
  • 0 in reply to Jose Maria Alvarez
    Intellectual 650 points
    Can this be enabled programatically, or only at compile time?
  • 0 in reply to Chris Jackson
    Genius 3415 points
    Only at compile time so you have to add the MT_AF_CB_FUNC flag and then rebuild.
  • 0 in reply to Jose Maria Alvarez
    Intellectual 650 points
    Ok, we were hoping to use standard firmware, but maybe that's not going to be possible.

    Can you confirm that with this setting, we will receive all frames via the AF_INCOMING_MSG call - ZDO and ZCL?

    Thanks.
  • 0 in reply to Chris Jackson
    Genius 3415 points
    ZDO messages are processed by ZDO_MSG_CB_INCOMING. Take a look to section 3.12.1.24 ZDO_MSG_CB_REGISTER you need to register the ZDO messages that you like to receive using the specific ZDO cluster ID for each ZDO command.

    AF_INCOMING_MSG is used for APS messages that go to an endpoint different to 0x00 (endpoint reserved for ZDO)
  • 0 in reply to Jose Maria Alvarez
    Intellectual 650 points
    Ok, so we're back to the start then as this is exactly what I'm doing, and the problem I have (as per this thread) is with the ZDO_MSG_CB_INCOMING message, and you earlier suggested to instead use AF_INCOMING_MSG. It now seems that this is wrong, so we are back at the start?
  • 0 in reply to Chris Jackson
    Genius 3415 points
    It seems that I get you wrong I was thinking that you want to get ZCL messages but you already done that. Sorry for the misunderstanding. Give me some time to look further.
  • 0 in reply to Jose Maria Alvarez
    Genius 3415 points

    Is there any particular ZDO message that you have seen with this behavior of transactionID=0x00? I just tested with ZDO_IEEE_ADDR_REQ and the value is correctly set as on the Over-The-Air message value.

  • 0 in reply to Jose Maria Alvarez
    Intellectual 650 points
    I would need to recheck, but if I remember correctly, every received message had the SeqNum of 00. As per the logfile in the first post of this thread, clusterId 0003 is the Power Descriptor Request / Response. This was just one example though.

    I thought above you said that this was a known bug? Maybe it was fixed in your version, but I am using 3.0.2.
  • 0 in reply to Chris Jackson
    Genius 3415 points

    At the beginning I thought the issue was about the APS reflected frames but is not the case so the known issue is not related to your case. Sorry about that.  

  • 0 in reply to Jose Maria Alvarez
    Intellectual 650 points
    Ok, but Ryan said that it was reading the incorrect byte from the array? Is that also wrong?

    Can you explain what you mean by "APS reflected frames"?
  • 0 in reply to Chris Jackson
    Genius 3415 points
    I need you to reproduce the issue with an specific command in order to know if the parsing of the data is not done properly. Maybe there are some cases were this is true, so we need to track them.

    A reflected frame means re-transmission of a frame that was generated in the device itself.
  • 0 in reply to Jose Maria Alvarez
    Intellectual 650 points
    What do you want me to provide? I've provided a log already showing the Power Descriptor Request and response. Isn't that a specific command?
  • 0 in reply to Chris Jackson
    Genius 3415 points

    Can you try to reproduce the issue with a fresh new installation of Z-Stack 3.0.2.

    I'm able to see the expected value for transaction ID.

  • 0 in reply to Jose Maria Alvarez
    Intellectual 650 points

    > Can you try to reproduce the issue with a fresh new installation of Z-Stack 3.0.2.

    We are using the precompiled 3.0.2 binary - this is a requirement from our customer. It is however the latest and I'm not sure if reinstalling it will help?

    The following is a bunch of received frames. I've also added the raw data received, and in all cases, the sequence number is 00. 

    21:09:06.861  DEBUG  ZSTACK RX: FrameData [ data=45 FF 00 00 00 32 80 00 00 00 00 00 00 00 00 ]
21:09:06.862  DEBUG  RX ZSTACK: ZstackZdoMsgCbIncomingAreq [srcAddr=0000, wasBroadcast=false, clusterId=8032, securityUse=false, seqNumber=00, dstAddr=0000, data=00 00 00 00]

21:09:27.491  DEBUG  ZSTACK RX: FrameData [ data=45 FF 00 00 00 03 80 00 00 00 00 00 00 00 10 C1 ]
21:09:27.491  DEBUG  RX ZSTACK: ZstackZdoMsgCbIncomingAreq [srcAddr=0000, wasBroadcast=false, clusterId=8003, securityUse=false, seqNumber=00, dstAddr=0000, data=00 00 00 10 C1]

21:09:37.491  DEBUG  ZSTACK RX: FrameData [ data=45 FF 00 00 00 32 80 00 00 00 00 00 01 00 01 F4 32 01 FE FF ]
21:09:37.492  DEBUG  RX ZSTACK: ZstackZdoMsgCbIncomingAreq [srcAddr=0000, wasBroadcast=false, clusterId=8032, securityUse=false, seqNumber=00, dstAddr=0000, data=00 01 00 01 F4 32 01 FE FF]

21:12:10.531  DEBUG  ZSTACK RX: FrameData [ data=45 FF 00 00 00 36 00 00 00 00 00 00 01 ]
21:12:10.531  DEBUG  RX ZSTACK: ZstackZdoMsgCbIncomingAreq [srcAddr=0000, wasBroadcast=false, clusterId=0036, securityUse=false, seqNumber=00, dstAddr=0000, data=00 01]

21:12:10.566  DEBUG  ZSTACK RX: FrameData [ data=45 FF 00 00 00 01 80 00 00 00 00 00 38 E2 D9 14 00 4B 12 00 00 00 00 ]
21:12:10.566  DEBUG  RX ZSTACK: ZstackZdoMsgCbIncomingAreq [srcAddr=0000, wasBroadcast=false, clusterId=8001, securityUse=false, seqNumber=00, dstAddr=0000, data=00 38 E2 D9 14 00 4B 12 00 00 00 00]

    Note that we are not sending ZDO messages through the individual ZDO MT commands - we send all commands (ZDO and ZCL) via the AF_DATA_REQUEST command. I assume that this should not matter - and the sniffer shows the sequence is not 0 (as seen in the example below where this is 4).

    12:42:45.312  DEBUG  TX ZSTACK: ZstackAfDataRequestSreq [dstAddr=6824, destEndpoint=03, srcEndpoint=01, clusterId=0006, transId=04, options=[AF_ACK_REQUEST, AF_DISCV_ROUTE], radius=31, data=01 04 01]
12:42:45.313  DEBUG  ZSTACK TX: FrameData [ data=FE 0D 24 01 24 68 03 01 06 00 04 30 1F 03 01 04 01 4C ]
12:42:45.328  DEBUG  ZSTACK RX: FrameData [ data=64 01 00 ]
12:42:45.328  DEBUG  RX ZSTACK: ZstackAfDataRequestSrsp [status=SUCCESS]
12:42:45.651  DEBUG  ZSTACK RX: FrameData [ data=44 80 00 01 04 ]
12:42:45.651  DEBUG  RX ZSTACK: ZstackAfDataConfirmAreq [status=SUCCESS, endpoint=01, transId=04]
    12:42:45.686  DEBUG  ZSTACK RX: FrameData [ data=44 81 00 00 06 00 24 68 03 01 00 27 00 65 2E 02 00 00 05 18 04 0B 01 00 24 68 1D ]
    12:42:45.687  DEBUG  RX ZSTACK: ZstackAfIncomingMsgAreq [groupId=0000, clusterId=0006, srcAddr=6824, srcEndpoint=03, destEndpoint=01, wasBroadcast=false, linkQuality=39, securityUse=false, timeStamp=00022E65, seqNumber=00, data=18 04 0B 01 00]

    I'm really at a loss to see where to take this - we have a statement from TI above that says that there is a bug ->

    > After looking through Z-Stack code it appears that the SeqNum is equivalent to TransSeq which is set to cmd.Data[0] instead of cmd.TransSeqNumber inside ZDP_IncomingData, which therefore returns a Success message (0x00) as compared to an actual sequence number. I will have a Software Developer follow up on this.

    If this is the case, then I guess we just have to live with this being always 0.

  • 0 in reply to Chris Jackson
    Genius 3415 points

    You can track ZCL command using the ZCL Transaction Sequence Number. For ZDO messages you can use the defined MT ZDO messages to have the transaction ID from MT_ZDO_MSG_CB_INCOMMING, this event is not triggered if you build ZDO messages with an AF request.

  • 0 in reply to Jose Maria Alvarez
    Intellectual 650 points

    > this event is not triggered if you build ZDO messages with an AF request.

    Can you clarify what event you are referring to that is not generated when using the AF request?

    Thanks.

  • 0 in reply to Chris Jackson
    Genius 3415 points
    MT_ZDO_MSG_CB_INCOMMING will not be triggered when you send ZDO messages with an AF data request.
  • 0 in reply to Jose Maria Alvarez
    Genius 3415 points

    By looking further I found that TransSecNum field of AF_INCOMMING_MSG is always set to 0x00 from Z-Stack library. However this is an internal sequence number that doesn't go Over-The-Air and is not necessary to keep track of the responses. In the case of ZCL commands you can  use the ZCL Transaction Sequence Number form the ZCL header, since any response to a ZCL command will have the same ZCL Transaction Sequence Number as the request.

  • 0 in reply to Jose Maria Alvarez
    Intellectual 650 points

    > MT_ZDO_MSG_CB_INCOMMING will not be triggered when you send ZDO messages with an AF data request.

    Well, it is triggered when sending an AF data request - this is how we are sending all the ZDO messages, and the responses are definitely received through the MT_ZDO_MSG_CB_INCOMMING callback.

    > By looking further I found that TransSecNum field of AF_INCOMMING_MSG is always set to 0x00

    Ok, so I guess at this point there is nothing that can be done and we will just work around this bug in our framework.

    Thanks for your help.

  • 0 in reply to Chris Jackson
    Genius 3415 points

    You are right about MT_ZDO_MSG_CB_INCOMMING. I think that I made a mistake registering the wrong ZDO cluster the last time.

    You welcome, and if you need something else don't hesitate in asking for help.