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

[参考译文] CC2652P7：关键 Z-Stack 固件错误

admin — Fri, 26 Jun 2026 11:16:39 GMT

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1658992/cc2652p7-critical-z-stack-firmware-bug

Thread 中讨论的其他器件： CC2652P7、 Z-STACK、 CC2652R

关键 Z 堆栈固件错误：CC2652P7 SRSP AF 在大容量集群请求（例如 GenTime）期间的数据缓冲区溢出/锁定

我负责管理一项大规模部署、该部署控制着安全关键型基础设施、包括自动化商业闸门和交通信号灯系统。在高负载下、由于存在未处理的同步响应 (SRSP)/异步框架 (AF) 数据缓冲区溢出、CC2652P7 会定期完全锁定。

当终端设备向协调器发送特定群集请求（特别是 GenTime 查询 (Cluster 0x000A)) 时、就会触发此问题。 Z-Stack 的“AF - dataRequest“内部内存管理不会缓慢地丢弃未处理的请求、丢弃超时数据包或将干净的错误代码返回主机应用程序 (Zigbee2MQTT / ZigBee - herdsman)、而是完全饱和。一旦 SRSP 缓冲区已满、整个串行接口就会冻结、需要执行硬关机后再开机、并需要一个完整的 NVRAM 闪存、以便每隔几个小时恢复一次功能。

作为企业级元件提供商、TI 不能期望运行关键基础设施的客户实施荒谬的权变措施、例如、仅因为 Z-Stack 无法清除其自己的异步命令缓冲区、通过外部继电器物理切断 MCU 电源。简单的网络搜索证明、社区受到 CC2652 系列上这些“SRSP AF“和 Z-Stack 崩溃循环的困扰。

我需要您的工程团队立即对以下几点进行技术澄清：
1、为什么 Z-Stack 无法在完全锁定发生之前实现严格的 FIFO/LIFO 超时机制来清除存储器中已停止的 AF 请求?
2. SimpleLink SDK 中是否有未记录的配置参数或特定补丁可防止 SRSP 接口在大量存在未处理的群集请求时冻结？
3. TI 修复 Z-Stack 核心固件中这一严重稳定性缺陷的官方路线图是什么？

请直接将此问题转发给 Z-Stack 高级系统工程师。对于安全关键型环境、这是停止生产的问题。

RE: [参考译文] CC2652P7：关键 Z-Stack 固件错误

admin — Mon, 06 Jul 2026 22:32:51 GMT

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

尊敬的 Dirk：

请放心、我们正在非常认真地对待这一问题、并努力提供一个能使双方都满意的解决办法。 7 月 3 日是一个假日替代 7 月 4 日在美国的国庆节,因此我们的反应迟缓。关于这一点以及我们无法打开您在 TI 网络上提供的日志、请理解、我们绝不会试图停滞。

我们了解客户创造的产品会对现实世界产生影响、因此我们非常重视技术支持。如果此论坛/主题上的任何答复认为我们损害了您的专业知识、请了解我们通常需要确保我们拥有所有详细信息、并且已尝试每个调试选项来确定正确的解决方案。

关于制作 Z-Stack 开源软件以及与 TI 相关的任何法律和责任问题、我已直接与我们的专家一起向您发送电子邮件、以继续离线讨论、在此基础上、我们希望阐明一些详细信息、您可以接受哪些内容等

此致、

Daniel

重要声明和免责声明| Texas Instruments

RE: [参考译文] CC2652P7：关键 Z-Stack 固件错误

admin — Fri, 03 Jul 2026 17:01:50 GMT

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

另一天是关于 TI 的任何结果或至少反应的争论。

我的耐心已正式耗尽。我一直在处理这种固件锁定的绝对笑话已经超过 4 周了。最初、您的支持回复好像您假设我是一位业余爱好者、坐在家里、手里拿着 5 个智能灯泡。

让我重复一遍：我经营的是一个商业/工业场所。我们正在运行一个包含 120 个 Zigbee 器件的重负荷网络、其中包括 111 个路由器、对大量仪表组数据（实时电源报告，工业光信号等）进行泛洪处理。我们购买了市场上价格最昂贵的高端 LAN 网关 (SMLIGHT SLZB-06P7)、具体取决于您宣传的 CC2652P7 硬件规格。

老实说、SMLIGHT 甚至将这些垃圾组件集成到他们的硬件中、尽管这是一个已知问题、但我确实感到惊讶和愤怒。如果我事先知道 TI 在这里提供了什么样的故障、损坏的垃圾邮件、我绝对会选择采用 Silicon Labs 芯片组的产品。

