Zigbee®︎ 和 Thread（参考译文帖）(Read Only) - 最近的话题

[参考译文] CC2652RSIP：ZigBee OTA 更新卡在~60%的位置（片外 OTA、Zr_Genericapp 示例）

admin — Thu, 26 Mar 2026 07:22:27 GMT

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1630270/cc2652rsip-zigbee-ota-update-stuck-at-60-off-chip-ota-zr_genericapp-example

器件型号： CC2652RSIP
主题中讨论的其他部分： Z-stack、 Sysconfig

尊敬的团队：

我在使用 Zigbee OTA 时遇到了一个问题、固件更新始终会卡住 60、一些 timwe 20、45、49、11、3 进度。

设置详细信息：

器件：基于 CC13x2/CC26x2 的定制硬件
使用示例：zr_generic（针对 OTA 片外而修改）
OTA 类型：片外 OTA
外部闪存：已配置和验证
OTA 服务器：工作（相同的映像用于示例） zr_sw_ota_client_offchip
堆栈版本：Z-Stack 3.x（如果需要，请指定确切版本）

观察到的行为：

OTA 成功启动并通常进展至~60%
之后、进度便会停止、而不会恢复
器件在 OTA 期间不会复位
在 OTA 期间未观察到按钮或应用程序活动（似乎被阻止）
在某些尝试中、它也会卡在非常低的百分比 (~0.01%)

我尝试过的方法：

已验证外部闪存配置和链接器设置
与比较zr_sw_ota_client_offchip（工作案例）
确保正确包含 OTA 集群 (inCluster)
已检查状态轮询延迟（行为无变化）

问题：

什么会导致 OTA 以~60%等特定百分比失速？
zr_generic与相比、在中启用 OTA 时是否存在任何已知问题zr_sw？
这是否与缓冲区大小、块请求处理或时间（例如，状态轮询延迟）有关？
在 OTA 期间、是否预计应用程序循环会被阻止（无按钮响应）？

有关调试此问题或要检查的特定区域的任何指导都会非常有用。

提前感谢！

RE: [参考译文] CC2652RSIP：ZigBee OTA 更新卡在~60%的位置（片外 OTA、Zr_Genericapp 示例）

admin — Fri, 27 Mar 2026 12:37:34 GMT

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

尽管没有返回失败状态、但当您在调试器中暂停 OTA 应用程序时、调用栈的情况是什么？是否有任何栈溢出或堆问题的迹象？下面是调试指南。您能否在工作版本和非工作版本之间执行比较、以确定任何关键的栈或堆配置更改、以及 SysConfig 或链接器命令文件差异。您是否遵循了我之前提到的“向应用程序添加客户端功能“指南？

此致、
Ryan

RE: [参考译文] CC2652RSIP：ZigBee OTA 更新卡在~60%的位置（片外 OTA、Zr_Genericapp 示例）

admin — Fri, 27 Mar 2026 08:15:31 GMT

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

您好、Ryan、

ZR_SW_OTA_CLIENT_offchip 示例在 LP-CC2652RSIP 和定制电路板中均运行、我已成功测试。当我检查 ZR_genericapp 示例时、OTA 过程开始成功地卡在 60%的某个百分比下。这意味着不会出现任何错误或不退出或失败。始终保持在 60%。

控制器是 cc2652r1f

闪存为 w25q80dv

ZR_genericapp 为定制电路板以及 LP-CC2652RSIP 提供相同的行为。

此致、

Sushmitha.

RE: [参考译文] CC2652RSIP：ZigBee OTA 更新卡在~60%的位置（片外 OTA、Zr_Genericapp 示例）

admin — Thu, 26 Mar 2026 16:23:27 GMT

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

你好、Sushmitha、

我们已经确定了基准、您已经在您的系统上确认 ZR_SW_OTA_CLIENT_offchip 示例会执行 OTA 更新直至完成？您是否已在 LaunchPad 或定制硬件上验证过这一点？如果您是按照 Z-Stack 用户指南的说明在 LP-CC2652RSIP 上测试修改后的 ZR_generic、结果是什么？您引用的是哪个 SimpleLink F2 SDK 栈版本？此外、您的定制硬件上有什么外部闪存器件？ OTA 在失败后是否有任何调试日志或调用堆栈分析、例如 UI 会报告什么内容、或者可以在 ota_client.c 中添加其他打印 (ota Client_Upgrade Complete 应包含状态 ZOtaAbort)。您能否使用嗅探器设备捕获无线流量？

