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

[参考译文] CC2652R：ZigBee 范围问题

admin — Wed, 20 May 2026 05:25:25 GMT

Other Parts Discussed in Thread: CC2592

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1647540/cc2652r-zigbee-range-issue

器件型号： CC2652R
主题： CC2592 中讨论的其他器件

尊敬的团队：

继续讨论、根据建议、我们已经测试了结果。 KINLDY 在文档中找到所附的测试结果

Home_automation_Range_test_report.pdf

Kinldy 查看并分享您的反馈意见、以解决这些问题

此致
Srinivas

[参考译文] CC2538-CC2592EMK：电子门锁 — ZigBee 开发项目

admin — Tue, 19 May 2026 09:53:50 GMT

Other Parts Discussed in Thread: CC2340R5

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1647247/cc2538-cc2592emk-electronic-door-lock---zigbee-development-project

器件型号： CC2538-CC2592EMK
主题中讨论的其他器件： CC2340R5

尊敬的 TI 团队：

我代表我们的工程团队发送此邮件、因为我们目前正在将 Zigbee 天线/模块集成到我们的门禁控制门锁系统中。我们正在探索合适的 Zigbee 芯片或模块解决方案、希望获得您的支持和建议。

以下是我们的初始要求：

与集成到电子门锁系统兼容的 Zigbee 芯片或模块

最新可用的 Zigbee 版本和支持的协议
电气和机械规格、包括接口、引脚排列、功耗和天线选项
安全特性、OTA 功能以及认证合规性
推荐的开发工具、SDK 和文档
样片和批量订单的预估价格
样片和大规模生产的交货周期
在开发过程中提供技术支持、并与我们的工厂工程团队协调

如果您能提供推荐的解决方案以及完整的技术规格、数据表和商业详细信息、我们将不胜感激。我们的团队随时准备进一步协调、以确保与我们现有的锁紧硬件兼容。

提前感谢您的帮助。我们期待着你的提议和合作的可能性。

[参考译文] CC2755R10：射频计划

admin — Wed, 29 Apr 2026 08:56:05 GMT

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1641416/cc2755r10-radio-frequency-plan

器件型号： CC2755R10

你（们）好

当前正在运行 FCC 批准、遇到有关射频计划 LO osc (IF freq) 的问题。我想频率与“如何认证您的蓝牙产品“中的规定大致相同。请详细说明这一点。

B.R.

Fleming Larsen

[参考译文] CC2755R10：带有 ALIRO 标准的软件包

admin — Tue, 28 Apr 2026 04:28:49 GMT

Other Parts Discussed in Thread: CC2340R5

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1640899/cc2755r10-sw-package-with-aliro-standards

器件型号： CC2755R10
主题中讨论的其他器件： CC2340R5

尊敬的专家：

我的客户正在寻找符合 Aliro（CSA 标准）标准的器件。

https://csa-iot.org/all-solutions/aliro/

您是否有计划在 cc2755 或 cc2340R5 中提供 aliro 标准库？

谢谢

[参考译文] CC2652PSIP：ATEX 认证的最大总内部电容

admin — Wed, 22 Apr 2026 04:16:39 GMT

Other Parts Discussed in Thread: CC2652PSIP

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1639071/cc2652psip-maximum-total-internal-capacitance-for-atex-certification

器件型号： CC2652PSIP

尊敬的专家：

我的客户申请了用于 ATEX 认证的 CC2652PSIP 的最大总内部电容。

此外、您能为我们提供 ATEX 认证指南文档吗？

谢谢

[参考译文] CC2530：在 CC2530 P0_R2/P1_0 引脚受到干扰后、功耗变得非常高。

admin — Wed, 22 Apr 2026 03:38:54 GMT

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1639057/cc2530-after-interference-on-the-cc2530-p0_2-p1_0-pins-the-power-consumption-becomes-extremely-high

器件型号： CC2530

您好！