现在、您的断开、闭源 Z-Stack 正在使我们的设施瘫痪、因为无论在 115200 或 460800 波特下、SRSP/AF 数据缓冲区都会溢出并使协调器崩溃、而无需硬件流控制。

在这篇文章的过程中,我已经联系了几个经销商和业内人士。令我十分震惊的是、我获悉这个特定的缓冲区溢出错误是一个众所周知的长期问题、TI 只是选择忽略数月甚至数年。如果您有意识地不断销售和推广具有突破性架构缺陷的经过认证的工业 Zigbee 3.0 平台、这完全是不可接受的。在迁移到本地控制之前、这一精确的网络在 Tuya 云中完全完美地运行了 6 个月。现在、由于 TI 的 Z-Stack 故障、我们有了一块昂贵的数字砖。

我不是谁会让你浪费我的时间或骑这个。以下是我的最后通牒：
我期望 TI 星期一最迟能提供具体且具约束力的声明和明确的技术决策。

如果星期一没有解决方案或明确的路线图、我将立即采取以下措施：
1.向美国联邦贸易委员会 (FTC) 提出正式投诉,指控其误导性的广告,并在实际负载下销售一个基本破损的产品。
2.与欧洲消费者保护和贸易当局启动监管程序,以基于不遵守数字产品保修 (Sachmangel) 的情况强制执行销售禁令/产品召回,因为您的硬件未能实现承诺的规模。
3.在所有主要社交媒体平台和开发者论坛上发起最大规模、无情的公共活动/暴风雨。我将公开揭露 TI 的无能、他们对自己分销商的系统性无知、以及他们如何对待业务关键型基础设施客户。智能家居和工业社区需要准确了解他们购买的不可靠性是什么类型。
4.如果您的内部团队太无能修补此缓冲区溢出,请立即开源 Z-Stack 二进制组件（如 libZStack_Nwk_all.a）,这样社区就可以帮您解决问题。

Silicon Labs 设法保持其栈透明和稳定。如果 TI 继续忽略严重的企业破坏错误、我们（以及整个社区）将永久迁移到 Silicon Labs 硬件。

时钟计时。我希望星期一提供答案。

在这个意义上,我祝你的团队有一个美好的周末。

Dirk Freiherr zu Wilmannsberg

RE: [参考译文] CC2652P7：关键 Z-Stack 固件错误

admin — Thu, 02 Jul 2026 15:47:41 GMT

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

主题：关于：CC2652P7：关键 Z-Stack 固件错误 — 紧急：安全风险和责任声明

您好、Ryan、

直接回答：是的、必须立即将此事上报给您的首席执行官、高级管理层以及您的法律与合规部。

这不再是标准的固件问题；这是严重的安全隐患、导致 Texas Instruments 严重受损。

我曾在互联网上咨询过各种来源、包括 SM Light、Zigbee 社区以及使用此芯片的其他制造商、我在所有地方都收到了完全相同的反馈：TI 已经很长时间知道这个问题、但解决这个问题的根本方法却没有。我们个人认为、这种完全不采取行动的做法是完全不负责任的。

实际影响：
我们的系统控制两个交通灯、管理一个带有盲点的单车道桥、由这些信号进行保护。我们放弃了专门针对本地可靠性的其他解决方案。然而、由于当前的 Z-Stack 错误、TI 芯片会出现不可预测的冻结。如果在错误的时刻发生这种情况—在反对交通进入桥梁的同时、将信号卡在“绿色“上—将导致严重的财产损失、并可能导致人员伤亡。

法律和财务风险：
根据产品责任法、制造或分销导致身体伤害的已知缺陷组件所产生的财务后果是灾难性的。现在这个问题已经记录下来并通过 TI 官方渠道进行了沟通、但任何不当行为都将引发故意过失。在美国、如果责任方意识到严重的安全缺陷并且未能立即采取行动、则可能导致公司官员遭受严重的惩罚性损害和刑事责任。

解决方案:立即为 Z-Stack 开源
我们知道 TI 目前可能缺乏内部资源来在严格的期限内重现、修复和全面测试此错误。因此、Texas Instruments 可以做出的最负责任的决策是立即将 Z-Stack 源代码作为开源代码发布。

Zigbee 社区拥有快速隔离和解决此问题的专业知识。开源堆栈将：
1.允许社区部署修复程序、降低 TI 的法律风险。
2.保护人类生命和关键基础设施。
3.通过展示透明度来保护公司的声誉。

