[参考译文] LP-CC2652RB：Z-stack 发送端点群集数据、不执行传入的开/关命令

路易吉、您好！

您正在使用哪个 SDK 版本？  这仅发生在 ZED 器件上还是也可能发生在 ZRS 上？  可以清楚地说、以前在运行期间接受 ON/OFF 命令时没有出现任何问题的器件将在某个时间停止对这些命令的操作、直到发生复位？  所有器件都容易受到这种行为的影响、还是只有少数几个？  您是否能够进一步量化导致该器件状态发生的情况、或者是否能够通过某种方式可靠地重现行为？  使用监听器器件确认故障器件确认这些数据包非常重要。  您还可以调试应用程序的 zclGenericApp_processAfIncomingMsgInd、 zclGeneral_ProcessInOnOff 以及开/关集群命令回调(如果启用、请参阅 zclSampleLight_OnOffCB 查看示例)函数、以确定应用程序是否接收该数据包以及该数据包在处理过程中从何处失败。

此致、
Ryan

您好、Ryan！ 以下是我的答案。 正如你所看到的、Roberto 不再与我们合作、所以这一个月我不得不努力完成项目、而对我来说、这并不像对他而言那么容易！ 他很生气!

关于您的问题："...在操作过程中接受开/关命令之前没有遇到任何问题的设备有时会停止对其执行操作，直到发生重置" ：是的，这就是所发生的情况：在两天内，3个不同的 ZED 设备出现了此问题。 昨天我对其中的一个进行了重新编程(完成闪存擦除、而非编程和验证)、现在工作正常、需要12个小时。 今天早上一个新的一个 给我相同的行为... 我将对其重新编程。

在实践中、 我发现在对器件进行重新编程之前未发出完整的器件擦除命令、有时某些 器件在上电时无法恢复开/关属性(正如您确定的那样、即使此状态也会保存在 NVM 中)

关于 SDK 我们仍在使用"CC13xx CC26xx SDK [6.20.0.29]"；我记得一个月前 Roberto 安装了一个新版本、在遇到一些问题(应用在 ZigBee 网络级别不工作)后、我们决定继续使用原始 SDK [6.20.0.29]。

因此、如果您考虑转到最新版本、我会尝试执行该操作。 希望我所承担的工作不会超过我现在所承担的工作！

？  您是否能够进一步量化导致此器件状态的可能情况：我真的不知道：我们准备了一个测试台、其中包含20个器件：4个路由器和16个终端器件、它们都在持续运行： 每个器件会定期发送仿真电能测量值、并且必须接受有关开/关属性的远程命令。 实际上、根本无法理解可能的原因；我们也不能在每个器件上安装调试器来在这种状态下调试器件…。

但在最新版本的 FW 中、我会触发一个蜂鸣器发出蜂鸣声、"zclGenericApp_OnOffCB"被称为…μ s。 通过这种方式、我可以了解故障是在回电之前还是在…之后。 我希望以后可以、在这种情况下、我一定能够独自解决问题、但我认为这已超出了我的想象！

因此、我们无法可靠地重现行为。

请注意,这对我们来说是一个重要的项目: 测量港口码头的电力和水消耗,为每艘船,可能远程启用两个供应;所有这些都由一个云服务器管理。 您可以很好地理解系统是否工作、有无数种可能的安装！ 但系统必须非常可靠。 我们是一家小公司、自1983年开始从事硬件/软件业务。 在这个项目上,我们已经投入了大量的可能性,大约50,000欧元:硬件和软件…..

您的帮助对我们非常重要... 我们甚至有兴趣到美国,如果一些开发商在这个问题上可以有一个愉快的整个项目..(自然地支付活动的成本)。 您能以这种方式帮助我们吗？

非常感谢您的友好协作

Br

路易吉

Luigi,

感谢您的详细回答。  因此、有时 器件复位就足够了、但有时 需要重新编程/nV 复位来恢复操作？  这是意外的、因为开/关属性与 NV 存储器本质无关。  某些器件是否可能永不失效？  您可以尝试向  zclGenericApp_processAfIncomingMsgInd 添加其他 GPIO 调试功能、以实现与开/关集群(0x0006)匹配的群集 ID、类似于您的蜂鸣器蜂鸣声以获取另一个参考点。  是否 为报告设置了开/关属性？ ZED 定期发送 CurrentSummationDelivereded 测量的频率如何？  ZED 是否能够接收来自发送这些数据包的 AF ACK ( 有关 AF_ACK_request 的详细信息、请参阅 Zigbee 基础 SLA)或接收任何其他 ZCL 命令(例如、读取/写入其他属性)？  同样、针对有问题行为的监听器日志将会很有帮助。  我无法评论专门用于此次调查的更多 TI 资源。

此致、
Ryan

根据您描述的行为、您的应用程序可能发生内存泄漏。   SDK v6.20的 Z-Stack 工程的 OSAL 堆管理器使用 在*。cfg 文件内声明的静态堆大小 HEAPMGR_SIZE。 增加堆大小会延迟但不能阻止问题的发生。  当继续调试器件时、应该在 IDE 调试器中添加 HEAPMGR_Metrics 预定义和监视堆变量。  《Z-Stack 用户指南》的堆分配和管理部分也介绍了这一点。  您还可以在 BLE5-Stack 调试指南中找到常见的堆问题调试和解决方案。  如果适用、您可以进一步进行故障排除以确定内存泄漏的原因。

您可以使用看门狗外设在器件无响应时强制进行复位。  您可以在   TI 驱动程序运行时 API 和看门狗 示例项目的 Watchdog.h 和 WatchdogCC26XX.h 文件中找到更多信息。  这意味着您可以设置看门狗超时周期并按确定的间隔清除看门狗、如发送  CurrentConsumptionDelivered 值、如果不这样做则表明器件故障、此时看门狗应进行干预并复位器件。

此致、
Ryan

 Ryan、您好、我在此再次对我们的项目提出一些问题：

我们转向"simplelink_cc13xx_cc26xx_sdk_6_41_00_17"  

不是很容易 但现在它可以工作了！  

我在这个新版本上注意到的是、有时应用停止运行：除了 ZigBee 器件没有响应、我看到闪烁 LED (由标准计时器回调处理)停止、这意味着计时器回调也不运行。

这可能取决于需要改进的一些 RAM 定义设置。 当然、我没有做任何与先前堆栈发布相关的修改。

您会告诉我在哪里可以找到这些设置吗？有什么价值呢？

请考虑在我的应用程序中、我 根本不使用堆。

另一个问题:对于类似的需求,在我的应用程序中,我需要执行软件重置;我尝试了"SysCtrlShutdown ()",但它不能运行!

有什么建议吗？

非常感谢

Br Luigi.

这里有一个讨论 RAM 分配的指南、否则除了我 最近的 回复已经提供的内容、我没有其他评论。  您需要进一步调试器件、以了解其当前状态和故障原因。  此外、 您应该使用 SysCtrlSystemReset 来执行器件重置。  SysCtrlShutdown 会将器件置于其最低功耗状态(SHUTDOWN)、只能通过器件复位或使用预配置的引脚来恢复。  您可以了解有关 TRM 中关断状态的更多信息。

此致、
Ryan

谢谢 Ryan！

Br

路易吉