[quote]什么会导致 OTA 以~60%等特定百分比停止？[/quote]

听起来它可以在多个不同的百分比下退出、这表明可能存在 Zigbee 数据包通信故障。

[quote]在中启用 OTA 时是否存在任何已知问题zr_genericzr_sw？[/quote]

如果完全遵循“向应用程序添加客户端功能“指南、则不会执行此操作。我也不了解您的外部闪存器件。

[quote]这是否与缓冲区大小、块请求处理或时间（例如状态轮询延迟）有关？[/quote]

您需要仔细比较 ZR_generic 和 ZR_SW 之间的配置差异、因为它们应该相同。

[quote]在 OTA 期间、是否预计应用程序循环会被阻止（无按钮响应）？[/quote]

否、执行 OTA 时应用程序仍应在运行。关于如何初始化任务、需要进一步探讨这一点。

下面是 Zigbee 无线 (OTA) 升级 SimpleLink Academy 实验、供您参考。

此致、
Ryan

[参考译文] CC2340R5：ZB_NLME_STATUS_INDITION 的原因是什么？

admin — Mon, 09 Mar 2026 02:47:36 GMT

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1623876/cc2340r5-what-is-the-cause-of-zb_nlme_status_indication

器件型号： CC2340R5

      case ZB_NLME_STATUS_INDICATION:
      {
        zb_zdo_signal_nlme_status_indication_params_t *nlme_status_ind = ZB_ZDO_SIGNAL_GET_PARAMS(sg_p, zb_zdo_signal_nlme_status_indication_params_t);
        printf("Network operation %02x,nwk_addr = %02x\r\n", nlme_status_ind->nlme_status.status,nlme_status_ind->nlme_status.network_addr);
        break;
      }

在哪里可以找到由 nlme_status_ind->nlme_status.status 和 nlme_status_ind->nlme_status.network_addr?表示的状态位的含义在什么情况下会出现此信号？为什么在多次生成此信号后、协调器会重新启动？

RE: [参考译文] CC2340R5：ZB_NLME_STATUS_INDITION 的原因是什么？

admin — Mon, 23 Mar 2026 19:26:46 GMT

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

[quote]这是我作为协调器测试 onoff_light 的代码。我只为信号值添加了打印语句。我仍然使用 onoff_switch 作为终端[/quote]

我复制了您的测试、但无法复制该行为。我的 UART 日志中没有“Network operation 00“、只有默认情况下预期出现的“Unknown signal“（未知信号）（建议在末尾添加中断以保持一致性）。我的 ZC 从不重置。我正在使用 ZR 作为交换机、但我认为这不会有任何影响。

[quote]协调器保持通电状态、终端设备连接后重新编程[/quote]

您是否知道、如果没有额外的步骤、重新编程的开关将无法重新加入 ZC 照明、前提是 180 秒的允许加入窗口已结束？与我的测试一样、开关使红色 LED 闪烁、但在重新编程后无法与 ZC 通信、因为其 NV 闪存已被擦除。 ZC 没有适用于 ZB_Nwk_command_status_indirectal_transaction_expires 和 ZB_Nwk_command_status_no_route_available 的操作。

此致、
Ryan

[参考译文] CC2652P7：Z-Stack：ZigBee 协调器限制为 255 个关联器件、而不管 NWK_MAX_DEVICE_LIST 如何

admin — Thu, 19 Mar 2026 19:59:40 GMT

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1628171/cc2652p7-z-stack-zigbee-coordinator-limited-to-255-associated-devices-regardless-of-nwk_max_device_list

器件型号： CC2652P7

我们使用 CC2652P7 作为 Zigbee 协调器、需要支持超过 255 个相关器件。将 NWK_MAX_DEVICE_LIST 设置为任何值≥255 都会导致协调器在超过 256 个连接的器件后失败、但无法正确处理高于该阈值的关联。这在 SDK 8.32.00.07 和几个之前的版本上得到确认。