我们在工程中遇到相同的配置、其中 P0_R2 和 P0_R3 都配置为输出低电平。这些 IO 均未连接到任何外部器件。用镊子触摸 P0_R2 时、功耗会显著增加。此时、该引脚上测得的电压约为 0.63V。以相同的方式触摸 P0_R3 不会导致该问题。出现此问题时、只能通过下电上电恢复正常。您能否帮助分析导致这种情况的原因以及如何解决？我们期待着你的答复。

谢谢！

[参考译文] CC2652R7：Zed Unexpected Network Leave + NLME_RestoreFromNV() 返回 False

admin — Tue, 14 Apr 2026 16:35:03 GMT

Other Parts Discussed in Thread: CC2652R7, Z-STACK, SYSCONFIG

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1636508/cc2652r7-zed-unexpected-network-leave-nlme_restorefromnv-returns-false

器件型号： CC2652R7
主题中讨论的其他器件： Z-STACK、 SYSCONFIG

您好：

我正在处理一个电池供电的 Zigbee 终端设备 (ZED) 项目、需要帮助解决两个相关问题：

硬件/软件环境：
-设备: CC2652R7（定制板）
- Z-Stack 版本: 3.x (SDK 8.30)
-配置: ZigBee 终端设备（休眠终端设备）

——
问题 1：未解释的网络休假事件

我们的电池供电终端设备偶尔会意外离开 Zigbee 网络（极少数情况下，现场设备中有~0.1%）。由于这是间歇性的、很难在我们的实验室中重现问题、因此我还没有监听器日志或器件跟踪。我确实有信息表明、旧版本的 SDK (6.20) 上也出现了此问题。

问题：
-什么是已知的机制,可以导致 ZED 离开网络而无需明确的应用程序请求?
-我应该看看:父母丢失超时,轮询率问题,安全故障,低电池行为,或其他什么?
-我是否应该监控特定的 NV 项目或运行时标志,以检测为什么发生休假?

——
问题 2：NLME_RestoreFromNV() 返回 False

为了解决问题 1、我正在实施网络备份/恢复机制、将网络参数保存到单独的自定义 NVS 区域。设备离开网络后、我要恢复参数并重新加入封闭网络（禁用允许加入）。

当前实施的方案：
1.成功加入后:
  -将 NIB 数据保存到自定义 NVS 区域
  -保存安全密钥
2.尝试引导/重新连接时：
  -从自定义 NVS 恢复 NIB 数据
  -从自定义 NVS 恢复安全密钥
  -调用 bdb_setNodeIsOnANetwork()-告诉 BDB 设备有网络参数、以便它可以尝试安全重新连接
  -清除启动选项以允许在下次启动时恢复网络状态
  -通过 osal_nv_write 写入 NIb
  -重新启动设备

问题：
NLME_RestoreFromNV() 始终返回 false。由于这是一个预编译的库函数、因此无法调试其失败的原因。

问题：
-什么情况会导致 NLME_RestoreFromNV () 返回 false ?
-在调用此函数之前,是否必须设置特定的初始化序列或 NV 项?
-我是否应该在休假事件后使用不同的 API 来恢复网络状态?
-网络密钥是否需要与 NIB 结构分开处理?

我尝试过的方法：
-已验证的 NV 写入操作成功
-已验证的 NIB 数据完整性,并在恢复前进行 CRC 检查
-在初始化序列中的不同点调用恢复

希望就这两个问题提供任何指导。对于问题 1、即使是一般的调试策略也会有所帮助。对于问题 2、了解恢复 API 要求将取消阻止我的原型。

谢谢！

[参考译文] CC2652P：哪个文件可以更改 TX_POWER、引导加载程序后门 DIO 和 LF 时钟源

admin — Fri, 10 Apr 2026 10:18:15 GMT

Other Parts Discussed in Thread: SYSCONFIG

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1635277/cc2652p-which-file-can-change-tx_power-bootloader-backdoor-dio-and-lf-clock-source

器件型号： CC2652P
主题： SysConfig 中讨论的其他器件

您好、