请立即将此问题上报给您的法律顾问和执行团队。对于 TI 计划如何立即降低这种安全风险、我们需要做出正式回应。

此致、

Dirk Freiherr zu Wilmannsberg

RE: [参考译文] CC2652P7：关键 Z-Stack 固件错误

admin — Wed, 01 Jul 2026 14:11:25 GMT

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

尊敬的 Dirk：

感谢您的意见和反馈。我提醒了我的领导、让他们知道您的请求。

此致、
Ryan

RE: [参考译文] CC2652P7：关键 Z-Stack 固件错误

admin — Tue, 30 Jun 2026 15:20:29 GMT

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

您好、Ryan、

postimages.org 是一个标准的、可全局访问的映像主机。如果 TI 的内部公司防火墙限制了对数据的访问、请使用移动设备或非公司网络来检查数据。日志和地图对于理解此问题至关重要、我不会为您的内部 IT 执行基本的网络故障排除。

让我们讨论一下您的技术要点和这种情况的现实情况：

1、波特率和高速故障的现实
您曾询问我们是否使用 921600 波特。我们将 UART 波特率从 115200 提高到 460800 波特、从而开辟了串行瓶颈。这一变化暂时延长了硬锁定之间的时间 — 现在运行了大约 4 到 5 个小时、而不是每 1 到 2 个小时崩溃一次。

不过、让我绝对清楚一点：提高波特率只能减轻打击；不能治愈疾病。我完全期望系统在数小时内再次崩溃。虽然协调器没有立即停止、但内部 Z-Stack 表仍然会耗尽自身资源、导致出现连续的 0xc7 (Nwk_table_full) 和 0xcd (Nwk_no_route) 错误。数据包处理瓶颈是 Z-Stack 内核（而不是串行接口）内的内部固件故障。

2.企业约束和 TI 的责任
建议将 MAC_CFG_TX_MAX / RX_MAX 增加 10x 并将 NPI_TL_BUF_SIZE 扩展到 1024 字节、这是正确的路径。但作为一个终端用户操作的交钥匙硬件,如 SM Light SLZB-06P7 ,我不能简单地重新编译 ZNP 二进制文件自己。

如果标准 TI 参考示例和 SDK 默认值系统地缺少现代网络流量、则 TI 需要将这些优化编译参数（NPI_TL_BUF_SIZE = 1024、UART_ISR_BUF_SIZE = 128、最大化 MAC 缓冲区）直接推入上游 SDK 分支。企业客户为了实现基本的网络稳定性而不得不对核心 SDK 默认设置进行逆向工程和对抗、这是完全不可接受的。

3.市场现实:Tuya vs. Texas Instruments
整个互联网充满用户运行在这个精确的“SRSP - AF - dataRequestNoSRSP 超时后 6000ms“循环中。您不需要我的链接;您只需要使用 Google 查看此问题的规模。

我现在已经处理了这些每天的坠机事件四个星期了,我的耐心已经达到了绝对极限。如果中国制造商能够构建稳定的、通过云连接的 Zigbee 网关（30€）来管理大量路由器流量而不会出汗、那么价值数十亿美元的半导体公司（如 Texas Instruments）必须能够在优质芯片上提供功能强大的本地网络堆栈。

4、即将出现的声誉和图像损坏
该线程正受到开源社区、核心硬件开发人员和企业集成商等的密切监控。如果您持续停滞、请不要低估 TI 所面临的严重声誉和图像损害、提供基本的故障排除技巧、或在关键生产基础设施锁定时借口使用公司防火墙。

我不需要进一步的解释、也不需要将崩溃窗口移动几个小时的解决方法。我希望您的高级固件团队能够立即提供可用于生产环境的具体架构解决方案。

此致、
Dirk Freiherr zu Wilmannsberg

RE: [参考译文] CC2652P7：关键 Z-Stack 固件错误

admin — Tue, 30 Jun 2026 14:20:26 GMT

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

尊敬的 Dirk：

[quote]MAC_CFG_TX_MAX / MAC_CFG_RX_MAX：在标准 TI 参考示例中、通常上限为 5 或 8 个缓冲区[/quote]

标准 TI 参考示例未针对大型网络流量进行优化。由于您有 RAM 允许值、我建议将这些值增加 10 倍、就像在 Koen 的固件补丁中一样。最好评估它们的预构建映像、以确定它们的配置是否对您的系统有利。 NPI TL、其他定义等也有一些变化、您可以从中受益。您使用的 UART 波特率是 921600 而不是 115200 吗？

