📚 课程目录第3章异常分类与来源

3、异常分类与来源：硬件异常（看门狗、电源、时钟）、软件异常（断言、溢出、非法指令）与外部干扰

TinyML 设备长期部署在无人值守的现场环境中，异常日志设计的首要任务不是“记录发生了什么”，而是“让开发者能远程还原故障现场”。要设计出有效的错误码体系，必须先对异常来源建立清晰的分类学框架。本章将异常划分为三大类：硬件异常、软件异常与外部干扰，并深入剖析每一类的根因机制、典型表现与定位方法。只有准确区分异常来源，错误码才能具备真正的诊断价值——否则日志只是数据的堆砌，而非故障的导航图。

3.1 硬件异常：看门狗、电源与时钟的失效模式

硬件异常是 TinyML 设备最常见的“无声杀手”。它们往往不产生任何软件报错，而是直接触发复位或进入不可恢复状态。在 Cortex-M 系列 MCU 上，硬件异常通常表现为复位源寄存器的特定标志位被置位，例如 RCC_CSR 寄存器中的 IWDGRSTF、PORRSTF、PINRSTF 等。理解这些标志位的含义，是设计硬件错误码的基础。

3.1.1 看门狗异常：程序跑飞的最后防线

看门狗（Watchdog）分为独立看门狗（IWDG）和窗口看门狗（WWDG）两种。IWDG 使用独立的 LSI 时钟（约 32kHz），一旦启动无法关闭，超时时间由预分频器和重装载值决定。WWDG 则使用系统时钟，要求喂狗必须在特定时间窗口内完成——过早或过晚都会触发复位。在实际部署中，看门狗超时往往意味着主循环被阻塞、中断优先级配置不当导致死锁、或低功耗模式下未正确暂停看门狗。

关键判断方法： 读取复位源寄存器（如 STM32 的 RCC->CSR），检查 IWDGRSTF 或 WWDGRSTF 标志位。若置位，则确认是看门狗复位。此时需要进一步区分：是主循环卡死（软件问题），还是喂狗代码本身被中断/低功耗流程干扰（软硬件交互问题）。

看门狗异常的错误码设计建议：使用独立的高位区间（如 0x10-0x1F），并记录复位时的 PC 指针（通过 LR 寄存器或栈回溯）和最后一次喂狗的时间戳。这些信息能帮助开发者判断卡死位置。

3.1.2 电源异常：电压跌落与毛刺

电源异常是 TinyML 设备现场故障的头号原因。电池供电设备在射频发射（如 LoRa、NB-IoT）瞬间会产生大电流抽载，导致 VDD 瞬间跌落。若跌落幅度超过 MCU 的欠压复位（BOR）阈值，芯片会直接复位。更隐蔽的是电源毛刺——持续时间极短（纳秒级）的电压尖峰，可能不会触发 BOR，但会干扰内部逻辑，导致程序跑飞或存储数据损坏。

判断电源异常需要结合硬件设计和日志数据：

BOR 标志位： 若复位源寄存器中 PORRSTF 或 BORRSTF 置位，说明发生了上电复位或欠压复位。
ADC 采样记录： 在关键任务（如射频发送）前后对 VDD 进行 ADC 采样，记录电压曲线。若发现发送瞬间电压低于 2.8V（以 3.3V 系统为例），则基本可判定为电源跌落。
时间关联： 将复位时间戳与射频发送日志进行时间对齐。若复位总是发生在发送后 1-2ms 内，则电源抽载是根因。

3.1.3 时钟异常：系统心跳的紊乱

时钟异常包括 HSE（外部高速晶振）失效、PLL 失锁、LSE（外部低速晶振）停振等。HSE 失效时，MCU 会自动切换到 HSI（内部高速时钟），但系统时钟频率会发生变化，导致外设时序错乱（如 UART 波特率偏差、定时器超时时间不准）。LSE 停振则直接影响 RTC 和独立看门狗——IWDG 依赖 LSI 而非 LSE，但 RTC 闹钟唤醒功能会失效。

时钟异常的判断需要借助时钟安全系统（CSS）：

// STM32 时钟安全中断处理示例
void NMI_Handler(void) {
    if (RCC->CIR & RCC_CIR_CSSF) {
        // 清除 CSS 标志
        RCC->CIR |= RCC_CIR_CSSC;
        // 记录错误码：0x21 表示 HSE 失效
        log_error(0x21, "HSE failure detected");
        // 系统已自动切换到 HSI，需重新配置外设时钟
        SystemClock_Config_HSI();
    }
}

异常类型	复位源标志	典型错误码	定位要点
IWDG 超时	IWDGRSTF	0x11	主循环阻塞 / 喂狗被中断
WWDG 超时	WWDGRSTF	0x12	喂狗窗口不匹配 / 中断延迟
欠压复位	BORRSTF	0x13	电源跌落 / 电池老化
HSE 失效	CSSF（NMI）	0x21	晶振损坏 / 负载电容不匹配
PLL 失锁	无直接标志	0x22	配置错误 / 电源噪声