我从 GitHub 存储库 (https://github.com/TexasInstruments/ot-ti) 下载了 OpenThread。我需要更改一些参数。您能告诉我应该修改哪些文件吗？

TX_POWER
引导加载程序后门 DIO 和引导加载程序后门的触发电平
LF 时钟源

[参考译文] CC2755P10：CC2755 — 需要获得电源轨帮助。

admin — Wed, 08 Apr 2026 03:24:54 GMT

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1634153/cc2755p10-cc2755---need-help-with-power-rails

器件型号： CC2755P10

您好、

我尝试使用 CC2755 构建物联网器件。 IC 是否可以在 1.8V 下工作。我认为、如果<2.2V、就会有轻微的窒息。如果我错了、请纠正我。此外,在这种情况下,我们可以使 GPIO 引脚在 1.8V 而不是 3.0 或 3.3V 下工作。

[参考译文] CC2652P：CC2652P (Sonoff Zigbee 3.0 Dongle Plus) 发送 NWK 密钥、但忽略 APS 请求密钥 (TCLK) 和安全重新加入请求

admin — Tue, 07 Apr 2026 17:55:49 GMT

Other Parts Discussed in Thread: CC2652P, Z-STACK

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1634057/cc2652p-cc2652p-sonoff-zigbee-3-0-dongle-plus-sends-nwk-key-but-ignores-aps-request-key-tclk-and-secure-rejoin-request

器件型号： CC2652P
主题中讨论的其他器件： Z-stack

您好：

我正在使用 Sonoff Zigbee 3.0 USB Dongle Plus (CC2652P 协调器、通过 ZNP 运行 Z-Stack 3.x)。我正在开发自定义 Zigbee 节点实现（并非基于 TI Z-Stack）、并研究了信任中心的接纳行为。

我的器件成功执行以下序列：

MAC 关联请求→已收到关联响应
从协调器收到的 AP 传输密钥（网络密钥）
ZDO 设备通知由协调器广播

因此、设备在 NWK 级别明确加入网络、并成功接收网络密钥。

不过：

APS 请求密钥（密钥类型= 0x04，信任中心链路密钥）仅通过 MAC 确认、从不应答
安全 NWK 重新加入请求仅得到 MAC 确认、从未应答
未观察到 APS_UPDATE_DEVICE 命令
加入设备不会显示在协调器端的键表中

协调器安全配置（来自 ZNP/zigpy 网络信息）：

AP_USE_INSECURE_JOIN = 1
USE_DEFAULT_TCLK = 1
SECURE_LIQUE_JOIN = 1
APS_LINK_KEY_TABLE 为空
TCLK_table 为空

关联期间的器件功能标志：

ALTERNATE_PAN_COMPAN协调器= 0
DEVICE_TYPE = 0（终端器件）
Receiver_on_when_idle = 1
SECURITY_CAPABILITY = 1
ALLOCAT_ADDRESS = 1

ZigBee 修订版= 22

观察到的行为总结：

已成功传送 NWK 传输密钥
器件通知由协调器重新广播
APS 请求密钥 (0x04) 已忽略
已忽略安全重新加入请求
仅收到 MAC ACK 响应
在任何阶段都未观察到 APS_UPDATE_DEVICE

问题：

在 NWK 传输密钥交付和器件通知后、Z-Stack 3.x（CC2652P 协调器）在什么条件下将器件插入 ADDRMGR/安全表？
在接受 APS 请求密钥 (0x04) 之前是否需要 APS_UPDATE_DEVICE？
USE_DEFAULT_TCLK = 1 是否完全抑制 Zigbee 3.0 模式下的信任中心链接密钥传输？
成功接收 NWK 密钥的设备是否仍可被视为在 APS 级别未经身份验证？
在回答安全 NWK 重新加入请求之前是否需要其他条件？

在此方案中、任何关于信任中心准入政策的说明都将受到极大的欢迎。

[参考译文] CC2674P10：在 CC2674P10 RGZ 上为 ZNP 启用 20dBm

admin — Thu, 02 Apr 2026 07:21:57 GMT

Other Parts Discussed in Thread: CC2674P10, SYSCONFIG

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1632762/cc2674p10-enabling-20dbm-for-znp-on-cc2674p10-rgz

器件型号： CC2674P10
主题： SysConfig 中讨论的其他器件

我的客户使用的是 CC2674P10 RGZ 的定制板、他们希望在 ZNP 工程上启用 20dBm Tx 功率、但无法找到如何实现。

ZNP_LP_EM_CC2674P10_tirtos7_ticlang 仅支持最大 5dBm：

LP_EM_CC2674P10 工程中不支持开关器件。

我还尝试从 LP-EM-CC1354P10-6 工程开始、但在器件切换窗口中无法选择 CC2674P10 RGZ：

请提供为 ZNP 工程启用 20dBm Tx 功率的指南、目标器件是 CC2674P10 RGZ。谢谢。

此致、

Shuyang

[参考译文] CC2755P10：CC2755P10 / CC2745R10 — 输出功率下降和谐波增加至高于特定功率阈值

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

Other Parts Discussed in Thread: CC2755P10, LP-EM-CC2755P10, LP-EM-CC2745R10-Q1, SYSCONFIG, CC2745R10-Q1

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1630989/cc2755p10-cc2755p10-cc2745r10-output-power-drops-and-harmonics-increase-above-a-certain-power-threshold

器件型号： CC2755P10
Thread 中讨论的其他器件： LP-EM-CC2745R10-Q1、 SysConfig、 CC2745R10-Q1

我们正在使用 CC2755P10 和 CC2745R10 为 2.4GHz IEEE 802.15.4/Zigbee 开发定制电路板。当射频输出功率配置为高于特定阈值时、我们观察到异常行为。此问题可直接使用 SmartRF Studio 8 重现、不依赖于应用程序固件。

观察到的行为：

LP-EM-CC2755P10 配置文件、SmartRF Studio 8：

-+4dBm：测得=+2dBm、二次谐波=−50dBc
｛.ibBoost = 0、.IB=33、.Gain = 6、.mode = 1、.rtsmTxCompCtl=0 .pa20dBmEsdCtl=0、.noIfampRfLdoBypass=0 }
-+5 dBm:测量值= 0 dBm,二次谐波~+16 dBm,比上一步高
｛.ibBoost = 0、.IB=54、.Gain = 3、.mode = 2、.rtmmTxCompCtl=0 .pa20dBmEsdCtl=0、.noIfampRfLdoBypass=0 }