环境：
-设备：CC2652P7
- SDK：SimpleLink CC13xx/CC26xx SDK 8.32.00.07（在许多以前的版本上也已确认）
- CCS：20.5.0
编译器：TI Arm Clang 4.0.4.LTS

在调查根本原因后、我们发现 libZStack_nwk_all.a 中的 assoc_list.o 是使用 deviceTableIndex_t = uint8_t 进行编译的、这意味着不使用 -DLARGE_DEVICE_TABLE、NWK_MAX_DEVICES≤255。由于此文件仅作为二进制文件分发、因此无法使用正确的标志对其重新编译。当应用程序设置 NWK_MAX_DEVICE_LIST = 300 时、该库会静默地将 gNWK_MAX_DEVICE_LIST 读取为 1 字节值、获取 45、而不是 301。我们在设备上确认了以下内容：调用 AssocAddNew 300 次、只有 45 次成功；AssocCount 也返回 45 次。

该修复程序已存在于 SDK 头文件中：large_device_table 无条件强制 deviceTableIndex_t = uint16_t。它在构建出厂库时根本不使用、由于源代码不可用、因此我们无法自行应用它。

我们想问一下是否可以像其他文件（如 Nwk_globals.c）那样访问 assoc_list.c 和 addr_mgr.c 的源文件或者、使用-DLARGE_DEVICE_TABLE 编译的库变体可以解决该问题。我们还想标记此标记、以便在未来的 SDK 版本中进行更正。

如果需要、我们可以提供更多详细信息、但以上信息足以重现和验证您的问题、并确定修复路径。

assoclist_bug_demo.c

RE: [参考译文] CC2652P7：Z-Stack：ZigBee 协调器限制为 255 个关联器件、而不管 NWK_MAX_DEVICE_LIST 如何

admin — Mon, 23 Mar 2026 18:26:54 GMT

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

感谢您提供更多信息。我必须向管理层提出此请求、请允许我有时间在内部进一步讨论并与您联系。

此致、
Ryan

[参考译文] CC2652P7：如何提高 CC2652P7 的传输速度？

admin — Fri, 20 Mar 2026 03:37:14 GMT

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1628234/cc2652p7-how-to-increase-transmission-speed-of-cc2652p7

器件型号： CC2652P7

尊敬的先生：

目前、我们正在使用 CC2652P7‘s Zigbee 传输一个 32K 字节的数据。我们发现传输时间过长。每个数据包的容量只能为 128 字节、每秒传输大约 6 个数据包。我们如何提高数据包容量并加快传输频率？

谢谢

乍得

RE: [参考译文] CC2652P7：如何提高 CC2652P7 的传输速度？

admin — Mon, 23 Mar 2026 14:04:10 GMT

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

尊敬的 Chad：

没有任何示例可以绕过预构建的 Zigbee 库中定义的 ZStack 最大数据包大小（或者至少我相信，只是从 nwk.h 增加 MAX_DATA_PACKET_LEN 是无效的）。 OTA 示例展示了一些高吞吐量、但包含更多的开销和应用程序、而这可能不是您的需求所必需的。我认为最好的方法是 Zstackapi_Af 使用 zstackmsg_Cmdids_af_incoming_MSG_IND 处理最后一条消息的结果后、使用 DataReq 并开始下一条消息。 Zigbee 基础项目开发 SLA 对此进行了演示、并可进行扩展以提高数据包频率。

此致、
Ryan

RE: [参考译文] CC2652P7：如何提高 CC2652P7 的传输速度？

admin — Mon, 23 Mar 2026 06:48:16 GMT

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

您好、Ryan、

感谢您的答复。

我们也认为它是这样的。我认为监听器日志不是很有用。您是否有任何可以提高此数据包容量的示例？或者、我们如何通过直接调用 ZStack 的底层协议接口来避免这种限制？

谢谢

乍得

RE: [参考译文] CC2652P7：Z-Stack：ZigBee 协调器限制为 255 个关联器件、而不管 NWK_MAX_DEVICE_LIST 如何

admin — Fri, 20 Mar 2026 20:56:51 GMT

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

您好、Ryan、

