zcl_SendCommand() 返回成功但没有发送出数据包

是终端设备对路由吗？终端设备需要接收response吗？poll rate多少

感谢VV大神抽空回答。

是协调器对路由设备的控制，函数zcl_SendCommand() 返回值是ZSuccess，但是抓包发现有时数据包没有发出来。

协调器与高通的一款芯片是通过SPI DMA方式通信的，CC2530DMA中断后解析完命令调用zcl_SendCommand() 发送控制命令，函数返回ZSuccess则调用SPI DMA发送消息告诉主机成功，SPI的gpio是 P0_4: SSN     P0_5: SCK      P0_3: MOSI      P0_2: MISO，请问难道这两者会干扰吗？因为有时候CC2530 RF死机后，SPI也死机了。

还有就是，zcl_SendCommand()设置了默认响应，这个默认响应的消息内存也得到释放，是不是有其他需要注意的地方呢？

1. 导致RF与SPI死机的原因找到了，是由于ZStack的调度时间为320us，而程序DMA中断后处理程序执行时间超过了这个时间导致的。

2. zcl_SendCommand()返回ZSuccess但抓包没有抓到是由于，这个返回值仅表示数据包成功到了发送缓冲区，有没有真正的发送出去还得靠MAC ACK和APS ACK进行检测。

问题： 1. 什么原因会导致数据到发送缓冲区后出现没有调制成载波出去呢？

            2. 如果数据包没有发送出去，有没有触发事件到应用层呢？

你填写的参数是否都正确？

参数是对的，我调用的是on/off的宏：

tmp = zclGeneral_SendOnOff_CmdOn( dstAddr.endPoint, &dstAddr , false ,netServiceSeqNum++ );

补充一下，出现返回ZSuccess但是抓包没有抓到数据包这种情况是做压力测试时出现的，测试的方法是每隔1s协调器向路由器发送On/Off命令，测试时间1小时就出现了几次这种现象，PA用的CC2592，phyTransmitPower设置为20。

这个问题可能对产品在真实应用中出现很大的隐患，还请VV大神解答一下，硬件上的问题除了PA，应该没有其他影响，但是PA只是调制信号，按理说不应该会有影响；还是说这个压力测试的要求有点高呢？

还有就是有没有办法在应用层快速知道数据包是否真的发送出去了？

你是点对点做的测试，还是一对多的时候做的测试。

您好，这个问题解决了吗？我现在也遇到这个问题了，不知道该怎么弄

1. 解决方法：

这个问题可以在应用层加超时机制和重传解决。

2. 根本原因猜想：

AF_DataRequest只是把数据包打包后到达MAC层的Queue等待发送，

802.15.4中有一个原语purge，这个原语的作用对象是协调器，作用是删除发送Queue中的一个消息，

所以可能由于某种原因这个原语被使用了。

3. 测试思路建议：

purge接口在 mac_api.h 中描述如下：

/**************************************************************************************************
* @fn MAC_McpsPurgeReq
*
* @brief This function purges and discards a data request from the
* MAC data queue. When the operation is complete the MAC sends
* a MAC_MCPS_PURGE_CNF.
*
* input parameters
*
* @param msduHandle - The application-defined handle value
*
* output parameters
*
* None.
*
* @return None.
**************************************************************************************************
*/
extern void MAC_McpsPurgeReq(uint8 msduHandle);

从描述中可以看到这个原语有confirm，所以可以在CNF回掉函数中进行测试打印。

4.  如果有进行测试希望可以分享结果哈，谢谢！

AF_DataRequest还不是直接打包到MAC层的Queue，还有网络层的缓存。所以你想做Purge是没用的。唯一解决办法是不要连续调用，AF_DataRequest连续发送数据时，中间至少有10ms的超时间隔。也就是说要执行osal_run_system超过10ms