[quote]npi_TL_BUF_SIZE：在标准 ZNP 构建中通常以 256 字节分配[/quote]

请尝试将其增加到 1024、将 UART_ISR_BUF_SIZE 增加到 128。可接受堆管理器的自动大小配置。您可以尝试实现对握手消息的 NPI 流控制 (NPI_FLOW_CONTROL)、但这需要额外的 RTS/CTS UART 引脚。

[quote]数据包已渗透到无线电层、越过 MAC 层、并在 MT_AF_incoming_MSG~被推过串行端口之前淹没了 CC2652P7 的内部 OSAL 缓冲队列[/quote][quote userid=“706038“ url=“~/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1658992/cc2652p7-critical-z-stack-firmware-bug/6399113 /support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1658992/cc2652p7-critical-z-stack-firmware-bug/6399225

我想这有助于拒绝将不必要的读取响应发送到主机、并使 UART 通信进一步增加负担、不过我们可以理解、在丢弃这些消息之前、这些消息仍会浪费 Zigbee 协议栈的处理时间。

[quote]在充分尊重的情况下、告诉企业客户从生产网状网络强制弹出稳定的工业级路由硬件、因为 Z-Stack 无法处理标准 ZCL 时间同步请求、这不是一个可行的架构缓解措施[/quote][quote]我们不需要来自安全路由器的基本故障排除建议。

我对这一建议表示歉意、不会在进一步的沟通中建议这样做。

[quote]我们需要资深固件工程师调整 ZNP 编译参数、尽可能地提高内部缓冲区结构以匹配 CC2652P7 的物理 124KB RAM 容量、并消除了这种堆耗尽循环。此外、TI 需要直接与 SM Light 等核心硬件集成商协调这些固件优化、以便可以立即将经过修补、可用于生产的 ZNP 二进制文件推送给最终用户作为更新。[/quote][quote]如果 Texas Instruments 缺少工程人员或在技术上无法及时修复此旧内存管理架构、就该到了完全开源的 Z 栈。开放源代码社区很乐意在一周内修复这种持续的堆耗尽错误、而不是让企业客户陷入关键的基础架构锁定。[/quote]

我明白这种行动会大大惠及社会、因为我没有这种权力或权限、我已将你的反馈意见提供给管理层作进一步考虑。

[quote]完整的网络指标和 LQI 库： postimg.cc/.../Y7h3t6t[/quote]

由于防火墙限制、我无法查看此链接。

此致、
Ryan

[/quote]

RE: [参考译文] CC2652P7：关键 Z-Stack 固件错误

admin — Tue, 30 Jun 2026 05:19:58 GMT

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

您好、Ryan、

要使用硬数据和清晰的体系结构证明备份我的技术分析、请查看此生产环境中的附加日志和网络指标。

正如您在网络概述屏幕截图中所观察到的、物理网状网络在射频层上完全正常、经过高度优化且极其稳定。在所有 120 个有源设备（111 个大容量路由器和 9 个终端设备）中、绝大多数路由主干网在三位数范围内保持完美的链路质量指标 (LQI)、其广泛值介于 100 到 160 之间。即使 Eglo 灯也能保持稳定、高 LQI 连接、因为它们仅通过经过优化的 Zigbee 组触发。这种原始的连接质量是严格的基础设施规划、精确的传输功率调谐到–7 个甜蜜点以及细致的部署的直接结果。

不过、看看实时 Zigbee2MQTT 日志：Z-Stack 持续受到“genTime.readRsp“突发的影响。由于在此并发路由负载下内部缓冲区和执行上下文已完全耗尽、因此堆栈会丢弃路径并引发“Nwk_no_route (0xcd)“错误。

让我们对这里发生的事情完全透明:这种精确的高密度网状网络以前运行了六个月以上,而不会发生一次崩溃或冻结,当连接到一个廉价的,30美元 Tuya/Tongu LAN 网关时,使用基本的 Silicon Labs 芯片组。我们将该基础设施迁移到了专用的 CC2652P7 协调器、专门用于实现本地的关键任务独立性、期望 Texas Instruments 硬件提供企业级稳定性。相反、我们会遇到灾难性的软件故障。

简而言之：Z-Stack 目前的记忆管理就像一个步行街边走的行人、努力收集狗垃圾、但他们不是把它们丢弃、而是依次堆叠成一个巨大的堆、正好在路的中间、直到整个街道完全无法通行。

这正是 Z-Stack 处理异步集群请求的方式。它从内部 OSAL 表中收集帧、未清除过期或已完成的执行上下文、并让数据堆叠起来、直到内部串行接口达到致命 6000ms SRSP 锁定。

这不是边沿情况或硬件限制。这是 Z-Stack 处理大量应用层流量的严重架构缺陷。我们不需要基本的故障排除技巧或建议即可从我们的安全关键型基础设施中弹出稳定的路由器。

我们需要资深固件工程师来调整 ZNP 编译参数、尽可能地提高内部缓冲区结构以匹配 CC2652P7 的物理 124KB RAM 容量、并消除这种堆耗尽循环。此外、TI 需要直接与 SM Light 等核心硬件集成商协调这些固件优化、以便将可直接用于生产环境的经过修补的 ZNP 二进制文件作为即时更新推送给终端用户。

一个简单的网络搜索“SRSP - AF - 6000ms 后的数据请求“超时证明,全球智能家居和工业自动化社区正受到这一精确核心缺陷的困扰。如果 Texas Instruments 缺少工程人员或在技术上无法及时修复这种传统的内存管理架构、现在是时候完全开放 Z-Stack 核心存储库的源代码了。开放源代码社区很乐意在一周内修复这种持续的堆耗尽错误、而不是让企业客户陷入关键的基础设施锁定。

完整的网络指标和 LQI 图库： postimg.cc/.../Y7h3t6t

此致、
Dirk

RE: [参考译文] CC2652P7：关键 Z-Stack 固件错误

admin — Tue, 30 Jun 2026 03:09:18 GMT

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

您好、Ryan、

回答您的初始问题：我目前直接管理这个基础设施、没有专门的 TI Field Office 联系人、所以我直接向 E2E 工程平台提出这个问题。

我们来了解一下您提到的核心配置参数。由于此部署在 Zigbee2MQTT /ZNP 架构（基于 Koen Kanters 的 Z-Stack 固件编译）之上运行、因此该固件作为 ZNP（Zigbee 网络处理器）应用运行。

以下是您询问的 Z-Stack 定义的关键编译时值：

* NPI_TL_BUF_SIZE：在标准 ZNP 版本中通常以 256 字节分配。这正是 31 个工业级路由器将高频测量属性与并发 ZCL 时间同步请求流式传输时瓶颈开始的地方。传输层缓冲区只是在串行接口将其刷写到主机之前溢出。
* MAC_CFG_TX_MAX/MAC_CFG_RX_MAX：在标准 TI 参考示例中、通常上限为 5 或 8 个缓冲区。在高密度的 111 路由器网状网络中、这种分配基本上不足以吸收瞬时的 ZCL 峰值。
* HEAPMGR_SIZE:在这些大 RAM P7 配置中设置为 0（自动大小动态堆）,以利用 124KB RAM。然而、OSAL 动态存储器分配在连续异步加载下会出现严重的碎片化、即使物理上可用的存储器也会导致无声的堆用尽。

让我们澄清一个关键点：诸如 Nwk_table_full 或丢弃的报告数据包之类的瞬态错误不会导致崩溃。实际的系统停止故障是致命的“SRSP - AF - dataRequest after 6000ms“超时。当应用层队列与 genTime 查询阻塞时,它们会呈指数级堆积,直到 Z-Stack 的同步接口完全锁定。一旦超过此 6000ms SRSP 超时阈值、内部串行/UART 驱动器扼流圈就会使整个 CC2652P7 无响应、直到执行硬硬件下电上电。

关于您的缓解建议：

1.通过 MT_AfIncomingMsg 进行筛选:由于这是一个 ZNP 编译的二进制架构,因此在主机应用程序层 (Zigbee2MQTT ) 上过滤传入群集请求（如 genTime）的时间太晚了。该数据包已经穿透无线电层、越过 MAC 层、并淹没了 CC2652P7 的内部 OSAL 缓冲队列、之后 MT_AF_INALINING_MSG 甚至被推送到串行端口。 Z-Stack 会在主机应用程序有机会丢弃该消息之前从 SRSP 队列溢出中内部崩溃。

2、强制误操作路由器离开网络:在充分尊重的情况下,告诉企业客户从生产网状网络强制弹出稳定的工业级路由硬件,因为 Z-Stack 无法处理标准 ZCL 时间同步请求,不是一个可行的架构缓解措施。移除路由器会破坏网状路径拓扑并损害依赖于这些精确路由链的安全关键型基础设施。

向 TI 工程部门提出的具体申请：

由于您确认 TI 目前没有修改 Z-Stack 内核源代码以缓慢丢弃出站 TX 缓冲区或限制传入流量的计划、因此我们必须在现有代码库中优化缓冲区分配。

鉴于 CC2652P7 提供了大量的 124KB RAM、从较旧的 CC2652R (80KB) 配置继承的标准基准限值是对硬件的人为限制。

请咨询高级 Z-Stack 系统工程师、并为 NPI_TL_BUF_SIZE、MAC_CFG_TX_MAX 和特定 OSAL 堆调整提供特定且稳定的编译时建议、以明确将内存分配扩展到 CC2652P7 的全部物理容量。如果 TI 无法修补源代码、您必须指导我们如何安全地最大化这些内部缓冲区、以防止串行接口在 ZCL 大量条件下达到致命 6000ms SRSP 锁定。

此致、
Dirk

RE: [参考译文] CC2652P7：关键 Z-Stack 固件错误

admin — Mon, 29 Jun 2026 12:40:24 GMT

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

尊敬的 Dirk：

您是否与 TI 现场或销售办事处联系？为了更好地解决您的问题、我需要知道您使用的 SDK 版本以及您是否应用了 Koen 的建议更改。您的项目是否使用 ZNP 或 ZC 应用程序？具体而言、以下定义的值是什么？

NPI_TL_BUF_SIZE
MAC_CFG_*_MAX
HEAPMGR_SIZE

您可以选择利用 MT_AfIncomingMsg 或 ProcessAfIncomingMsgInd（取决于 ZNP 或 ZC）中的应用程序处理来过滤掉不需要的 ZCL 消息。或者、您可以主动让 ZC 请求“误操作第三方路由器“离开网络并阻止它们重新加入。目前没有修改 Z-Stack 源代码以过滤传入请求或将数据包丢弃到 TX 缓冲区中的计划、因此我们需要尽可能减轻应用中的这种行为。

此致、
Ryan

RE: [参考译文] CC2652P7：关键 Z-Stack 固件错误

admin — Sat, 27 Jun 2026 09:04:18 GMT

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

有关 CC2652P7 上高密度 ZCL 流量下 Z-Stack 崩溃的技术详细信息

您好、Ryan、

感谢您的答复。为了防止常见的“边沿情况“或“超出规格“假设、让我为您提供准确的技术环境以及触发此关键 Z-Stack 冻结的协议级行为。

1、环境（高密度企业网状）
-协调员:SMLIGHT SLZB-06P7 基于 CC2652P7 芯片 (124 KB RAM 可用于 Z-Stack )。
-网络规模:120 个物理 Zigbee 设备（111 个路由器,9 个终端设备）。
-流量简介:这些路由器中的 31 个是工业级智能断路器,通过报告将能量指标（电压，电流，功率）不断流式传输回协调器。

2.触发条件（“ ZCL 时间同步垃圾邮件“）
当特定品牌的灯泡（制造商：Eglo/AwoX）每隔几秒钟向协调器发送 ZCL 时间簇读取请求 (genTime.readRsp) 时、就会可靠地触发碰撞。

3. Z-Stack 失效模式（为什么这是一个核心错误）
当传入能量指标的高频与协调器快速生成 genTime 响应相一致时、Z-Stack 的串行发送缓冲器会完全崩溃。

Z-Stack 不是缓慢丢弃未确认或低优先级的数据包、而是表现出以下行为：
-延迟激增: ZCL 命令响应延迟突然从小于 100 毫秒跳至超过 6000 毫秒。
-串行备货: Zigbee 内核和串行接口（UART/网桥）之间的通信冻结。
-致命锁定: CC2652P7 芯片完全停止响应。需要执行硬下电上电（通过继电器实现物理电压切断）才能恢复。仅进行热软件复位通常还不够、因为内部堆/NV-RAM 状态仍然损坏。

4.向 TI 工程部门提出的问题
作为一名软件工程师、我看到了 Z-Stack 处理应用层上的异步流量峰值的明显架构缺陷。

-为什么 Z-Stack 允许串行/ZCL 响应缓冲区完全耗尽 124 KB RAM 而不是限制传入请求或丢弃过期的出站数据包?
- f8wConfig.cfg 或 Z-Stack 内核中是否存在隐藏的缓冲区分配限制,当处理大容量 genTime 请求时,与标准属性报告一起导致无提示堆栈溢出?

我们需要一个修补程序或编译器标记建议、以针对因误检第三方路由器而导致的这种类型的应用层拒绝服务 (DoS) 来强化 Z-Stack。

期待您的更深入的技术分析。

RE: [参考译文] CC2652P7：关键 Z-Stack 固件错误

admin — Fri, 26 Jun 2026 15:09:20 GMT

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

尊敬的 Dirk：

请提供您正在评估的 SimpleLink F2 SDK 版本、以及任何调试或监听器日志（如果有）。您是否使用了 Zigbee2MQTT ZNP 补丁、是否还能提供有关此版本的更多详细信息？ KOEN KANTERS 和我几年前参与了这个话题,这里是参考:

SIMPLELINK-CC13X2-26X2-SDK：自 SDK 6.20.00.29 起固件不稳定
 https://github.com/Koenkk/Z-Stack-firmware/discussions/483
https://github.com/Koenkk/Z-Stack-firmware/discussions/496

此致、
Ryan

RE: [参考译文] CC2652P：RED 认证测试

admin — Tue, 23 Jun 2026 13:25:24 GMT

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

“你是我的！

BR Luigi

[参考译文] CC2652P：RED 认证测试

admin — Fri, 19 Jun 2026 06:59:56 GMT

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1656957/cc2652p-red-certification-tests

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

CC2652P 器件：

我们目前正在为集成了您的板载无线电模块的电子器件准备 RED 认证流程。

对于认证测试、实验室要求提供用于连续传输模式的专用固件版本、并满足以下要求：

无线电频段占用率高于 98%；
在最高无线电信道上操作；
以最大输出功率传输；
BLE 和 ZigBee 模式的可用性。

请确认您是否已经有这些固件版本、如果有、您是否可以向我们提供这些版本、以便我们可以将它们直接加载到无线电模块上？

另外、如果需要使用这些固件版本对模块进行编程以及设置最大传输功率、请告知我们是否需要任何具体说明、工具或程序。

我们仍可随时获取您可能需要的任何其他技术信息。

BR Luigi

RE: [参考译文] CC2652P：RED 认证测试

admin — Fri, 19 Jun 2026 13:54:45 GMT

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

您好 Luigi、

TI 提供的选项包括 1) Smart RF Studio 7 、这需要 JTAG 连接并使用不需要以任何特定方式对器件进行编程的 ROM 命令进行通信；或 2) 对器件上的 rfDiagnostics 示例进行编程并通过 UART 连接使用 AT 命令来配置无线电和启动测试模式。