风险提示： 不要将所有复位都归为“看门狗超时”。很多开发者只关注 IWDG 标志，忽略了 BOR 和 PIN 复位。建议在系统启动的最早阶段（Reset_Handler 第一条指令后）就读取并保存复位源寄存器，然后立即清除标志位，避免后续初始化代码覆盖原始信息。

3.2 软件异常：断言、溢出与非法指令

软件异常是开发者最熟悉也最容易排查的类型，但在 TinyML 场景下有其特殊性：资源极度受限（RAM 通常只有 16-64KB），栈空间可能只有 2-4KB，且大量使用中断和 DMA，导致软件异常的表现形式更加隐蔽。Cortex-M 内核将软件异常统一映射到 Fault 异常（HardFault、MemManage、BusFault、UsageFault），其中 HardFault 是最常见的“最终兜底”。

3.2.1 断言失败：契约违背的第一现场

断言（assert）是嵌入式开发中最有效的防御性编程工具。在 TinyML 中，断言不仅用于检查函数入参，更应检查传感器数据的合理性（如加速度计读数是否在 ±16g 范围内）、模型推理输出的概率和是否为 1.0、以及内存分配是否成功。断言失败意味着程序已经处于不一致状态，继续执行只会产生更严重的后果。

断言错误码的设计应包含：断言所在文件名、行号、以及断言表达式的内容。例如：

