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

尊敬的 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

有关 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。

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

尊敬的 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

您好、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

您好、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

尊敬的 Dirk：

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

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

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

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

数据包已渗透到无线电层、越过 MAC 层、并在 MT_AF_incoming_MSG~被推过串行端口之前淹没了 CC2652P7 的内部 OSAL 缓冲队列

在充分尊重的情况下、告诉企业客户从生产网状网络强制弹出稳定的工业级路由硬件、因为 Z-Stack 无法处理标准 ZCL 时间同步请求、这不是一个可行的架构缓解措施

我们不需要来自安全路由器的基本故障排除建议。

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

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

如果 Texas Instruments 缺少工程人员或在技术上无法及时修复此旧内存管理架构、就该到了完全开源的 Z 栈。 开放源代码社区很乐意在一周内修复这种持续的堆耗尽错误、而不是让企业客户陷入关键的基础架构锁定。

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

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

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

此致、
Ryan

[/quote]

您好、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

尊敬的 Dirk：

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

此致、
Ryan

主题：关于：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

另一天是关于 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

尊敬的 Dirk：

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

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

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

此致、

Daniel

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