任何一个都将满足您的所有要求、无论您选择哪一个、主要取决于您所需的接口。

此致、
Ryan

[参考译文] CC2340R5：CC2350R53 ZBOSS ZIGBEE 如何实现包含 128 个节点的网络规模

admin — Tue, 09 Jun 2026 04:24:41 GMT

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1653445/cc2340r5-the-cc2350r53-zboss-zigbee-how-to-achieve-a-network-scale-of-128-nodes

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

SDK 版本： simplelink_lowpower_f3_SDK_9_14_02_16

参考：zbos-user-guide

配置文件中找到	用法	最大节点数
zb_mem_config_min.h	简单应用和小型网络。	16
zb_mem_config_med.h	而无需大量 Zigbee 功能、例如、广播传输、绑定和组成员资格条目。	32
zb_mem_config_max.h	复杂的应用程序和庞大的网络。	128

大型网络应能够容纳 128 个节点。

但是、使用 ZB_mem_config_max 中的配置实际测试、协调器可以连接到的最大节点数仅为 31。

增加 NVRAM 也没有任何改善、在 ZBOSS 协议栈中、NV（非易失性内存）的最大大小是否限制为 8K？这将导致最大网络大小限制为 32。

RE: [参考译文] CC2340R5：CC2350R53 ZBOSS ZIGBEE 如何实现包含 128 个节点的网络规模

