一次遥测波形上报后出现极端尖峰的故障排查记录

设备使用 STM32L4 系列 MCU，外接合宙 4G 模块，把传感器数据上传到云后台。业务里有一段几百 KB 的遥测数据，用于在后台前端预览时间序列波形。

故障现象是前端曲线中偶发极端尖峰。尖峰值明显超出传感器正常范围，且会破坏整段波形的可读性。单看前端图形，问题可能来自三个位置：

传感器采集数据异常。
MCU 内部缓冲区被改写。
遥测数据上报链路发生数据损坏。

这类问题不能只看最终曲线。需要在数据流的关键边界加校验点，把错误范围压缩到一个明确的链路段。

数据路径

本次数据路径可以简化为：

传感器采集 -> 输入缓冲区 -> 边缘 AI 推理 -> 遥测报文打包 -> 合宙 4G 模块 -> 云后台 -> 前端波形预览

前端尖峰是最后一个环节看到的结果。排查时先确认前半段数据是否可靠，再检查上报链路。

遥测报文本身已经带 CRC32。后端收到后会计算 CRC32 并记录校验结果。由于这段遥测波形主要用于问题分析和体验改进，即使 CRC32 错误，后端仍会保存报文并生成报告。这个策略可以避免一次遥测损坏导致整份报告丢失，但也会让损坏数据继续进入前端预览。

先排除采集和内存损坏

第一步检查传感器输出值是否正常。极端尖峰如果来自源头，MCU 侧的原始输入缓冲区应该已经包含异常值。

在固件里增加两个校验点：

边缘 AI 推理前，对输入缓冲区计算 CRC32。
数据上报后，再对同一份输入缓冲区计算 CRC32。

同时增加简单断言，检查采样值是否落在物理范围内，缓冲区长度是否符合预期，写指针是否越界。

示例结构如下：

uint32_t crc_before = crc32_calc(input_buf, input_len);

for (size_t i = 0; i < sample_count; i++) {
    ASSERT(sample[i] >= SENSOR_MIN);
    ASSERT(sample[i] <= SENSOR_MAX);
}

run_edge_ai_inference(input_buf, input_len);
upload_telemetry_packet(input_buf, input_len);

uint32_t crc_after = crc32_calc(input_buf, input_len);
ASSERT(crc_before == crc_after);

实测结果是两次 CRC32 一致，断言也没有触发。这个结果说明输入缓冲区在边缘 AI 推理前后没有被破坏，传感器数据本身也没有出现超范围值。

故障范围由此收敛到遥测数据报文打包、串口传输、4G 模块发送、云端接收和后端解析这几个环节。

查后端 CRC32 日志

遥测报文已有 CRC32，后端日志是第二个关键证据。检查出现极端尖峰的报告后，可以看到对应遥测上报存在 CRC32 校验错误。

这个结果把前端尖峰和上报链路损坏关联起来：

MCU 输入缓冲区 CRC32 正常。
MCU 侧断言正常。
后端收到的遥测报文 CRC32 错误。
CRC32 错误的报告更容易出现极端尖峰。

前端尖峰和波形渲染、边缘 AI 推理改写输入数据的关联降低。当前证据指向上报数据中某些字节发生错误，后端仍按原格式解析，错误字节被解释成异常大的采样值。

为什么 CRC32 错误仍然接收

后端没有因为 CRC32 错误直接丢弃整份遥测数据。这个策略有业务原因：遥测波形用于定位设备问题，报告即使有局部损坏，也可能保留大量有价值信息。

但这个策略需要配套处理：

后端必须记录 CRC32 错误。
前端应该显示数据完整性状态。
波形预览可以对超物理范围的点做标记，避免静默画成普通曲线。
报告结论不能把 CRC32 错误的波形当成完全可信数据。

否则损坏数据会被包装成正常曲线，排查时容易把问题误判为传感器异常或算法异常。

板级差异

进一步对比硬件版本后，问题集中在老 PCB 上。新 PCB 没有复现同类 CRC32 错误。

两个版本中，STM32L4 到合宙 4G 模块的主要连接没有改动。原理图差异主要在其他边缘线路，且两个版本的核心上报链路看起来一致。这个现象说明问题可能不在单条 UART/控制线的原理图连接上，还需要考虑板级实现差异：

PCB 走线边缘变化带来的耦合和串扰。
4G 模块发射电流脉冲对电源和地弹噪声的影响。
老 PCB 物料批次、电容 ESR、连接器接触、焊接状态差异。
天线、模块供电回路、传感器模拟前端之间的空间耦合。

新 PCB 稳定不能直接证明老 PCB 某个器件损坏。它提供了一个约束条件：固件和后端协议基本可用，问题和旧硬件环境下的大块数据上报强相关。

排查顺序

遇到 STM32 边缘设备通过 4G 模块上传大块遥测数据，前端波形出现极端尖峰时，可以按下面顺序处理：

在 MCU 原始输入缓冲区计算 CRC32，确认传感器采集数据稳定。
在边缘 AI 推理前后重复计算 CRC32，确认算法过程没有改写输入缓冲区。
对采样值、缓冲区长度、写指针和发送长度加断言。
检查遥测报文自带 CRC32，确认后端是否记录校验失败。
把后端 CRC32 错误报告和前端尖峰报告做关联。
对比新老 PCB、不同批次模块、不同天线位置和不同供电条件。
在 CRC32 错误时让前端标记数据不完整，避免把损坏点当作真实采样值。

结论

这次问题的关键在数据边界上的 CRC32。前端尖峰只是结果，直接修前端曲线或先改传感器算法都无法解释后端 CRC32 错误。

MCU 侧输入缓冲区前后 CRC32 一致，断言没有报错，说明采集和内存安全嫌疑降低。后端日志显示尖峰报告存在遥测 CRC32 错误，说明大块数据上报链路存在损坏。老 PCB 复现、新 PCB 不复现，则把后续方向指向硬件版本差异、供电完整性、4G 模块发射干扰和大包传输边界。

遥测数据用于排查故障时，可以允许 CRC32 错误的数据进入报告，但必须显式标记完整性状态。否则损坏数据会继续参与波形显示，把通信问题伪装成传感器异常。

本文由 AI 辅助生成，可能存在错误或遗漏，请以实际资料和官方文档为准。