从“能跑”到“跑得稳”：一款环境监测仪的调试手记

在小型智能设备的研发周期里，最磨人的往往不是原理图设计，而是单片机程序里那些“说不清道不明”的时序冲突。上个月，一家做室内空气质量检测仪的客户找到我们，他们的设备在实验室环境下功能完全正常，可一旦接入实际使用场景——比如工厂车间——就会偶发性地出现传感器数据跳变和LCD花屏。问题持续了三周，硬件工程师怀疑是电源纹波，结构工程师怀疑是接地不良，最后排查到我们这边。

这就是典型的单片机程序健壮性不足。上海粱健科技有限公司的调试团队接手后，没有急着改代码，而是先用逻辑分析仪抓取了长达72小时的运行日志。数据显示，故障都发生在设备进入低功耗模式再唤醒的瞬间——唤醒时序里，I2C总线上多了一个不该出现的时钟脉冲，导致传感器寄存器被意外改写。问题定位后，修复只花了半天：在唤醒代码里增加一个20毫秒的稳定延时，并把I2C初始化改为“先复位从机，再发送起始位”。

这类问题在嵌入式硬件开发中非常典型，尤其是涉及多传感器轮询、无线通信和低功耗切换的场合。我们总结了一套调试流程，分享给同行参考：

• 第一步：环境复现。用可编程电源模拟客户现场的电压波动，配合温湿度循环箱，把偶发问题变成可稳定复现的必然问题。
• 第二步：指令级跟踪。在关键函数入口处插入软中断标记，用J-Link RTT实时输出PC指针和寄存器状态，而不是单纯依赖串口打印。
• 第三步：边界参数扫描。对晶振频率偏差、ADC采样窗口、看门狗超时时间进行±20%的步进扫描，找出程序“最脆弱的角落”。

这次项目里，我们还顺手解决了另一个隐患：客户原来的智能控制板设计中，按键扫描和LED刷新共用了一个定时器中断，优先级配置不当会导致按键响应偶尔卡顿。我们把定时器拆分为两个——一个1ms的时基中断用于按键消抖，一个10ms的中断用于LED呼吸灯效果，中断优先级分别设为2和3。改完后，按键响应时间从平均45ms缩短到12ms，体感上“跟手”了很多。

调试过程里那些容易被忽略的“坑”

干这行久了，发现很多单片机程序编写阶段埋下的雷，往往要到现场调试才爆发。这里提三个高频问题：
1）堆栈溢出。小型设备常用的STM32G0系列默认堆栈只有2KB，如果中断嵌套层级深，加上printf重定向，很容易静默溢出。建议在调试阶段把堆栈区填充为0xAA，定期检查边界值。
2）看门狗误复位。喂狗位置不对，比如放在一个可能被长延时阻塞的任务里，会让设备在正常工作时突然重启。喂狗点应该放在主循环的最短周期路径上。
3）Flash擦写时序。如果在掉电保存参数时正好赶上电源跌落，轻则数据丢失，重则Flash损坏。正确的做法是采用双备份区轮流写入，并在写入前检测VDD电压。

这些经验，都是我们在一次次小型智能设备研发调试中踩过坑后总结出来的。比如有个做智能门锁的客户，他们的电机驱动电流有1.8A，启动瞬间会把MCU的参考电压拉低0.3V，导致ADC采集到的电池电量直接跳变15%。这问题光靠软件滤波是压不住的，最后我们在电源输入端加了一个470uF的钽电容和一颗TVS管，配合软件上的滑动平均值滤波，才把电量显示误差控制在±3%以内。

常见问题：客户最关心的三个点

问：调试服务是按时间收费还是按项目收费？ 答：两种模式都有。如果是问题明确、范围可控的专项调试，按项目打包更划算；如果是产品迭代期的持续支持，比如每两周更新一版固件，建议按月服务合同走。我们目前大部分客户选择后者。

问：你们能远程调试吗？ 答：可以。我们自研了一套远程调试盒子，客户把设备寄过来或者我们寄出调试板，通过加密VPN连接到实验室的仿真器上，可以实时查看寄存器值和变量波形。不过要提醒一点，电磁干扰类问题远程很难复现，建议这类问题还是走现场支持。

问：调试完成后会提供哪些交付物？ 答：除了修改后的工程源码，我们还会附一份调试报告，里面包含问题根因分析、修改前后的代码对比、压力测试记录（比如连续运行72小时无故障），以及针对后续开发的预防建议。这份报告对你们内部评审和量产导入都很有参考价值。

回到开头那个环境监测仪项目。最终交付时，客户自己又做了两周的现场挂机测试，故障率从原来的千分之三降到了零。其实很多时候，单片机程序调试拼的不是代码量，而是对硬件底层的理解深度和排查问题的耐心。上海粱健科技有限公司这几年专注在嵌入式硬件开发和智能控制板设计领域，积累的正是这种“把模糊问题变成精确修改”的能力。如果你也正被某个顽固的软件/硬件交互问题卡住，不妨带着现象和代码来找我们聊聊，也许一个周末就能找到答案。