Linux 基金会Zephyr 开源项目已经成长为许多物联网项目的支柱。Zephyr 提供一流的小型、可扩展的实时操作系统 (RTOS)，针对资源受限的设备在多个架构中进行了优化。该项目目前有 1,000 名贡献者和 50,000 次提交，为多种架构构建高级支持，包括 ARC、Arm、Intel、Nios、RISC-V、SPARC 和 Tensilica，以及 250 多个板。
与 Zephyr 合作时，有一些重要的考虑因素要保持事物的连接和可靠运行。开发人员无法在他们的办公桌上解决所有类别的问题，有些问题只有在设备群增长时才会变得明显。随着网络和网络堆栈的发展，您需要确保升级不会引入不必要的问题。
例如，考虑我们部署 GPS 跟踪器来跟踪农场动物的情况。该设备是一种占地面积小、基于传感器的项圈。在任何一天，动物从移动网络漫游到移动网络；从一个国家到另一个国家；从一个位置到另一个位置。这种运动很快暴露了错误配置和意外行为，这些错误配置和意外行为可能导致电力损失，从而导致巨大的经济损失。我们不需要只知道一个问题，我们需要知道它为什么会发生以及如何解决它。使用联网设备时，远程监控和调试对于即时了解问题所在、解决问题的最佳步骤以及最终如何建立和维护正常操作至关重要。
我们使用 Zephyr 和基于云的设备可观察性平台 Memfault 的组合来支持设备监控和更新。根据我们的经验，您可以利用这两者来建立使用重启、看门狗、故障/断言和连接指标进行远程监控的最佳实践。
建立一个可观察性平台
Memfault允许开发人员远程监控、调试和更新固件，这使我们能够：
避免生产冻结，以支持最小可行产品和第 0 天更新
持续监控整体设备健康状况
在大多数（如果有）最终用户注意到问题之前推送更新和补丁
Memfault 的 SDK 可轻松集成以收集数据包以进行云分析和问题重复数据删除。它的工作方式类似于典型的 Zephyr 模块，您可以将其添加到清单文件中。
第一个重点领域：重启
假设您看到设备上的重置数量大幅增加。这通常是拓扑中的某些内容已更改或设备由于硬件缺陷而开始出现问题的早期指标。这是开始了解设备运行状况时可以收集的最小信息，它有助于将其分为两部分来考虑：硬件重置和软件重置。
硬件复位通常是由于硬件看门狗和掉电。软件复位可由固件更新、断言或用户启动引起。
在确定正在发生什么类型的重置后，我们可以了解是否存在影响整个队列的问题，或者是否仅限于一小部分设备。
记录重启原因
void fw_update_finish ( void ) { // … memfault_reboot_tracking_mark_reset_imminent(kMfltRebootReason_FirmwareUpdate, …); 系统重启（0）；}
Zephyr 有一种注册区域的机制，这些区域将在 Memfault 挂钩的重置中保留。如果您要重新启动平台，我们建议您在开始之前立即保存。当您重启平台时，记录重启的原因——在本例中为固件更新——然后将其称为 Zephyr sys_reboot。
在 Zephyr 上捕获设备重置
注册用于读取启动信息的 init 处理程序
static int record_reboot_reason () { // 1. 读取硬件复位原因寄存器。（查看 MCU 数据表中的寄存器名称） // 2. 从 noinit RAM 中捕获软件复位原因 // 3. 将数据发送到服务器进行聚合} SYS_INIT(record_reboot_reason, APPLICATION, CONFIG_KERNEL_INIT_PRIORITY_DEFAULT);
您可以设置一个宏，通过 MCU 复位原因寄存器在复位前捕获系统信息。当设备重新启动时，Zephyr 将使用system_int 宏注册处理程序。MCU 复位原因寄存器的名称略有不同，它们都很有用，因为您可以查看是否存在任何硬件问题或缺陷。
示例：电源问题
让我们看一个示例，说明远程监控如何通过查看重新启动和电源供应情况来深入了解车队的健康状况。在这里我们可以看到少数设备的重启次数超过 12,000 次（图 1）。
12K 设备每天重启——太多了
10 台设备贡献了 99% 的重启
导致设备不断重启的坏机械部件
在这种情况下，某些设备每天重启 1,000 次，可能是由于机械问题（部件损坏、电池接触不良或各种慢性速率问题）。
设备投入生产后，您可以通过固件更新来处理其中的许多问题。推出更新可让您解决硬件缺陷并避免尝试恢复和更换设备。
第二个重点领域：看门狗
使用连接的堆栈时，看门狗是使系统恢复到干净状态而无需手动重置设备的最后一道防线。挂起的原因有很多，例如
send() 上的连接堆栈块
无限重试循环
任务之间的死锁
腐败
硬件看门狗是 MCU 中的专用外设，必须定期“馈送”以防止它们重置设备。软件看门狗在固件中实现，并在硬件看门狗之前触发，以捕获导致硬件看门狗的系统状态
Zephyr 有一个硬件看门狗 API，所有 MCU 都可以通过通用 API 来设置和配置平台中的看门狗。（更多细节见 Zephyr API
让我们使用Nordic nRF9160 的这个例子来完成几个步骤。
转到设备树并设置 Nordic nRF watchtime 文件夹。
通过公开的 API 设置看门狗的配置选项。
安装看门狗。
当行为按预期运行时，定期喂食看门狗。有时这是从最低优先级的任务中完成的。如果系统卡住，它将触发重新启动。
在 Zephyr 上使用Memfault，您可以利用由定时器外设提供支持的内核定时器。您可以将软件看门狗超时设置为早于硬件看门狗（例如，将硬件看门狗设置为 60 秒，将软件看门狗设置为 50 秒）。如果回调被调用，则将触发断言，这将引导您完成 Zephyr 故障处理程序并获取有关系统卡住的那个时间点发生的情况的信息。
示例：SPI 驱动程序卡住
让我们再次转向一个未在开发中发现但在现场出现的问题的示例。在图 2 中，您可以看到时序、事实和 SPI 驱动器芯片的退化。
相关实战：https://www.99qibang.cn/information/5065012d7599477ba363feea663d23de.html
https://www.99qibang.cn/information/b54816cb202c4e0b87b337efd90eaf33.html
https://www.99qibang.cn/information/aa3c164cae604a6481b9480e061464c6.html
https://www.99qibang.cn/information/b82bafc070d0449ca14893f635716452.html
https://www.99qibang.cn/information/f86a6a4bcd104f2daf4001ea2c3eb1fd.html