错误处理基础：区分错误、异常与故障，掌握TinyML中错误处理的特殊性

TinyML 系统运行在单片机（MCU）、嵌入式处理器或极低功耗协处理器上，其软件栈与通用 Linux 或桌面环境截然不同。在资源受限的裸机或 RTOS 环境中，错误处理的设计哲学、实现手段和调试路径都呈现出独特的约束。本章首先厘清错误、异常与故障三个核心概念的本质区别，随后深入剖析 TinyML 场景下错误处理面临的特殊挑战，为后续章节中返回码、断言与日志规范的具体实践奠定理论基础。

核心原理：错误、异常与故障的本质边界

在 TinyML 工程语境中，错误（Error）、异常（Exception）与故障（Fault）经常被混用，但它们在系统设计层面有着截然不同的语义和应对策略。错误是指系统在运行过程中出现的、可被预先识别并纳入设计考虑的非预期状态，例如传感器返回的数值超出物理量程、I2C 总线上的 NACK 应答、或模型推理输出的概率向量总和不为 1。错误的特点是可预期——开发者知道它可能发生，并且通常可以通过返回码或状态枚举来传递和处理。

异常则是指程序执行流被硬件或软件机制强制打断的事件，例如除零操作、未对齐的内存访问、或执行了未定义的指令。在桌面系统中，异常通常由操作系统捕获并转换为信号或异常对象；但在裸机 TinyML 环境中，异常往往直接触发处理器内核的 Fault Handler，如果没有正确配置，系统会直接进入死循环或复位。异常的本质是程序状态与处理器约束的冲突，它比错误更严重，因为它意味着代码逻辑本身存在缺陷。

故障则是最底层的硬件级失效，包括时钟源失锁、电源电压跌落、Flash 存储单元损坏、或外部晶振停振。故障通常无法通过软件恢复，只能通过看门狗复位、冗余切换或安全停机来处理。在 TinyML 设备中，故障往往具有累积性和隐蔽性——例如 Flash 磨损导致的位翻转可能在数月后才显现为推理结果异常。理解这三者的层级关系，是设计错误处理策略的第一步。

判断方法：TinyML 错误处理的特殊性分析

TinyML 设备的资源约束从根本上改变了错误处理的设计空间。首先，内存容量限制是最直接的约束。典型的 Cortex-M0+ 内核 MCU 可能只有 16KB SRAM 和 128KB Flash，这意味着无法使用 C++ 异常机制（需要额外的运行时支持表，通常占用 2-8KB），也无法为每个函数调用栈保留大量错误处理帧。其次，CPU 算力限制使得复杂的错误恢复算法（如事务回滚、状态重建）变得不现实——一个 48MHz 的 Cortex-M0 执行一次浮点除法可能需要数百个周期，而错误处理代码不应占用推理主路径的宝贵时间片。

实时性要求则进一步压缩了错误处理的响应窗口。在电机控制或医疗监测等场景中，从错误发生到系统响应的时间必须控制在微秒到毫秒级。这意味着错误检测必须尽量在中断上下文或紧耦合的循环中完成，而不能依赖延迟较高的任务调度。下表对比了通用嵌入式系统与 TinyML 系统在错误处理关键维度上的差异：

维度	通用嵌入式系统	TinyML 系统
可用 RAM	512KB - 数 MB	16KB - 256KB
异常机制	可支持 C++ 异常 / RTOS 信号量	仅支持裸机中断向量或轻量 RTOS
错误传播方式	异常对象、errno、回调函数	返回码、全局错误标志、断言
日志存储	文件系统 + 外部 Flash	环形缓冲区 + 最小擦写次数
恢复策略	任务重启、进程隔离	看门狗复位、安全状态机
调试接口	JTAG/SWD + 交互式调试器	SWD + 串口打印（受限）

从上述对比可以看出，TinyML 的错误处理必须遵循"轻量、静态、可预测"的原则。轻量意味着错误信息不能携带动态分配的内存或复杂的对象；静态意味着错误处理路径在编译期就应确定，避免运行时的分支爆炸；可预测则要求错误处理的时间开销和资源占用是上界已知的，以满足实时性约束。

案例拆解：传感器数据异常的处理策略对比

我们以一个实际的 TinyML 应用场景——基于 Cortex-M4 的振动监测设备——来具体说明错误、异常与故障的区分及处理。该设备以 100Hz 采样加速度计数据，通过轻量级 CNN 模型判断轴承故障。系统约束为：STM32F411 芯片（512KB Flash、128KB SRAM），运行 FreeRTOS，推理任务周期为 10ms。

初始现象：设备在现场运行 72 小时后，偶发输出"轴承正常"的误判结果，但通过串口日志发现部分采样数据出现跳变。工程师最初怀疑是模型精度问题，但离线测试模型准确率正常。

分析过程：通过 SWD 调试器抓取实时变量，发现加速度计通过 SPI 读取时，偶尔返回 0xFFFF 的满量程值。进一步检查 SPI 通信层，发现代码中未处理 SPI 的 MODF（模式错误）标志。当 SPI 主设备检测到片选信号异常时，会置位 MODF 并停止通信，但现有代码仅检查了 RXNE（接收非空）标志，导致读取到陈旧数据。

关键参数与日志：在错误发生前，SPI 的 SR 寄存器值为 0x13（MODF=1, OVR=1, RXNE=1），而正常值为 0x01。由于代码未检查 MODF，错误被当作正常数据送入推理流水线。

处理方案：按照错误分类重新设计处理逻辑：

1. 错误（可恢复）：SPI 通信返回 NACK 或 CRC 校验失败时，设置返回码 SPI_ERR_COMM，由上层任务重试最多 3 次，每次间隔 1ms。
2. 异常（需状态重置）：检测到 MODF 标志时，执行 SPI 外设的软件复位序列（禁用 SPI、清除标志、重新初始化），并丢弃当前采样帧。
3. 故障（需系统复位）：若连续 10 次 SPI 初始化失败，判定为硬件链路故障，触发看门狗复位并记录故障码到 Flash 的专用区域。

结果对比：实施上述策略后，误判率从 0.8% 降至 0.02%，且系统无一次意外复位。通过日志分析，SPI 通信错误被成功捕获并恢复，平均恢复时间为 2.3ms，满足 10ms 的实时性预算。

风险与代价：增加错误检查代码后，SPI 读取函数的代码体积增加了 120 字节，执行时间增加了约 1.2μs（在 100MHz 主频下），但换来了系统的鲁棒性。复盘经验是：错误处理必须与业务逻辑解耦——将通信层的错误检测与推理任务的数据预处理分离，避免错误处理代码侵入模型推理的关键路径。

常见误区与总结复盘

在 TinyML 错误处理设计中，开发者常陷入以下误区：

• 误区一：将所有错误都视为致命故障。这会导致系统频繁复位，丢失宝贵的现场数据。正确的做法是建立错误分级机制，区分可恢复错误与不可恢复故障。
• 误区二：过度依赖断言而忽略运行时错误。断言适合捕获编程逻辑错误（如数组越界），但无法处理外部环境变化（如传感器老化）。断言应作为最后防线，而非主要错误处理手段。
• 误区三：日志记录过于冗长。在资源受限设备上，每条日志都占用 Flash 写入寿命和 RAM 缓冲区。应使用分级日志（ERROR/WARN/INFO/DEBUG），并确保生产版本只保留 ERROR 级别。
• 误区四：忽略错误处理的实时性预算。错误处理代码本身也会消耗 CPU 时间。在中断上下文中执行复杂的错误恢复逻辑，可能导致中断延迟超限，引发更严重的实时性故障。