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.

[参考译文] CC2652P:"AF_DataRequest"使用"Success "返回无法触发"afDataConfirm"每次。

Guru**** 1087160 points
Other Parts Discussed in Thread: SIMPLELINK-CC13XX-CC26XX-SDK, Z-STACK, CC1352P, CC2652P
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1178438/cc2652p-af_datarequest-with-success-returning-could-not-trigger-afdataconfirm-everytime

器件型号:CC2652P
主题中讨论的其他器件:SIMPLELINK-CC13XX-CC26XX-SDKZ-STACKCC1352P

SDK 版本:simplelink_cc13xx_cc26xx_sdk_6_30_01_03

我在 "AF_DataRequest"和 "afDataConfirm"中标记了执行计数器。 我强制我的坐标和路由器相互发送应用程序数据 。 发送被触发的时间非常长、为10ms。 10分钟后、 AF_DataRequest 的计数器不等于   "afDataConfirm"的计数器。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好 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 事件将丢失。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    谢谢 Aries。  您的调查结果与我自己的调查结果一致、我能够确认您建议的修复方法可以改善观察到的行为。  我已将您的建议转交给 Z-Stack 软件开发团队进行进一步分析。

    此致、
    Ryan

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

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

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

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

    此致、
    Ryan