LP-EM-CC2745R10-Q1 配置文件、SmartRF Studio 8：

-+5 dBm：测量值=+5 dBm
-+6dBm:测量值= 0 dBm,二次谐波显著增加
-+10 dBm:测量值=+4.5 dBm,二次谐波显著增加

摘要：

低于特定功率级别时、两个器件都会按预期运行。高于该阈值时、输出显著下降、二次谐波增加+16dBm 或更高、该行为也不会在更高的配置值下恢复。该异常情况在 CC2755P10 和 CC2745R10 中是一致的。

通过查看功率表、我们注意到该阈值与 MODE 字段从 1 转换为 2 的点重合。模式=2 和模式=3 的条目均显示相同的异常行为、而模式=1 的条目按预期工作。我们无法确认模式是实际原因还是仅是相关性、我们将其作为一种观察。

我们已考虑的事项：

功率表精度：我们考虑了 SysConfig 或 SmartRF Studio 生成的默认功率表可能会针对较高功率条目包含不正确的值。但是、由于这两种工具都会自动生成该表、因此直接评估或校正此表的能力有限。我们唯一能够独立研究的参数是 pa20dBmEsdCtl：我们在工程上禁用了 SysConfig 生成功能并手动编辑了功率表、对于所有 mode=2 和 mode=3 条目、将该字段设置为 1。我们观察到略有改善（较高功率等级下为~2dBm）、但基本异常仍然存在。这表明该表可能有一些不准确之处、但仅更正 pa20dBmEsdCtl 是不够的。
电源电压 (VDDS)：我们考虑了电源电流不足是否可以解释该行为。但是、工程分析和点测量并不表明存在供应问题、即使在低模式=2 电平 (5–6 dBm) 下也会出现电压下降、在这种情况下、电流消耗应接近或仅略高于最后一个工作模式=1 条目。电源限制不容易解释突然的输出下降以及如此大的谐波增加。我们提到它是为了完整,但认为它不大可能。
阻抗匹配：我们还考虑了射频匹配问题。但是、CC2755P10 和 CC2745R10 在内部集成了平衡 — 非平衡变压器，我们的电路板遵循与 LP-EM-CC2745R10-Q1 LaunchPad 相同的射频布局原则。我们在 TI CC 系列射频工程和适当的射频测试设备方面拥有丰富的经验、可让我们放心地进行测量和布局分析。我们还注意、LP-EM-CC2755P10 文档显示在 Resource Explorer 中、但链接会重定向到 CC2745R10-Q1 文档、因此我们无法确认 P10 型号是否存在相关的原理图或布局差异。也就是说、通过 CC2745R10 也可以观察到相同的异常行为、我们可以访问正确的 LaunchPad 参考。遵循该参考设计、我们预计 CC2745R10 将在其整个额定功率范围内正常工作、但异常情况在该范围内似乎很明显。该电路在这两个器件上均可在阈值 (~4–5dBm) 下正常工作、这使得匹配问题不太可能解释高于该点时的行为突变。

