第一章：NB-IoT终端死机现象面面观

大家好，我是老张。做NB-IoT终端开发这些年，我见过最多的故障就是——死机。说句实话，死机这问题，看着简单，查起来真要命。今天咱们就来聊聊，死机到底长什么样，它怎么影响你的业务，以及我个人的排查思路。

1.1 死机的典型表现

死机不是只有「屏幕不动了」这一种。在NB-IoT终端里，死机的表现五花八门。我总结了几种最常见的：

• 完全无响应：终端像块石头，串口敲回车没反应，LED也不闪了。说白了，CPU已经停止执行代码。
• 周期性死机：运行几小时或几天后挂掉，复位后又正常。这种最坑人，我在项目中遇到过，查了整整一周才发现是内存泄漏。
• 部分功能失效：比如能发数据但收不到下行，或者模组AT指令能回但应用层不干活。嗯，这种往往是任务调度出了问题。
• 看门狗反复复位：终端不断重启，日志里全是复位记录。你想想看，这通常是喂狗线程被高优先级任务卡死了。

1.2 死机对业务的影响

死机不是小事。我见过一个水表项目，终端死机后整整三天没上报数据，结果用户投诉说水费算错了。影响有多大？咱们列一下：

影响维度	具体表现	严重程度
数据上报中断	传感器数据无法上传，平台侧出现数据空洞	高
下行指令丢失	远程升级、参数配置等操作失败	中
功耗异常	死机后电流可能飙升，电池寿命缩短	高
运维成本增加	需要派人到现场手动复位，人力成本翻倍	中
业务连续性受损	关键场景（如烟感、燃气报警）可能造成安全事故	极高

我记得有个做智能路灯的客户，终端死机后灯整晚不灭，被居民投诉到城管。你看，死机不只是技术问题，更是业务问题。

1.3 死机问题的排查思路

排查死机，我有一套自己的方法。说白了，就是「由表及里，层层剥离」。你按这个顺序来，大概率能定位到根因。

第一步：收集现场信息

• 死机时的环境温度、供电电压
• 最后一次正常通信的时间戳
• 复位引脚的电平状态
• 模组输出的错误码（如果有）

第二步：区分硬件还是软件

怎么区分？很简单：

• 如果复位后能稳定运行，但特定操作（比如发大包数据）必死，那多半是软件问题
• 如果终端在震动、高温或低电压下频繁死机，那硬件嫌疑大

我曾经遇到一个案子，终端在-20℃时必死，查了三个月才发现是晶振在低温下起振不稳。嗯，这种坑踩过一次就记住了。

第三步：软件层面的排查重点

1. 任务栈溢出：RTOS里每个任务都有栈空间，栈溢出会直接覆盖关键数据。我建议把栈使用率打印出来看看。
2. 内存泄漏：malloc了不free，或者消息队列只发不收。跑个压力测试，观察内存余量是否持续下降。
3. 中断优先级配置：低优先级中断被高优先级中断长时间阻塞，导致喂狗失败。你想想看，中断嵌套太深，CPU就转不过来了。
4. 临界区过长：关中断时间太久，其他任务饿死。我见过有人把Flash擦除操作放在临界区里，一擦就是几十毫秒，系统直接瘫痪。

第四步：硬件层面的排查重点

• 电源纹波：NB-IoT发射时电流峰值可达300mA，如果电源响应慢，电压跌落就会导致复位。
• 复位电路：复位引脚有没有加电容？有没有被干扰？我建议用示波器抓一下复位引脚的波形。
• 看门狗配置：外部看门狗的喂狗周期是否合理？内部看门狗有没有被意外关闭？

第五步：复现与验证

死机问题最难的就是复现。我的做法是：

• 搭建自动化测试环境，24小时跑压力脚本
• 用逻辑分析仪抓取关键信号（复位、UART、GPIO）
• 在代码里埋点，通过串口输出调试信息

说白了，排查死机就像破案。你得有耐心，有工具，还得有点运气。但只要你按这个思路一步步来，90%的死机问题都能找到根因。