[参考译文] CC2652P：&quot；AF_DataRequest&quot；使用&quot；Success &quot；返回无法触发&quot；afDataConfirm&quot；每次。

您好 Aries、

感谢您分享您的调查结果。  您是否正在评估 SIMPLELINK-CC13XX-CC26XX-SDK v6.30、以及之前的 SDK 版本是否存在此问题？  要重新创建此问题，需要对默认应用程序进行哪些更改？  您是否也有任何监听器或调试器日志可供共享？  计数器不再以什么方式相等？

此致、
Ryan

1. 我在调试代码时发现此问题。 我在  "AF_DataRequest"和 "afDataConfirm"中分别设置了两个变量。 并长时间运行 调试。  然后停止转换和 调试、我发现  "AF_DataRequest"中的变量 不仅仅是  "afDataConfirm"中的变量。

我已经在 SDK 5.40上测试了我的代码、没有这个问题。

我已将其更新为 SDK 620、但这个问题也没有出现。

AF_DataRequest 要比 afDataConfirm 多大？  Z-Stack 确实从 v6.20 SDK 中的 TI-RTOS 升级到了 v6.30 SDK 中的 TI-RTOS7、但除此之外没有对 AF 层进行实质性更新(TI 目前正致力于将 Z-Stack 更新到下一个即将发布的 Zigbee 协议版本)、因此报告的此错误令人惊讶。  我能否通过设置一个每10ms 在 ZR 上调用 Zstackapi_AfDataReq 的连续计时器来复制此行为？  是否启用了 AF ACK？

此致、
Ryan

在 SDK 6.30中，我的坐标每20ms 发送 AF 数据包，每 10ms 接收 AF 数据包。 当 AF_DataRequest 计数器达到3000，以上时、它 比 afDataConfirm 计数器多256。  

但在 SDK 6.20中 、我的坐标每 1ms 发送 AF 数据包、每 1ms 接收一台路由器的 AF 数据包、 AF_DataRequest 计数器和 afDataConfirm 计数器保持 相等 、但两者都大于65535。

在我的测试中，协调发送到路由器而不启用 APS-ACK-Enabled，但路由器发送到协调将启用 APS-Ack 和 ZCL-Default-RSP。  

TI-RTOS7的计时器系统与 TI-RTOS 是否不同？  afDataConfirm 是否可以由计时器触发(例如超时)？ 有时 AF_DATA_CONFIRM_MSG 可被应用程序用作超时计时器。

谢谢 Aries、我将尝试重新创建问题并进一步调查其根本原因。  我目前不知道 RTOS 计时器系统之间的差异。  我将在有更新时通知您。

此致、
Ryan

您好 Aries、

我无法在  上述刻度上复制不匹配的 AF_DataRequest/afDataConfirm 计数器。  v6.20和 v6.30 SDK 的结果也完全相同。  您能否查看我的实施情况、并告诉我是否应该更改任何内容以重新创建行为？

e2e.ti.com/.../8206.af.ce2e.ti.com/.../6558.zcl_5F00_samplesw.c

此致、
Ryan

 每10ms 协调发送 AF-Packet 到路由器，每  10ms 协调发送 AF-Packet。

运行此发送5~10分钟。

我的发送由 UART-Software 控制、UART-Software 每10ms 输入要协调和路由器的数据。

   在使用10ms 数据包间隔测试 v6.30 SDK 时、我观察到非常类似的 AF_DataRequest/afDataConfirm 计数器。  协调器显示完全相同的值、路由器在运行几分钟后会稍微漂移。  但是、v6.20 SDK 上也会显示相同的行为。  我的测试依赖于计时器而不是 UART 控制来发送消息、您认为 UART 接口对您观察到的行为有直接影响吗？

此致、
Ryan

您能加快收发速度吗？ 在路由器发送到协调时协调发送到路由器。

在我的坐标中、它配置如下

-DMAC_CFG_APP_PENDING_QUEUE=TRUE
-DMAC_CFG_TX_DATA_MAX=20
-DMAC_CFG_TX_MAX=32
-DMAC_CFG_RX_MAX=20

-DNWK_MAX_DATABUFS_WAITING=32
-DNWK_MAX_DATABUFS_SCHEDULED=20
-DNWK_MAX_DATABUFS_CONFIRMED=20
-DNWK_MAX_DATABUFS_TOTAL=48
-DNWK_INDIRECT_MSG_MAX_PER=6

在 SDK 6.20上、HEAPMGR_SIZE 为40960KB (0xA000)

在 SDK 6.30上、堆大小是自动分配的。

协调器每隔10毫秒发送一次 APS ACK，路由器每隔10毫秒发送一次 APS ACK。  更改 nwk_globals.c 和 f8wcoord.opts 内的定义似乎不会影响行为。  将数据包间隔减少到10ms 以下可能会导致瓶颈、AF 计数差异、从而导致应用程序性能不佳、正如我在 v6.20和 v6.30 SDK 上的路由器所注意到的那样。  您的应用程序可能会删除 AF ACK 请求、缩短数据包间隔、或依赖接收  AF_DATA_CONFIRST_MSG 来确认消息是否 已在下一个数据包排队之前被确认。

此致、
Ryan

我的测试是制造瓶颈、AF-Request 的计数器将大于 AF-Confirm 的计数器。 但是、当我停止翻译一段时间时、在 SDK 6.20上 、AF-Confirm 的计数器将等于 AF-Request 的计数器。 但在 SDK6.30上、AF-Confirm 的计数器不能与 AF-请求的计数器相同。

我的测试项目基于 zc_genericapp_CC1352P_2_LAUNCHXL_tirtos7_ticang

器件型号：CC2652P

不仅是 SDK6.30、而且还有其他 SDK、在这种情况下会发生此问题。 当坐标和路由器正忙时，某些 AF-Send (带 AP-Ack-Request-Enabled )将不会触发“afDataConfirm”(afDataConfirm)。 但可以释放"nwkDataBufQueue"中的发送记录。 因此、我建议 在删除 AP-Ack-Request-Enabled 发送的记录时触发带有"ZApsNoAck"的"afDataConfirm"。

我找到了新的。 无论 SDK 的版本如何、当启用 AP-Request 时、AF_DataRequest 都有可能无法触发 afDataConfirm。 包括 SDK 5.40和 SDK 6.20。

我在 Z-stack 3.0.2中看到了 APS-Ack-Retry 发送的源代码。 重试发送由"NLMEDE_CB.c"中 funcoun "NLDE_DataIndication (NLDE_DataIndication)"中的"APSDE_DataReq"进行传输。  但没有 处理  APSDE_DataReq 的预留计划、未成功。  

我看到"APSDE_DataREQ"也会传输重试发送、这意味着旧消息将被给定、并且将分配新的发送缓冲区。 如果  APSDE_DataReq 重试失败、则 af-Confirm 事件将丢失。

TI 最好同时发布适用于 TI-RTOS7和较旧 TI-RTOS 的解决方案。   Z-Stack 软件开发团队应在圣诞节假期之前发布库文件或更新包

我已通过私人消息联系、为您提供解决方案。

此致、
Ryan