另外、我们希望知道 LP-EM-CC2755P10 原理图与 LP-EM-CC2745R10-Q1 的相关方式是否不同、或者了解它们是否等效于射频用途、而不是作为主要问题、而是作为我们 P10 设计的有用背景。

我们对问题的分析非常透彻、我们可以从自己的角度来分析、而且已经没有任何想法了。有人以前见过这种行为吗？我们描述中的任何内容是否暗示了我们可能忽略的内容？我们是否应该研究任何其他参数、初始化步骤或硬件条件？

由于我们无法访问这些器件的 LaunchPad、因此我们也想知道是否可以使用默认 SDK 配置或 rfStudio 在一个平台上重现此行为。

作为参考、我们的大多数测试中使用的由 SysConfig 生成的以下文件。

TI_RADIO_CONFIG.c

此致

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

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

Other Parts Discussed in Thread: Z-STACK, LP-CC2652RSIP, SYSCONFIG

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

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 期间、是否预计应用程序循环会被阻止（无按钮响应）？

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

提前感谢！

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

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

Other Parts Discussed in Thread: LP-CC2652R7

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

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

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

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

Other Parts Discussed in Thread: CC2652P7

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

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 个数据包。我们如何提高数据包容量并加快传输频率？

谢谢

乍得

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

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

Other Parts Discussed in Thread: CC2652P7

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

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

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

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

Other Parts Discussed in Thread: CC2652RB, SYSCONFIG

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

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.

[参考译文] CC2755R10：SDK 工程设置 15.4 连接

admin — Thu, 12 Mar 2026 08:51:52 GMT

Other Parts Discussed in Thread: CC2755R10

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1625454/cc2755r10-sdk-project-setting-up-a-15-4-connection

器件型号： CC2755R10

是否有一个 SDK 工程可以提供以下任务？

“干扰保护测试条款“证明传输了唯一的地址。对于此测试、无线电设备应包含属于发送设备的唯一地址、该地址是每个发送的数据包的一部分。

它可以连接两个器件、其中一个器件连接到 PC、以显示来自另一个器件的重新加网地址。

此致

Fleming Larsen

[参考译文] CC2652RB：CAN'；t 通过 ZNP 获取绿色功率帧

admin — Tue, 10 Mar 2026 18:06:28 GMT

Other Parts Discussed in Thread: CC2530

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1624734/cc2652rb-can-t-get-green-power-frames-through-znp

器件型号： CC2652RB
主题： CC2530 中讨论的其他器件

您好：

这是本主题的后续:

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1572639/lp-cc2652rb-issues-with-migration-from-cc2530-znp-to-cc2652rb-znp

长话短说：我能够通过 CC2530 和 ZNP 接收绿色电源帧、现在我迁移到 CC652RB 和 ZNP、但通过此配置和等效的初始化序列、我没有收到任何...

