• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 56 subscribers
  • Views 397 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.

ZACCEL_SEND_DATA_CNF and false acknowledgements (ZApsNoBoundDevice)

Zaphod
Prodigy 155 points


Hi,

We keep receiving ZACCEL_SEND_DATA_CNF indications from ZACCEL, but with ZACCEL_SEND_SUCCESS set to unsuccessful (i.e. zaccelIndFlags == 0).

Looking into this, we found this is what happens:

1) zaccelPoll() is called on regular basis by appExecHost()
2) Calls rpcRsp(uint8 *pBuf)
3) rpcRsp detects this as a MT_RPC_SYS_SAPI case, and calls sapiRsp(uint8 *pBuf)
4) sapiRsp detects this as a MT_SAPI_SEND_DATA_CNF, and calls zb_SendDataConfirm
5) zb_SendDataConfirm checks the status and finds it is 0xB9 (ZApsNoBoundDevice), so it sets zaccelIndFlags &= ~ZACCEL_SEND_SUCCESS;

This causes our application to constantly receive ZACCEL_SEND_DATA_CNF indications, where zaccelIndFlags == ~ZACCEL_SEND_SUCCESS.

We are not using Binding in our application at all. We are also hardly ever requesting APS acknowledgments in messages.

Why is this happening? how can we stop CC2480 from raising this error?

 

  • 0
    TI__Mastermind 19350 points

    You can stop the CC2480 from raising the error mentioned by not using SAPI - as you see, it is not designed for what you are trying to do. Go directly via AF & ZDO layer calls. Or, since you don't care for binding, simply disconnect the error chain in sapiRsp() if the return value is equal to ZApsNoBoundDevice ... or disconnect the error chain altogether. You have been given the full source code of ZASA so that you can mold it into, or better, simply use it as a simplistic model for a more sophisticated, and hopefully eloquent, real-life application.

     On a side note, "&= ~" is a well-known C-construct for setting a bit mask to zero and the C-statement "foo &= ~BIT_MASK" does not result in "foo == ~BIT_MASK" unless the value of foo was already equal to ~BIT_MASK or equal to 0xFF.

     

  • 0 in reply to Dirty Harry
    Prodigy 155 points

    Hi Dirty Harry,

    Thanks for the info. Indeed what I did was to disconnect the error chain as you said in sapiRsp(). I do wonder why it is related to the SAPI layer??

    Re your side note: I perfectly understand bitwise operators, its just that in the previous post I wrote it pseudo-code style, but thanks anyway :)

    Zaph