感谢您的澄清。我们确实在使用带路由器的网状网络、我们知道 ZDSECMGR_TC_DEVICE_MAX 控制网络上的设备总数、而关联表是每个节点的。我们已经调整了 ZDSECMGR_TC_DEVICE_MAX 和所有相关的 NV 大小参数以适应更大的网络、但我们仍然不能超过 256 个器件。

我想澄清一下、将大量器件与单个节点关联在本例中尤为重要。这是一个专有的应用程序、其中设备的通信频率非常低、因此有关带宽和网格分配的典型问题并非以同样的方式适用、我们了解这种情况的所有含义。但我们并不在寻找通用的解决方案；使用单个协调器或路由器可靠地处理超过 255 个直接关联的设备对我们来说非常有价值。

我们已经拥有拥有数千台设备的生产网络、但目前、我们通过部署额外的协调器来克服这一限制。其中一些设备无论如何都是必要的、但在某些情况下、能够在每个节点关联更多设备可能会减少所需的总体协调器数量。

堆栈似乎已经在定义了 LARGE_DEVICE_TABLE 且已有类型切换机制的情况下支持它、并且修复程序似乎与使用正确标志重新编译库一样简单、因此我们认为这是一个值得实现的改进、这也是我们提请您注意的原因。

此致、

RE: [参考译文] CC2674R10：我是否可以将‑LAUNCHXL‑CC26X2R1 的 2.4GHz 天线和匹配网络重复用于 CC26X4 设计？

admin — Fri, 20 Mar 2026 20:38:34 GMT

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

您好、Stefan：

中讨论的一些项目 第 2 款 一半 SWRA814 （SimpleLink CC131x 和 CC135x 系列硬件迁移指南） https://www.ti.com/lit/swra814 也适用于此处、在这种情况下、器件封装尺寸的影响。

您使用的是 RGZ 或 RSK 器件？如果是 RGZ 器件、您可以使用用于 CC26x2 器件的相同+5dBm 匹配网络；射频前端是相同的、因此、CC13x2/4 和 CC26x2/4 RGZ 器件的网络（对于+5dBm、2.4GHz 射频路径）是相同的；您可以从以下 RGZ 设计中的相关射频部分看到这一点：

LP-CC1352P7-4 (SWRC373)： https://www.ti.com/lit/zip/swrc373
LP-CC2652R7 (SWRC370)： https://www.ti.com/lit/zip/SWRC370 — 如果使用 RGZ 器件、请直接使用它

对于 RSK 器件、请使用中的+5dBm 路径 LP-EM-CC1354P10-1 (SPRR484)： https://www.ti.com/tool/download/SPRR484 — 这用于数据表中的表征数据。

此致、

Zack

[参考译文] CC2674R10：我是否可以将‑LAUNCHXL‑CC26X2R1 的 2.4GHz 天线和匹配网络重复用于 CC26X4 设计？

admin — Fri, 20 Mar 2026 20:21:55 GMT

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1628528/cc2674r10-can-i-reuse-the-2-4-ghz-antenna-and-matching-network-from-launchxl-cc26x2r1-for-a-cc26x4-design

器件型号： CC2674R10
主题中讨论的其他器件： LP-CC2652R7

大家好：

我目前正在开发基于的新设计 CC26X4 器件 （仅限 2.4GHz、无 Sub-1GHz‑1GHz）  。由于 CC26x4 系列还没有可用的公共 LaunchPad 或参考设计、因此我想阐明以下内容：

是否可以将 LAUNCHXL‑CC26X2R1 的 2.4GHz‑GHz 天线布局和匹配网络重复用于基于 CC26X4‑的设计？

我的理由：

两个器件都使用 2.4‑GHz 射频路径
CC26x4 架构与具有扩展存储器的 CC26x2 密切相关
我是有意为之不会我想基于 CC1354 参考设计进行设计、因为我只需要 2.4GHz  并避免额外的低于‑ 1GHz 匹配网络
目标是采用紧凑型 2.4GHz‑设计、适用于 Thread/Matter 应用

我的问题：

是 射频引脚、阻抗特性和匹配拓扑 CC26x2 与 CC26x4 兼容？
有任何问题吗 内部指导或早期文档 CC26x4 射频布局建议？
‑它们不直接兼容、我应该考虑射频前端的主要差异是什么？