@Ryan Brown、根据您的回答、我使用 z-tool 来对配置进行预原型设计。结果如下：

//----------------------------- Clear NVM at reset

<TX>05:56:45.83 COM7 SYS_OSAL_NV_WRITE (0x2109)
Id: 0x0003
Offset: 0x00
Len: 0x01
Value: . (0x03)

<RX>05:56:45.83 COM7 SYS_OSAL_NV_WRITE_SRSP (0x6109)
Status: SUCCESS (0x0)

//----------------------------- Reset

<TX>05:57:12.8 COM7 SYS_RESET (0x4100)
Type: 0x00 (HARD RESET) (0x0)

<RX>05:57:13.42 COM7 SYS_RESET_RESPONSE (0x4180)
Reason: 0x00
TransportRev: 0x02
Product: 0x00
MajorRel: 0x02
MinorRel: 0x07
HwRev: 0x01

//----------------------------- Set panId

<TX>05:59:36.77 COM7 SYS_OSAL_NV_WRITE (0x2109)
Id: 0x0083
Offset: 0x00
Len: 0x02
Value: .. (0x0B, 0x00)

<RX>05:59:36.78 COM7 SYS_OSAL_NV_WRITE_SRSP (0x6109)
Status: SUCCESS (0x0)

//----------------------------- Start application

<TX>05:59:57.83 COM7 ZDO_STARTUP_FROM_APP (0x2540)
StartDelay: 0x00

<RX>05:59:58.47 COM7 ZDO_STARTUP_FROM_APP_SRSP (0x6540)
Status: SUCCESS (0x0)

<RX>05:59:58.47 COM7 APP_CNF_BDB_COMMISSIONING_NOTIFICATION (0x4F80)
Status: 1 (0x1)
Commissioning Mode: 0x02 (Formation) (0x2)
Commissioning Mode: 0x04 (Network Formation) (0x4)

<RX>05:59:58.71 COM7 ZDO_STATE_CHANGE_IND (0x45C0)
State: 8 (0x8)

<RX>05:59:59.27 COM7 ZDO_STATE_CHANGE_IND (0x45C0)
State: 9 (0x9)

<RX>05:59:59.27 COM7 APP_CNF_BDB_COMMISSIONING_NOTIFICATION (0x4F80)
Status: 0x00 (Success) (0x0)
Commissioning Mode: 0x02 (Formation) (0x2)
Commissioning Mode: 0 (0x0)

从这一点来看、我希望接收 zgp 帧、但不会输出任何帧。

当我尝试了解发生了什么时、我通过发出以下命令来使用数据包监听器获取帧：

CMD_STOP、CMD_CFG_PHY、 CMD_CFG_FREQUENCY 和 CMD_START。

这使我断言、我与 CC2530 一起使用的前一版本 ZNP 可能正在侦听比今天更高的默认频率、并且我必须明确设置正确的侦听频率。我看到的与频率相关的唯一消息是 APP_CNFG_BDB_SET_CHANNEL 和 UTILS_SET_CHANNES。我尝试了几种组合、但仍然不成功。

任何关于如何解决此问题的想法都将受到高度赞赏。

谢谢

Julien

[参考译文] CC2340R5：使用 CC2340R53 作为协调器时遇到的一些问题

admin — Mon, 09 Mar 2026 08:21:28 GMT

Other Parts Discussed in Thread: SYSCONFIG, LP-EM-CC2340R5

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1623988/cc2340r5-some-problems-encountered-when-using-cc2340r53-as-the-coordinator

器件型号： CC2340R5
主题中讨论的其他器件： SysConfig、

大家好、在使用 CC2340R53 作为协调器的调试过程中、我遇到了一些问题。我使用的 SDK 是 8_40 版本：

1.要启动网络加入、请使用 zb_zdo_mgmt_permit_joining_req。从数据包捕获中可以看出、捕获的数据包中存在管理许可加入请求消息、但节点无法加入网络。我发现 Beacon 数据包中的关联许可为 0、即 0。
我将 bdb_start_top_level_commissioning (ZB_BDB_network_steering) 替换为这种模式、能够让节点加入网络、但时间固定在 180 秒。我想自己定义时间。

