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: Error using AF_DATA_REQUEST

Part Number: CC2531
Other Parts Discussed in Thread: Z-STACK,

We are seeing an error returned when trying to send a ZCL packet using AF_DATA_REQUEST. The method works fine when sending a ZDO message, but returns error code 2 for ZCL.

22:45:33.470  DEBUG  ZSTACK TX: ZstackAfDataRequestSreq [dstAddr=CC22, destEndpoint=03, srcEndpoint=01, clusterId=0006, transId=1A, options=[AF_ACK_REQUEST, AF_DISCV_ROUTE], radius=31, data=01 17 00]
22:45:33.470  DEBUG  ZSTACK TX: FrameData [ data=FE 0D 24 01 22 CC 03 01 06 00 1A 30 1F 03 01 17 00 E2 
22:45:33.475  DEBUG  ZSTACK RX: FrameData [ data=64 01 02 ]
22:45:33.475  DEBUG  ZSTACK RX: ZstackAfDataRequestSrsp [status=AF_INVALID_PARAMETER]

22:42:34.968  DEBUG  ZSTACK TX: ZstackAfDataRequestSreq [dstAddr=0000, destEndpoint=00, srcEndpoint=00, clusterId=0032, transId=11, options=[AF_ACK_REQUEST, AF_DISCV_ROUTE], radius=31, data=00 00]
22:42:34.969  DEBUG  ZSTACK TX: FrameData [ data=FE 0C 24 01 00 00 00 00 32 00 11 30 1F 02 00 00 27 
22:42:34.977  DEBUG  ZSTACK RX: FrameData [ data=64 01 00 ]
22:42:34.978  DEBUG  ZSTACK RX: ZstackAfDataRequestSrsp [status=SUCCESS]

We have added an endpoint 1 using AF_REGISTER, so I'm wondering why we would get this error when trying to send a request.



  • As you are seeing a AF_INVALID_PARAMETER response I would suggest that you re-evaluate your destination address, source/destination endpoints, and cluster ID. Registration is also important and YK has a post a few months back detailing the process and expectations: e2e.ti.com/.../2712757

    Regards,
    Ryan

  • I did check the parameters are correct before posting, but to clarify -:

    The node exists (we are sending ZDO messages to it and getting responses), the endpoint exists (we have received the descriptor for it), and the cluster ID is ok (it's 6 which is the OnOff cluster). This is why I was wondering if there was something else, not directly related to this call such as local endpoint registration (which I think is ok).
  • As an aside, I tried some different software, and this works with exactly the same command -:

    21:06:12.092  DEBUG  Sending frame FE 0D 24 01 A8 72 03 01 06 00 05 30 1F 03 01 05 00 DB 
    21:10:22.871  DEBUG  ZSTACK TX: FrameData [ data=FE 0D 24 01 A8 72 03 01 06 00 04 30 1F 03 01 04 00 DB ]
    

    Other than the transaction IDs, the two commands are the same, so I don't think that this is an issue with the parameters. Is there any way to find out what is causing the error?

    Thanks

  • What do you mean by "different software" and what version of Z-Stack are you evaluating? It is worth mentioning that the data type and length of some cluster IDs are filtered by Z-Stack's source code. For example, the On/Off cluster should only be a binary value represented in a single byte and any other format could return an invalid parameter.

    Regards,
    Ryan
  • Our Java framework splits the stack and dongle drivers. We have an old driver (written by another party), which is the "different software" I referred to, but we are currently rewriting this completely, and that's what we're testing here. Both versions are generating the same data - one works, and one results in an error.

    The Z-Stack version is 3.0.2.

    I don't think there's anything wrong with the ZCL packet. The command doesn't have any "value" so I'm not sure what the binary value you refer to is. The commands in the OnOff cluster (at least the On and Off commands) are just simple commands.

    Thanks for your help.

  • Thanks for clarifying your environment. Sorry for not being clear, the comment about the data structure was a general comment and not meant as an indication of what could be wrong with your environment.

    Comparing the packets, you are correct that the only differences are the destination address, transaction ID, and transaction sequence number, none of which indicate an issue. If a different driver works then the Z-Stack project has the correct MT command pre-definitions enabled, I would therefore recommend that you further investigate the communication layer used by the two different drivers.

    Regards,
    Ryan
  • Thanks - I was hoping that maybe there was a description somewhere of what the error response meant?

  • Make sure you have register 0x01 as source endpoint before you use it to send AF message.
  • AF_INVALID_PARAMETER means that Z-Stack receives an error when attempting to process the command with the parameters supplied, YK gives an example for which ZstackAfDataRequestSreq will fail if srcEndpoint 0x01 is not properly registered on the device.

    Regards,
    Ryan
  • As explained earlier, we do register the endpoint, and this does come back with a SUCCESS response. We also agreed that the other parameters in the call are also not invalid, so I'm trying to understand what the error means. I am not 100% sure that the response means invalid parameter - the API doesn't document this, and I've inferred it from other information I've found in header files, so it might be an incorrect assumption?

  • I would suggest you to set a breakpoint inside ZNP source code and debug/trace what happens when you see this issue.
  • Thanks. We are trying to avoid having to do this sort of thing as we are only working on the host side using standard ZNP build and do not have the tools for dealing with the NCP side. Unfortunately, documentation is extremely lite so it’s rather difficult to move forward.

  • Do you have an oscilloscope or logic analyzer with which you can evaluate the communication and confirm that the commands between the two host drivers are exactly the same? Any differences would be worth investigating.

    Regards,
    Ryan
  • I do have a scope and logic analyser, but I would expect that if the serial data dump that is sent to the UART is the same in both cases, that the data sent on the UART line will also be the same ;)

  • But then what other differences could exist between two drivers which produce different results?

    Regards,
    Ryan
  • I don't know - that's why I was asking ;)

    I was hoping that someone from TI might be able to help by explaining what the error response 0x02 means and in what conditions this occurs. 

  • Then I apologize that no further insight can be provided. In Z-Stack an invalid parameter is returned in most instances where the request is not successful. You would have to further debug the AF data request on the CC2531 to know more about the specific reason.

    Regards,
    Ryan
  • In the absence of documentation explaining the meaning for the errors, is there source code we can look at? As we try to implement the interface using the API documentation, I'm not familiar with the source or if the complete source is available?
  • You can set a breakpoint in MT_AfDataRequest (inside MT_AF.c) and trace into AF_DataRequest (inside AF.c) to see what causes it returns INVALID_PARAMETER.