提前感谢、

Stefan

RE: [参考译文] CC2652P7：Z-Stack：ZigBee 协调器限制为 255 个关联器件、而不管 NWK_MAX_DEVICE_LIST 如何

admin — Fri, 20 Mar 2026 14:10:03 GMT

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

尊敬的 Tiago：

感谢您对您的情况进行简要而全面的描述。与网状网络相比、您是否计划实施星形网络？ Zigbee 协议旨在让路由器和终端设备与附近的其他路由器关联、而不是直接与协调器关联。协调器不应该或不支持直接与 255 多个器件关联。 Zigbee 网络应在整个路由网络中均匀地分配设备、以支持网状拓扑。 ZDSECCMGR_TC_DEVICE_MAX 决定了协调器上存储的唯一 TCLK 的数量、并且是一个 16 位值。与协调器关联的设备数量不等于 Zigbee 网络上允许的设备总数、因为终端设备和路由器可以与其他路由器关联。请允许我有时间在内部与 TI 利益相关者同步您的情况。

此致、
Ryan

RE: [参考译文] CC2340R5：ZB_NLME_STATUS_INDITION 的原因是什么？

admin — Fri, 20 Mar 2026 13:44:51 GMT

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

请参阅 Zigbee 基础项目开发 SLA 、其中涉及 SEND_APS_PAYLOAD_CB。此函数将返回应用程序有效载荷的状态、然后释放缓冲区。间接事务到期可能是由于 ZED 在到期时间之前没有向其父级发送数据请求（请参阅编译时配置参数）。如果您认为 ZBOSS 栈中存在错误、请发送详细说明、说明如何使用 F3 SDK 中的 Zigbee 示例进行复制。

此致、
Ryan

RE: [参考译文] CC2652P7：如何提高 CC2652P7 的传输速度？

admin — Fri, 20 Mar 2026 13:30:55 GMT

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

尊敬的 Chad：

根据您的说明、您似乎遇到了 Zigbee 协议的限制。 PHY 设置为 250kbps、数据包容量由 IEEE-Zigbee 规范定义。如果您只部署始终开启的 ZC/ZR 设备并限制使用 APS ACK 或目标响应、则您可能能够每秒传输更多数据包。您是否有当前传输的监听器日志？

此致、
Ryan

RE: [参考译文] CC2340R5：ZB_NLME_STATUS_INDITION 的原因是什么？

admin — Fri, 20 Mar 2026 01:26:41 GMT

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

该应用程序缓冲区是否可以清除？我使用协调器来连接 6 终端器件。 6 个终端设备中的每一个都每 10 秒发送 48 个字节的数据。运行 1 小时后、再次重新连接时、会出现“ZB_Nwk_command_status_indirectact_expired"错误“错误。我应该如何操作以防止每次重新连接时出现此状态？

[09:15:02.179]收←◆a55a30026916952501000000691695270100000069169529010000006916952b010000006916952d0100000000f40d0a 0f:48:3f:2f:00:4b:12:00

[09:15:02.815]收←◆a55a300269169525090d000069169527090d000069169529090b00006916952b090b00006916952d090b000000f70d0a 05:48:3f:2f:00:4b:12:00

[09:15:02.866]收←◆a55a30026916952501000000691695270100000069169529010000006916952b010000006916952d0100000000f40d0a 72:47:3f:2f:00:4b:12:00
a55a30026916952501000000691695270100000069169529010000006916952b010000006916952d0100000000f40d0a 58:45:3f:2f:00:4b:12:00

[09:15:02.941]收←◆a55a30026916952501000000691695270100000069169529010000006916952b010000006916952d0100000000f40d0a 5a:45:3f:2f:00:4b:12:00

[09:15:03.106]收←◆a55a30026916952501000000691695270100000069169529010000006916952b010000006916952d0100000001f50d0a 59:45:3f:2f:00:4b:12:00

[09:15:18.327]收←◆leave device short addr = 0xe009

[09:15:18.571]收←◆leave device short addr = 0xaa9b

[09:15:18.644]收←◆leave device short addr = 0xb57f

[09:15:18.941]收←◆leave device short addr = 0xb023