admin — Thu, 18 Jun 2026 12:24:30 GMT

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

我看不到附加的 OTA 数据包日志、并且 C/NVRAM R.txt 文件仅包括 Module_Zigbee_ OSIF、它详细说明了。是否可以在选中所有级别（调试，详细，信息，警告和错误）的情况下启用 Module_Zigbee_Low_Level_ Log.MAC 和 Module_Zigbee_App？将 gc_neighber_table_size 与总 Nwk 容量一起使用会很有帮助。 ZR 是否允许通过其他 ZR 加入 Zigbee 网络并形成网状网络、或者是否都尝试直接连接到 ZC？哪些 ZR 器件、TI EVM 或第三方模块？我假设此测试在 NVS 区域大小为 0x4000 的情况下运行、如果将其增加到 0x6000 或 0x8000、行为是否会发生变化？能否在调试会话的内存窗口中验证 NVS 内存是否已填充？之前您仅报告了 31 个设备正在加入；您知道发生了什么变化吗？

此致、
Ryan

RE: [参考译文] CC2340R5：CC2350R53 ZBOSS ZIGBEE 如何实现包含 128 个节点的网络规模

admin — Thu, 18 Jun 2026 04:31:23 GMT

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

e2e.ti.com/.../C.txte2e.ti.com/.../R.txt

