[参考译文] CC2674P10：报告 Z-Stack 中消息大小过大和碎片化的问题

admin

Other Parts Discussed in Thread: CC2674P10, Z-STACK

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1421511/cc2674p10-reporting-issues-with-large-message-size-and-fragmentation-with-z-stack

器件型号：CC2674P10
Thread 中讨论的其他器件：Z-stack、

工具与软件：

您好！

我使用的是来自 SimpleLink CC13xx/CC26xx SDK 版本7.40.00.77的 Z-Stack 的 CC2674P10微控制器。

在我的项目中、我将尝试实现从终端设备向协调器的报告。我添加了 ZCL_cluster_ID_MS_electric_measurement = 0x0b04集群、具有几个可报告的属性。我在终端设备和协调器之间创建了绑定、但我看不到协调器上发生了任何报告。

。 bdb_event_loop、特别是在 bdb_RepReport(从 bdb_reporting.c)、我注意到我通过以下函数定期发送报告命令：

zcl_StackSendReportCmd(clusterEndpointItem->endpoint, &dstAddr, 
                       clusterEndpointItem->cluster, pReportCmd, 
                       ZCL_FRAME_SERVER_CLIENT_DIR, 
                       BDB_REPORTING_DISABLE_DEFAULT_RSP, 
                       zcl_getFrameCounter());

但是、协调器侧不接收任何内容。

进一步深入了解 AF_DataRequest传递函数(IN af.c)、我看到以下代码：

if (len > afDataReqMTU(&mtu)) {
  if (apsfSendFragmented) {
    stat = (*apsfSendFragmented)(&req);
  } else {
    stat = afStatus_INVALID_PARAMETER;
  }
} else {
  stat = APSDE_DataReq(&req);
}

当我计算电气测量仪表组的报告有效载荷大小(ZCL_cluster_ID_MS_electric_measurement)时、(即 ∑(所有可报告的属性数据类型的长度) + (2 bytes for attribute ID + 1 byte for data type) * number of reportable attributes) 它达到大约90字节。。 afDataReqMTU(&mtu)该函数返回的最大大小为82字节、因此它始终调用 (*apsfSendFragmented)(&req)函数(其源代码我无法访问)、返回。 stat = 0x02 (ZInvalidParameter)

我怀疑这个问题可能与碎片有关。我尝试了添加 ZIGBEE_FRAGMENTATION但遗憾的是、问题仍然存在。

并减少可报告属性的数量、以保持以下大小 afDataReqMTU(&mtu)、它通过 APSDE_DataReq(&req)功能、一切都按预期工作、协调器成功收到报告消息。

我正在寻找一种解决方案、即使在邮件大小较大的情况下也能实现报告功能。如何解决此分段问题或允许发送更大的报告消息？

非常感谢您提供任何帮助或建议！

3 个月前

0 admin 3 个月前

TI__Guru**** 1783340 points

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

您好！

感谢您联系并提供所有这些信息。我已经研究了指向 APSF_SendFragmented 的 apsfSendFragmented 源代码。此函数仅返回 afStatus_INVALID_PARAMETER、具体取决于目标地址模式：

afStatus_t APSF_SendFragmented(APSDE_DataReq_t *pReq)
{
  APSF_TxObj_t *pTx;
  afDataReqMTU_t mtu;
  uint8_t blockSize;
  uint16_t  dstAddr;

  if ( pReq->dstAddr.addrMode == AddrNotPresent ||
       pReq->dstAddr.addrMode == AddrGroup      ||
       NLME_IsAddressBroadcast(pReq->dstAddr.addr.shortAddr) != ADDR_NOT_BCAST )
  {
    return afStatus_INVALID_PARAMETER;
  }

  // Find out the destination short address
  if ( pReq->dstAddr.addrMode == Addr64Bit )
  {
    if ( APSME_LookupNwkAddr( pReq->dstAddr.addr.extAddr, &dstAddr ) == FALSE )
    {
      return afStatus_INVALID_PARAMETER;
    }
  }
  else
  {
    dstAddr = pReq->dstAddr.addr.shortAddr;
  }

与 bdb_RepReport 一样、它将设置 dstAddr.addrMode =(afAddrMode_t) AddrNotPresent、给定间接寻址旨在使用存储的绑定表信息。这似乎不受分段支持、因为它会返回 FAIL 状态、并且只允许短目标地址。

我将联系 Zigbee 研发团队、进一步了解为什么在 APS 分段层内设置此条件。同时、您是否能够确定目标设备的短地址并相应地修改 bdb_RepReport 以满足此要求？或者、是否可以将属性分散在多个报告命令中、以避免碎片化？

此致、
Ryan

Zigbee®︎ 和 Thread（参考译文帖）

Zigbee®︎ 和 Thread（参考译文帖）(Read Only)

[参考译文] CC2674P10：报告 Z-Stack 中消息大小过大和碎片化的问题