• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 55 subscribers
  • Views 633 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.

MT_AF_INCOMING_MSG does NOT work (and a way to solve it)

Sjef de Krijger
Expert 1405 points

I have MT_AF_FUNC, MT_AF_CB_FUNC enabled. I don't see any MT_AF_INCOMING_MSG of any kind, ever. Some inspection in the source code revealed that the code to generate these messages is never executed:

  // If ZDO or SAPI have registered for this endpoint, dont intercept it here
  if (AFCB_CHECK(CB_ID_AF_DATA_IND, *(epDesc->task_id)))
  {
    MT_AfIncomingMsg( (void *)MSGpkt );
    // Release the memory.
    osal_msg_deallocate( (void *)MSGpkt );
  }
  else
#endif
  {
    // Send message through task message.
    osal_msg_send( *(epDesc->task_id), (uint8 *)MSGpkt );
  }
}

lthe if-statement is always false because the task ID is never equal to that of MT. Messages always have task ID's of either the ZCL or ZDApp. Which is logical in my opinion.

Does the MT_INCOMING_MSG command work at all?

Edit:

#if defined ( MT_AF_CB_FUNC )
  // If ZDO or SAPI have registered for this endpoint, dont intercept it here
//  if (AFCB_CHECK(CB_ID_AF_DATA_IND, *(epDesc->task_id)))
//  {
    MT_AfIncomingMsg( (void *)MSGpkt );
    // Release the memory.
//    osal_msg_deallocate( (void *)MSGpkt );
//  }
//  else
#endif
  {
    // Send message through task message.
    osal_msg_send( *(epDesc->task_id), (uint8 *)MSGpkt );
  }
}

Edit the source in AF.c (afBuildMSGIncoming) as above and all messages are send to MT as well as the app. It works, but it doesn't really feel 'right'. Can anyone suggest a better solution?



  • 0
    Guru 735695 points

    If you use ZTool to connect, can't it receive?

  • 0 in reply to YiKai Chen
    Expert 1405 points

    It can receive, viz

    <TX>03:08:07.02 COM3 ZDO_IEEE_ADDR_REQ (0x2501)
        ShortAddr: 0x0000
        ReqType: SINGLE_DEVICE_RESPONSE (0x0)
        StartIndex: 0x00

    <RX>03:08:07.04 COM3 ZDO_IEEE_ADDR_REQ_SRSP (0x6501)
        Status: afStatus_SUCCESS (0x0)

    <RX>03:08:07.05 COM3 ZDO_IEEE_ADDR_RSP (0x4581)
        Status: ZDP_SUCCESS (0x0)
        IEEEAddr: 0x00124B000231764D
        NwkAddr: 0x0000
        StartIndex: 0x0F
        NumAssocDev: 0x00
        AssocDevList

    <RX>03:08:20.5 COM3 ZDO_END_DEVICE_ANNCE_IND (0x45C1)
        SrcAddr: 0xB9A5
        NwkAddr: 0xB9A5
        IEEEAddr: 0x00124B0002317671
        Capabilities: 0x8E

    But, never the AF_INCOMING_MSG AREQ (0x81). With debugging, I found out that the responsible code is never called (see OP).

  • 0 in reply to Sjef de Krijger
    Guru 735695 points

    What and how do you send from ZED to ZC using AF_DataReq?

  • 0 in reply to YiKai Chen
    Expert 1405 points

    Ok, maybe this is the problem then. As in my understanding, the AF_INCOMING_MSG AREQ would provide me with an echo of all data going into the endpoints of my device (the coordinator).

    I've only been sending messages through AF_Datareq to turn on or off a LED on the end device (works) and to read some attributes from it (also works, but here, the AF_INCOMING would be handy, then I don't need to debug_str them out from the application's read response handler). These AF_Datareq were also sent from Z-TOOL (so not as you say from ZED to ZC, but from ZC to ZED).

  • 0 in reply to Sjef de Krijger
    Guru 735695 points

    If you want to see AF_INCOMING_MSG, it will need you to send message from ZR or ZED to ZC using AF_DataReq. So, there is nothing wrong with the source code.

  • 0 in reply to YiKai Chen
    Expert 1405 points

    Thank you for clearing this up. I didn't assume something wrong with the source code, but is seems the documentation (MT API) could be more clear - I do not know the ideas behind the code, so I have to take the documentation as a lead. Apparently, it is wrongly suggesting that AF_INCOMING_MSG will be called for all the incoming messages at the device. It's no big problem because for my specific application, I'll just go on and apply my 'fix' and be on my merry way :)

    Thanks again for your answers Chen.