RE: [参考译文] CC2340R5：CC2350R53 ZBOSS ZIGBEE 如何实现包含 128 个节点的网络规模

admin — Thu, 18 Jun 2026 04:02:38 GMT

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

我们通过接口“ZB_Nwk_get_total_capacity ()“获得了网络的总容量,它正好是由 SYSCFG 设置的值 100。

RE: [参考译文] CC2340R5：CC2350R53 ZBOSS ZIGBEE 如何实现包含 128 个节点的网络规模

admin — Thu, 18 Jun 2026 03:51:05 GMT

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

我们对版本 V9.20（simplelink_lowpower_f3_SDK_9_20_00_81 进行了测试）、SYSCFG 中的“Network Maximum Children“参数配置为 100、SYSCFG 中的“Network Maximum End Device Capacity “参数配置为 50。

构建一个由 50 台路由器组成的 Zigbee R23 网络、路由节点逐个连接到网络、当第 44 个路由器节点连接到网络时、无法加入网络。

然后、我们关闭了之前连接的 43 个路由器节点、并仅专注于第 44 个路由器节点的网络连接过程。我们在空中、获得了 Zigbee 帧的日志文件、并获得了协调器和第 44 个路由器节点的串行端口日志。

[参考译文] CC26XX-RESOURCES：Matter V 1.5： — 无法找到对 CC2652R7 的支持