[09:15:19.052]收←◆leave device short addr = 0x9e1b

[09:15:19.279]收←◆leave device short addr = 0x80b0

[09:16:30.021]收←◆long_addr : 58:45:3f:2f:00:4b:12:00

[09:16:35.914]收←◆long_addr : 72:47:3f:2f:00:4b:12:00

[09:16:37.737]收←◆long_addr : 0f:48:3f:2f:00:4b:12:00

[09:16:55.260]收←◆long_addr : 05:48:3f:2f:00:4b:12:00

[09:18:22.152]收←◆long_addr : 59:45:3f:2f:00:4b:12:00
leave device short addr = 0x0c7c

[09:18:32.591]收←◆Network operation 00,nwk_addr = c7c

[09:19:00.042]收←◆Network operation 00,nwk_addr = c7c

[09:19:15.424]收←◆Network operation 00,nwk_addr = c7c

[09:19:19.339]收←◆unavailable_short_addr = 0x0c7c

[09:19:25.865]收←◆long_addr : 59:45:3f:2f:00:4b:12:00

[09:19:25.942]收←◆leave device short addr = 0x0c7c

[09:19:33.790]收←◆Network operation 06,nwk_addr = c7c
Network operation 06,nwk_addr = c7c

[09:19:44.513]收←◆Network operation 00,nwk_addr = c7c

[09:19:58.960]收←◆Network operation 00,nwk_addr = c7c

[09:20:13.194]收←◆Network operation 00,nwk_addr = c7c

RE: [参考译文] CC2340R5：ZB_NLME_STATUS_INDITION 的原因是什么？

admin — Thu, 19 Mar 2026 13:01:44 GMT

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

这些是 ZBOSS 的预期响应（如果应用程序正在尝试向已离开网络且不可用的设备发送消息）。

此致、
Ryan

RE: [参考译文] CC2340R5：ZB_NLME_STATUS_INDITION 的原因是什么？

admin — Thu, 19 Mar 2026 02:24:31 GMT

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

协调器仅连接到一个器件。设备离开网络后、仍会显示 ZB_Nwk_command_status_indirectal_transaction_expires 和 ZB_Nwk_command_status_no_route_available。为什么会这样？

[10:21:48.527]收←◆long_addr : 05:48:3f:2f:00:4b:12:00

[10:21:48.759]收←◆leave device short addr = 0x1fbb

[10:21:56.429]收←◆Network operation 06,nwk_addr = 1fbb
Network operation 06,nwk_addr = 1fbb

[10:22:07.137]收←◆Network operation 00,nwk_addr = 1fbb

[10:22:18.285]收←◆Network operation 00,nwk_addr = 1fbb

[10:22:33.478]收←◆Network operation 00,nwk_addr = 1fbb

RE: [参考译文] CC2652RSIP：CC2652r1f 片外 OAD 在定制电路板上失败–OTA 中止 (0xC1) 和 BI 引导问题

admin — Tue, 17 Mar 2026 12:17:09 GMT

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

你好、Sushmitha、

下面是 Z-Stack 用户指南和 Zigbee OTA 升级 SLA 、供您参考。您需要创建 Zigbee 出厂映像或使用现有的 BLE 出厂映像。只要存在出厂映像、片外 BIM 和 Zigbee OTA 应用就不会考虑使用哪种栈。

ZR_SW_OTA_CLIENT_offchip 示例假设使用了 MX25R8035F 外部闪存（请参阅 SYSCONFIG -> NVS -> CONFIG_NVSXTERNAL）。您将需要确保区域基址、区域大小、区域大小等与您的 W25Q80DV 外部闪存对齐。这同样适用于 BIM Application/ext_flash_layout.h 和 ExternalFlash/ext_flash.c 文件、因为您应该检查以确保它们考虑到您的外部闪存。

此致、
Ryan

[参考译文] CC2652RSIP：CC2652r1f 片外 OAD 在定制电路板上失败–OTA 中止 (0xC1) 和 BI 引导问题

admin — Tue, 17 Mar 2026 03:43:45 GMT

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1626861/cc2652rsip-cc2652r1f-off-chip-oad-fails-on-custom-board-ota-abort-0xc1-and-boot-issue-with-bi