case ZB_BDB_SIGNAL_DEVICE_FIRST_START:
        LOG_COMMON_LN(LOG_DEBUG, "FIRST_START: start steering" );
        buf = zb_buf_get_out();
        if (!buf)
        {
          LOG_COMMON_LN(LOG_DEBUG, "no buffer available" );
          break;
        }

        req_param = ZB_BUF_GET_PARAM(buf, zb_zdo_mgmt_permit_joining_req_param_t);

        req_param->dest_addr = 0xfffc;
        req_param->permit_duration = 0;//0xff also gave it a try.
        req_param->tc_significance = 1;

        zb_zdo_mgmt_permit_joining_req(buf, permit_joining_cb);

        break;

2.我已将.sycfg 文件中的所有通道设置为启用。此外、我使用以下函数来配置通道。但是、在使用监听器捕获数据包时、我注意到协调器通道仍设置为通道 11。

  zb_set_network_coordinator_role(0x01000000);
  zb_set_bdb_primary_channel_set(0x01000000);
  zb_set_bdb_secondary_channel_set(0x01000000);

3.我用协调器调用 bdb_start_top_level_commissioning(ZB_BDB_network_steering );使一个节点能够加入我的协调器的网络（节点程序是另一个应用程序）。加入后、数据包捕获显示设备公告、但大约 20 秒后、数据包捕获显示协调器发送休假数据包、导致节点离开网络。
我注意到了 ZB_ZDO_SIGNAL_DEVICE_authorized 信号、类型和状态都为 1、即类型为 ZB_ZDO_authorization_type_R21_TCLK、状态为 ZB_ZDO_TCLK_authorization_timeout。休假是否是由身份验证失败引起的？有什么解决方案吗？

      case ZB_ZDO_SIGNAL_DEVICE_AUTHORIZED:
      {
        zb_ieee_addr_t ieee_addr;
        zb_zdo_signal_device_authorized_params_t *device_authorized_params = ZB_ZDO_SIGNAL_GET_PARAMS(sg_p, zb_zdo_signal_device_authorized_params_t);
        zb_uint16_t short_addr = device_authorized_params->short_addr;
        zb_ret_t ret = zb_address_ieee_by_short(short_addr, ieee_addr);
        zb_int8_t type = device_authorized_params->authorization_type;
        zb_int8_t status = device_authorized_params->authorization_status;
        atServer_printfln("short addr:%04X, ieee_addr:%02X%02X%02X%02X%02X%02X%02X%02X\r\n type: %d ,status:%d", \
            short_addr,  \
            ieee_addr[7], ieee_addr[6], ieee_addr[5], ieee_addr[4], ieee_addr[3], ieee_addr[2], ieee_addr[1], ieee_addr[0],type,status);

        LOG_COMMON_LN(LOG_DEBUG, "ZB_ZDO_SIGNAL_DEVICE_AUTHORIZED" );
        break;
      }

[参考译文] 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?表示的状态位的含义在什么情况下会出现此信号？为什么在多次生成此信号后、协调器会重新启动？

[参考译文] CC2340R5：当多个器件加入或离开网络时、协调器的短地址输出保持不变。

admin — Mon, 09 Mar 2026 01:21:46 GMT

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1623861/cc2340r5-the-short-address-output-by-the-coordinator-when-multiple-devices-join-or-leave-the-network-remains-unchanged

