主题中讨论的其他器件:SIMPLELINK-CC13XX-CC26XX-SDK、 Z-STACK、 CC1352P
SDK 版本:simplelink_cc13xx_cc26xx_sdk_6_30_01_03
我在 "AF_DataRequest"和 "afDataConfirm"中标记了执行计数器。 我强制我的坐标和路由器相互发送应用程序数据 。 发送被触发的时间非常长、为10ms。 10分钟后、 AF_DataRequest 的计数器不等于 "afDataConfirm"的计数器。
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.
SDK 版本:simplelink_cc13xx_cc26xx_sdk_6_30_01_03
我在 "AF_DataRequest"和 "afDataConfirm"中标记了执行计数器。 我强制我的坐标和路由器相互发送应用程序数据 。 发送被触发的时间非常长、为10ms。 10分钟后、 AF_DataRequest 的计数器不等于 "afDataConfirm"的计数器。
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。
您好 Aries、
我无法在 上述刻度上复制不匹配的 AF_DataRequest/afDataConfirm 计数器。 v6.20和 v6.30 SDK 的结果也完全相同。 您能否查看我的实施情况、并告诉我是否应该更改任何内容以重新创建行为?
e2e.ti.com/.../8206.af.ce2e.ti.com/.../6558.zcl_5F00_samplesw.c
此致、
Ryan
在使用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 事件将丢失。