admin — Wed, 17 Jun 2026 03:59:45 GMT

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1656024/cc26xx-resources-matter-v-1-5---not-able-to-find-support-for-cc2652r7

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

尊敬的团队：

我找不到 LP-CC2652R7 LaunchPad 的 Matter 1.5 支持文档或软件支持。

您能否提供有关 LP-CC2652R7 平台上 Matter 1.5 支持的相关链接或文档？

我们也希望提供有关所需 SDK 版本、示例工程或迁移步骤的任何指导。

RE: [参考译文] CC26XX-RESOURCES：Matter V 1.5： — 无法找到对 CC2652R7 的支持

admin — Wed, 17 Jun 2026 13:12:49 GMT

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

尊敬的 Adesh：

TI 目前正在于 2026 年 9 月前认证 Thread 1.4 和 Matter 1.5 解决方案。不过、CC2755xx 平台及所有变体会执行此操作。实际上、CC2652R7 没有足够的闪存来充当 Matter 终端设备、但可以为 Matter 结构控制器执行 Thread RCP 任务。 TI 通过 Open Thread 和 Matter 的下游应用实现了可用于评估的软件支持。

此致、
Ryan

[参考译文] CC2652P：ZigBee 片段可以'；t 使用 0xFF DstEndPoint 接收片段数据包。 SDK 8.30 中找到

admin — Fri, 12 Jun 2026 03:37:02 GMT

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1654773/cc2652p-zigbee-fragment-can-t-receive-the-fragment-packet-with-0xff-dstendpoint-in-sdk-8-30

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

CC2652P 向另一个 CC2652P 发送片段数据包（AP 数据为 90 字节）、DstEndPoint 为 0xFF、另一个 CC2652P 无法接收此数据包。发送方 CC2652P 将等待很长时间（超过 15s）、然后使用故障状态触发 AF_DATA_CONFIRM。

RE: [参考译文] CC2652P：ZigBee 片段可以'；t 使用 0xFF DstEndPoint 接收片段数据包。 SDK 8.30 中找到

admin — Tue, 16 Jun 2026 13:51:21 GMT

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

我们已达成一致、我已向您发送了一条直接消息。

此致、
Ryan

RE: [参考译文] CC2652P：ZigBee 片段可以'；t 使用 0xFF DstEndPoint 接收片段数据包。 SDK 8.30 中找到

admin — Tue, 16 Jun 2026 03:23:39 GMT

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

具有 0xFF 广播端点的分段数据包在 Zigbee 应用中很有用。我已尝试在 Z-stack 3.0.2 的“aps_frag.c“中解决此问题。但没有这个 SDK 8.30.e2e.ti.com/.../aps_5F00_frag.c 源文件