WEBENCH® Tools/CC2652R: ZDP-trans-ID is not ZDP-sequence-number.

6366.zd_profile.h

4174.zd_profile.c

Hi Aries,

From my observation, I don't see the need to split ZDP_TransID into two variables. Consider the following use-case that I reproduced with our latest code (4.10 SDK):

1. Start a network with 2 nodes (ZED + ZC)

2. From the sample application, send ZDP IEEE Addr Req from ZED -> ZC using Zstackapi_ZdoIeeeAddrReq(). This tells the stack to call the API ZDP_IEEEAddrReq(), which sends a ZDP IEEE Addr Req from Endpoint 0 on the ZED to Endpoint 0 on the ZC. Let's say ZDP_TransID in this case is 61. If we look at a sniffer log, you can see the value 61 in the field ZDP Transaction Sequence Number within the APS Payload of the command.

3. On the ZED, after successfully buffering the ZDP IEEE Addr Req at the NWK Layer to eventually be sent over-the-air, we will first increment ZDP_TransID to 62 and then internally send a NLDE_DataCnf() for this packet. This will eventually call the API afDataConfirm(), which sends an AF_DATA_CONFIRM_CMD to the endpoint which originally requested the command. In this case, that would be the ZDO endpoint 0, so the AF_DATA_CONFIRM_CMD event within zd_app.c will receive and process this message.

4. On the ZED, within ZDApp_ProcessOSALMsg() we will process the case for AF_DATA_CONFIRM_CMD and if you were to place a breakpoint here and view the value of the local variable afDataConfirm->transID, you will see that it is equal to 61. The ZDO layer doesn't need to do anything with this incoming message so it just discards it, but if you wanted you could put another callback function in here to do some further verification. As mentioned above, if you were to compare afDataConfirm->transID to ZDP_TransID at this point, they will not match because ZDP_TransID is incremented immediately after a command is successfully buffered at the NWK layer.

If you want to verify that a command was sent successfully via your own mechanism, you would need to save another copy of ZDP_TransID into your own structure (array, circular buffer, etc) at the time the command is sent, i.e. within the ZDP API right before calling fillAndSend(), and then create a callback function within the AF_DATA_CONFIRM_CMD case within zd_app.c to match the transaction ID. You shouldn't need to do that though because the stack already does this kind of logic internally. Note that the sample application never receives AF_DATA_CONFIRM_CMD for the ZDP command, it is received by the stack instead since it originates from endpoint 0 and is sent back to endpoint 0 (the internal ZDO endpoint).

If this does not cover your use case, can you please explain further using a specific example where what I mentioned above fails or has issues? Thanks.