#define ASSERT(expr, err_code) \
    do { \
        if (!(expr)) { \
            log_error(err_code, "Assert failed: %s at %s:%d", \
                      #expr, __FILE__, __LINE__); \
            trigger_system_reset(); \
        } \
    } while(0)

// 使用示例
ASSERT(sensor_data.accel_x > -16.0f && sensor_data.accel_x < 16.0f, 0x31);

3.2.2 栈溢出与堆溢出：内存的慢性毒药

栈溢出是 TinyML 设备最危险的软件异常——它不会立即崩溃，而是先覆盖相邻内存区域（通常是全局变量或堆），导致间歇性故障。当栈指针越过栈底，写入的数据可能破坏任务控制块（TCB）或中断向量表，最终触发 HardFault。堆溢出则常见于动态内存分配（如 TensorFlow Lite Micro 的 Arena 分配），当分配请求超过剩余空间时，返回空指针，若未检查则导致野指针访问。

判断内存溢出的方法：

栈水位监测： 在任务创建时填充栈区域为固定模式（如 0xDEADBEEF），定期扫描栈空间，检查水位线。若水位线超过 80%，则记录警告日志。
HardFault 栈回溯： 在 HardFault_Handler 中提取 MSP/PSP 指针，遍历栈帧，找到函数调用链。若返回地址指向未知区域（如 0xFFFFFFFF），则大概率是栈被破坏。
堆完整性检查： 定期遍历堆链表，检查块头魔数是否被改写。

3.2.3 非法指令与 HardFault

非法指令通常由以下原因引起：函数指针被破坏（指向非代码区）、栈溢出导致返回地址被篡改、或 Flash 内容被意外修改（如 Bootloader 写入错误）。Cortex-M 内核执行未定义指令时会触发 UsageFault，若 UsageFault 未使能则升级为 HardFault。在 Cortex-M3/M4 上，可以通过 SCB->CFSR 寄存器查看具体的 Fault 状态：UNDEFINSTR、INVSTATE、INVPC 等位分别指示不同原因。

实战技巧： 在 HardFault_Handler 中，不要立即复位。先将以下关键信息保存到备份寄存器或 Flash 日志区：

• PSP/MSP 指针值

• PC（程序计数器）—— 指向触发 Fault 的指令地址

• LR（链接寄存器）—— 指示调用来源

• CFSR/HFSR/MMFAR/BFAR 寄存器值

• 当前栈顶的 16 个字（用于后续离线分析）

3.3 外部干扰：EMI、ESD 与电源瞬变

外部干扰是最难定位的异常类型，因为它们在实验室环境中几乎无法复现，只有在现场特定条件下才会出现。TinyML 设备常部署在工业现场、户外杆塔、农业大棚等电磁环境复杂的场所，外部干扰导致的异常往往表现为“随机复位”或“偶发数据错误”。

3.3.1 干扰的传导路径与表现

外部干扰主要通过三条路径进入 MCU：

电源线传导： 工业现场的电机启停、变频器工作会产生大量谐波和瞬变，通过电源线传导至设备。表现为 VDD 上的毛刺或跌落，可能触发 BOR 或干扰内部 LDO。
I/O 口耦合： 长距离传感器线缆（如 RS485、4-20mA 电流环）会像天线一样接收 EMI，将干扰耦合进 MCU 的 GPIO。若 GPIO 配置为输入且未使能内部上拉/下拉，干扰可能导致虚假中断或数据错误。
空间辐射： 射频干扰（如对讲机、手机信号）直接辐射到 PCB 走线或晶振引脚，可能导致时钟抖动或逻辑翻转。

3.3.2 干扰类异常的识别特征

干扰类异常与硬件/软件异常的关键区别在于：复位源寄存器可能显示为 PINRSTF（外部复位引脚）或根本没有有效标志。因为干扰可能直接作用于 NRST 引脚，或导致内部逻辑混乱但未触发任何标准复位源。此外，干扰导致的 HardFault 往往 PC 指针指向随机地址（如 0x0800xxxx 之外的区域），且栈内容呈现“雪花状”随机数据。

识别干扰类异常的辅助手段：

多次复位记录： 在 Flash 中维护一个环形缓冲区，记录最近 10 次复位的复位源、时间戳和 PC 值。若发现复位源交替变化（有时 IWDG、有时 BOR、有时无标志），则高度怀疑外部干扰。
环境关联分析： 将复位日志与现场环境数据（如温湿度、附近设备开关状态）进行时间关联。若复位总在特定设备启动时发生，则基本锁定干扰源。
硬件加固验证： 在电源输入端增加 TVS 管和磁珠，在 I/O 口增加 RC 滤波，观察复位频率是否下降。

重要提醒： 不要试图在软件层面“修复”外部干扰。软件只能记录和上报，真正的解决必须依靠硬件设计改进——PCB 布局优化、屏蔽罩、滤波电路、光耦隔离等。错误码设计的目标是让开发者能远程判断“这是干扰问题”，从而指导现场工程师进行硬件整改。

3.4 案例拆解：工业传感器节点的“幽灵复位”定位

某工业设备监测节点采用 STM32L071 + LoRa 通信，部署在工厂车间。现场反馈设备每天随机复位 2-3 次，无固定规律。初步日志显示复位源为 IWDG 超时，但主循环代码经过审查未发现明显阻塞点。

关键数据收集：

复位源寄存器：IWDGRSTF 置位（0x11）
复位时间戳：集中在上午 9:00-11:00 和下午 14:00-16:00
最后一次喂狗时间：复位前 3ms（正常应在 10ms 周期内）
LoRa 发送日志：复位前 5ms 有一次发送完成

分析过程： 初步怀疑 LoRa 发送后电源跌落导致代码执行异常。但 ADC 采样记录显示 VDD 最低为 3.12V（阈值 2.9V），未触发 BOR。进一步检查发现，LoRa 发送期间 PA（功率放大器）电流高达 120mA，而电池为 2 节 AA 碱性电池串联（3.0V 标称），内阻较大。发送瞬间电压跌落至 2.85V，虽然未触发 BOR，但低于 STM32L071 的 Flash 工作电压下限（2.7V 以下 Flash 读取可能出错）。

根因确认： 电压跌落导致 Flash 读取错误，CPU 执行了错误指令，进入 HardFault。而 HardFault_Handler 中未正确喂狗，最终 IWDG 超时复位。这是一个典型的“电源问题伪装成看门狗问题”的案例。

解决方案：

在 LoRa 发送前，将系统时钟从 32MHz 降频至 16MHz，降低动态功耗。
在电源端增加 470μF 电解电容，提供发送瞬间的电荷储备。
修改 HardFault_Handler，在复位前记录 CFSR 寄存器和 PC 指针，便于后续分析。

结果对比： 整改后连续运行 30 天，零复位。错误码从 0x11（IWDG）变为 0x00（无异常），且新增的 CFSR 记录功能为后续其他现场问题提供了宝贵数据。

经验复盘： 看门狗超时只是“果”，不是“因”。当 IWDG 复位频繁出现时，务必检查复位前的电压曲线、外设事件日志和中断活动。在 TinyML 设备中，电源瞬态导致的 Flash 读取错误是极其隐蔽的故障源，建议在关键代码段（如 Flash 写入、OTA 升级）前增加电压监测。

3.5 常见误区与总结

在异常分类与错误码设计实践中，开发者常陷入以下误区：

误区一：只记录复位源，不记录上下文。 复位源只是“死因”，上下文才是“案情”。必须同时记录 PC、LR、栈内容、时间戳、外设状态。
误区二：将所有异常都映射到 HardFault。 很多异常（如断言失败、内存分配失败）在触发 HardFault 之前就有明确的检测点，应提前捕获并记录，而不是等 HardFault 兜底。
误区三：忽略外部干扰的可能性。 当复位源“不合理”时（如交替出现不同标志），不要强行用软件逻辑解释，应优先怀疑硬件干扰。
误区四：错误码设计过于粗糙。 仅用“0x01 硬件错误、0x02 软件错误”这种粒度，无法支撑远程定位。错误码应精确到具体模块和具体原因。