器件型号： CC2652RSIP
Thread 中讨论的其他器件： CC2652RB、 SysConfig

我正在使用处理 Zigbee OTA ZR_SW_OTA_CLIENT_offchip 基于的定制板上的示例 CC2652RIF 具有外部 SPI 闪存的器件 ( W25Q80DV 、1MB)。

同一 OTA 示例可在上正常工作 CC2652RB LaunchPad 、但在我的自定义硬件上、我遇到了以下问题：

问题 1：OTA 故障

OTA 过程成功启动。
启动后不久、它就会失败、原因是：
- “下载文件失败“
- “ZOTA 中止“
在 OTA 服务器工具中、该器件会显示：
- 软件失败（状态代码= 0xC1）

问题 2：BIM 启动失败

我刷新了：
- bim_offchip.hex
- zr_sw_ota_client_offchip_oad.bin
复位后、器件不会引导（无 UART 日志，无应用程序活动）。

不过：

如果我刷写正常应用程序（无 OAD）.bin、则应用程序会正确运行。
使用 NVS 示例验证外部闪存通信（读取/写入/擦除工作正常）。

硬件详细信息：

MCU：CC2652R1F
外部闪存：W25Q80DV (Winbond、1MB)
使用 NVS 驱动程序验证 SPI 通信
扇区大小：4KB (0x1000)

软件详细信息：

SDK 版本：SimpleLink CC13xx/CC26xx SDK 8.32.0.07
使用的示例： zr_sw_ota_client_offchip
测试的 SPI 比特率：2MHz 和 4MHz

调试观察结果：

从闪存读取的 JEDEC ID 正确
外部闪存擦除/写入操作成功
OTA 在下载阶段失败
当外部闪存为空时、BIM 不会引导应用程序

到目前为止的理解：

在调试过程中、显示为：

OTA 失败、因为外部闪存中不存在有效的出厂映像
BIM 需要在外部闪存中提供有效的映像、不会回退到内部闪存

问题：

在定制电路板上使用有效出厂映像初始化外部闪存的建议方法是什么？
是否使用了otaClient_saveFactoryImage()正确的生产方法？
是否有官方方法来在不使用 BLE Project Zero 的情况下生成出厂映像并对其进行编程？
1MB 外部闪存的链接器文件或 OAD 存储中是否需要任何其他配置？
如果外部闪存为空、BIM 是否有回退机制？

其他信息：

我已尝试完全擦除外部闪存。
我计划使用应用程序本身生成出厂映像。

请求：

请就以下方面提供指导：

定制硬件的正确出厂映像初始化流程
针对 BIM +应用+外部闪存的正确刷写序列
W25Q80DV 闪存需要进行的任何配置更改
如果需要进行任何其他配置或任何操作、请指导我

此致、
Sushmitha.

RE: [参考译文] CC2340R5：ZB_NLME_STATUS_INDITION 的原因是什么？

admin — Tue, 17 Mar 2026 11:35:50 GMT

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

我相信您的大多数问题都可以通过 ZBOSS 用户指南的 Zigbee 栈 RAM 使用配置部分得到解决。您可以使用包含更大 RAM 的 CC27XX 器件来支持更大的缓冲器大小和更多的加入器件。

此致、
Ryan

RE: [参考译文] CC2340R5：ZB_NLME_STATUS_INDITION 的原因是什么？

admin — Tue, 17 Mar 2026 00:59:30 GMT

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

如何检查应用缓冲区的大小和相关设置、并确定协调器可以接收多少个终端、以及终端发送的数据包可以同时接收多大。

RE: [参考译文] CC2340R5：ZB_NLME_STATUS_INDITION 的原因是什么？

admin — Mon, 16 Mar 2026 17:02:31 GMT

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

对于 MAC_TRANSACTION_OVERFLOW 或 MAC_TRANSACTION_EXPIREED、将返回 ZB_NWK_COMMAND_STATUS_INDIREATION_TRANSACTION_EXPIRED。这意味着在本地父设备上超时之前、传输缓冲区或休眠终端节点未及时报告接收消息的问题。无论在哪种情况下、充分管理应用程序缓冲区都至关重要、因为如果不这样做、可能会合理地导致器件软件复位。

此致、
Ryan