器件型号： CC2340R5

      case ZB_ZDO_SIGNAL_DEVICE_ANNCE:
      {
        zb_zdo_signal_device_annce_params_t *dev_annce_params = ZB_ZDO_SIGNAL_GET_PARAMS(sg_p, zb_zdo_signal_device_annce_params_t);
        short_addr = dev_annce_params->device_short_addr;
        // zb_ret_t ret = zb_address_ieee_by_short(short_addr, ieee_addr);
        printf("New device commissioned or rejoined short :0x%04hx\r\n",short_addr);
        // ZB_SCHEDULE_APP_ALARM(schedule_send_active_ep_req, 0, 1 * ZB_TIME_ONE_SECOND);
        break;
      }      
     case ZB_ZDO_SIGNAL_LEAVE_INDICATION:
      {
        zb_zdo_signal_leave_indication_params_t *leave_device_params = ZB_ZDO_SIGNAL_GET_PARAMS(sg_p, zb_zdo_signal_leave_indication_params_t);
        // delete_long_by_short(leave_device_params->short_addr);
        printf("leave device short addr = %d\r\n",leave_device_params->short_addr);
        bdb_start_top_level_commissioning(ZB_BDB_NETWORK_STEERING);
        break;
      }

有两种器件加入和离开协调器。输出短地址相同。为什么会这样？这种情况在以前的版本中没有发生。我当前使用的版本是 9.14.0.41。

[参考译文] CC2340R5：连接到 SmartRF Studio 8 时出现问题

admin — Fri, 06 Mar 2026 08:25:07 GMT

Other Parts Discussed in Thread: LP-XDS110, LP-EM-CC2340R5, UNIFLASH

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1623493/cc2340r5-have-problem-for-connecting-to-smartrf-studio-8

器件型号： CC2340R5
主题中讨论的其他部分： LP-XDS110、 UNIFLASH

你（们）好

我正在使用 LP-XDS110 和 LP-EM-CC2340R5。打开 SmartRF Studio 8 时、软件无法检测到器件。可能的原因是什么？

我的 LP-XDS110 和 LP-EM-CC2340R5 可用于通过 CCS 进行编程和调试、也可通过 UniFlash 进行编程。

最好的考虑。

宜化

[参考译文] CC2755R10：Matter over Thread

admin — Sun, 01 Mar 2026 12:47:29 GMT

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1621170/cc2755r10-matter-over-thread

器件型号： CC2755R10

您好、

我们已经开始使用 CC2340（电池供电的器件，通常是睡眠模式，在 RTC 或引脚 LPC 上唤醒、读取 ADC、通过 BLE/Thread 发送数据、支持 OTA）进行设计、但我们也希望包含 Matter over Thread 支持。

我认为我们需要更改为 CC2755、根据数据表、它可以支持 Matter、但我在 TI 的 Simplelink-Matter 库中找不到该器件。问题是：

CC2755 是否通过 Thread 支持 Matter？如果有、我们是否必须选择特定的 PN、或者所有变体都可以工作？应考虑任何已知的限制（对于 SED 器件）？

2.我们如何知道我们的软件将有多少资源可与 Thread over Matter 软件一起运行,包括 OTA 支持? 内部 162KRAM 足够了（根据我们所阅读的内容，它可能微不足道）？

3.我们的应用是 SED（休眠终端设备）-您认为最好考虑其他部件还是 2755 是一个合适的? 它对于大批量生产来说,价格非常重要。

谢谢、

TAL

[参考译文] CC2340R5：使用 NVS 写入数据后、无法在重新启动器件后读取数据。

admin — Thu, 26 Feb 2026 09:17:38 GMT

Other Parts Discussed in Thread: SYSCONFIG

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1620356/cc2340r5-after-writing-data-using-nvs-the-data-cannot-be-read-after-restarting-the-device

器件型号： CC2340R5
主题： SysConfig 中讨论的其他器件

我想利用 Zigbee 中的 NVS 函数。我尝试在示例“nvsinternal"中“中执行操作（代码如上所述）。我将使用以下代码：nvs_write (nvsHandle、0、(void *) 签名、sizeof (signature)、nvs_write_erase | nvs_write_post_verify)；执行此函数后、可以在存储器中看到数据。当我调用 NVS_write (nvsHandle、0、(void *) 签名、sizeof (signature)、NVS_write_erase | NVS_write_post_verify) 时；删除注释并将其重新写入存储器后、存储器中没有内容。为什么会这样？ NVS 不是断电非易失性器件吗？还是因为我在某处错过了某项操作而导致的？ 512KB 可编程闪存中也包含此地址。