软硬件调试9步速成攻略,轻松破解99%调试难题,告别死局困境

软硬件调试9步速成攻略,轻松破解99%调试难题,告别死局困境"/

软硬件调试是一项需要耐心和细致工作的技能。以下是一个简化的9步速成法,可以帮助你快速应对调试过程中的常见问题:
1. "明确问题": - 确定问题的具体表现,是硬件故障还是软件错误。 - 收集所有相关信息,包括错误信息、异常行为、环境条件等。
2. "重现问题": - 尝试在相同的条件下重现问题,以便更好地理解问题发生的情境。
3. "缩小范围": - 通过排除法,逐步缩小问题可能存在的范围。 - 逐一检查可能引起问题的组件或代码段。
4. "记录日志": - 记录系统或设备运行时的详细信息,如日志文件、系统信息等。 - 分析日志,寻找问题的线索。
5. "使用调试工具": - 利用调试器、示波器、逻辑分析仪等工具进行硬件调试。 - 对于软件,使用调试器逐步执行代码,观察变量值的变化。
6. "逐步测试": - 对硬件,可以分段测试电路或组件。 - 对软件,可以逐步添加代码或修改现有代码,观察效果。
7. "假设检验": - 基于已有的信息,提出可能的解决方案或假设。 - 对每个假设进行验证,看是否能解决问题。
8. "验证修复": - 实施修复措施后,重新测试以

相关内容:

调试是一种思维方式,更是一套系统方法。从工程现场的混乱无序,到建立可复现的模型,从“尝试”到因果验证,我们在不断地将不确定因素转化为确定性。本文总结了我在近期项目中的一些调试体会,分享如下。


一、硬件是基础,软件是竞争力

早期样机阶段,硬件可能存在飞线、暂态干扰等问题。我们的目标是将软硬件一起推向“稳态”

  • 飞线要规范、打胶要及时,确保结构稳定;

    大小公司由于技术缺陷、人员能力不足、资金不足、管理问题,积累不足吗,技术探索等原因,很容易导致新产品投板后存在飞线的情况。早期调试很可能是在有飞线的情况进行的。

    但是飞线本身是需要稳定可靠的。其实除了一些高速走线飞线可能会引入干扰问题或者SI问题。一般来说低速走线,通过飞线是不会有阻抗和干扰的问题。例如串口、I2C本身都有很强的容忍度。

    但是,一些硬件工程师经验不足,或者飞线方案不合理。会导致,焊得不好(手艺潮),或者飞线的走势不合理,导致仍然是个不定态。


  • 软件不要在“破硬件”上调试,软硬件问题要解耦分析

    软件会抱怨,这个硬件有飞线,不稳定。

    但是,其实不是飞线本身造成的问题,而是飞线的操作层面的问题。

    硬件交付应具备可插拔、可重复、误操作保护等基础可靠性;

  • 利用测试软件验证硬件可靠性,通过后再正式开展软件调试。

    软件应该出一些基本功能验证硬件是可用状态。例如我们的机器人应该是,下位机软件出一套可以验证机器人底盘正常的功能性测试软件,下位机正常后,由上位机出一套验证下位机正常工作的软件。

好的软件工程师早期的时候可以出一些版本帮助硬件定位问题,把硬件的问题做实。防止因为硬件的错误导致软件工程师疑神疑鬼,浪费时间。

二、每项操作要确认结果,不能停留在“感觉对了”

操作完成后必须“确认结果”,而不是凭经验判断:

  • 飞线、接线后要用万用表测通断,排查短路、开路;

  • USB线、电源线要测压降

  • I²C干扰等问题要测阻抗、上示波器看波形

  • 数据通信类问题,示波器+逻辑分析仪确认结果


三、复杂系统,先解耦,再调试

当系统特别复杂、无从下手时,最重要的是解耦思维

  • 时间上解耦:按启动流程、通信链路、控制逻辑分阶段排查;

  • 空间上解耦:将上位机、下位机、控制板、电机拆分单独验证;

  • 示例:NAV2加载失败,可以先验证底盘基本功能是否正常,再逐层加复杂度;

  • 示例:轮毂不转,不要一开始就调导航逻辑,先用串口直接控制电机。


四、现场能力闭环,是调试成功的保障

如果现场工作人员,基本操作能力都不够,基本都验证手段没法快速开展 会影响调试。

很多基础问题出现在现场处理能力不足:

  • 接地、EMC、电源、接线问题,其实是需要有经验的硬件工程师在现场处理;

  • 没有飞线、换芯片、万用表、示波器的基本使用能力;

    现场需要快速验证,快速给结论。有些怀疑的点,应该直接验证关闭。现场如果人员基础素养不够,结果是调试节奏被严重拖慢。所以,调试前必须完成现场技术能力闭环


五、调试不是瞎试:要有因果预测和实验验证

我们要每做一个试验,我们清楚输入条件,和可能带来的结果。我们要做因果关系的预测,然后用试验来验证我们的逻辑。

有的人调试,是穷举法,调大调小,先试试,看看结果,再试试。如果基础问题没解决,自己基本预测没有,其实越充分的记录,越多的实验结果,只会扰乱心智,浪费精力。

有保守派调试法,会在这个阶段考虑过多风险。导致主线调试进展缓慢。如同打游戏一样,我们要先打主线任务。支线任务可以在主线任务完成后,再进行。这样的好处是,你首先建立一条可行而稳定的路线。

5.1 调试的核心流程:

  1. 明确试验目的;

  2. 预测可能结果;

  3. 实验验证逻辑;

  4. 得出结论,调整方案。

盲目调试、穷举法、随手记录反而扰乱心智、浪费资源。

5.2 不要“屎上雕花”

我们如果已经明确了某个错误,那么就是坚决的解决错误,确保我们的设备状态是正确的,而不是:我们改正错误之后,发现没有解决问题,再改回去试试。

例如一个同事把i2c两个脚弄反了,他把飞线改对了,但是仍然没通。他就又改回去试试。这是明显的“瞎试”。因为改回去是一定不通,有什么好试的。看似简单的问题,在黔驴技穷之时,迫于压力,很多工程师思路没有平时清晰,会变得思路混乱。

改对后,仍然没有出来,我们应该整理必要条件:驱动管脚配置是否对;万用表看看有没有短路、断路;示波器看看有没有波形;I2C地址是否正确;I2C设备是否能否扫描到;最后还不行,那就上逻辑分析仪。

例如,我们明显看到一个错误的报警,也可以把机器人启动,但是运行时会有偶发故障。那么我们要先尝试清除这个错误后,再做偶发故障的分析。不要“屎上雕花”。

  • 错误必须先解决,而不是放着不管、边调边忍;

  • 改错后如果仍不成功,应该继续验证其他必要条件

  • 示例:I²C引脚接反,飞线改正后仍不通,不能再改回去“试试看”;

  • 要查:驱动配置、I²C地址、波形是否正常、总线扫描是否识别、逻辑分析仪排查是否有 ACK。


六、面对偶发故障:先找“必现条件”

其实在调试过程中,我们其实并不惧怕“必现问题”、“共性问题”;我们往往惧怕"难复现问题(偶发故障)",“个性问题”。

我们在处理问题时,首先要区分问题是“共性问题”还是“个性问题”;要区分是“必现问题”,“高频问题”,“低频偶发问题”。问题特点不同,策略不同。

对于偶发问题,很重要一点是找到“必现条件”。一旦找到“必现条件”,其实问题已经解决90%了。

如何找到“必现条件”是解决问题的关键。

找必现条件的思路:


a. 探索可稳定运行路径,找到最简可行模型

当系统出现偶发故障时,我们可以尝试简化模型(关闭暂时不必要的电机)、减少功能(机器人复杂任务变成简单路径,看是否可以完成任务)、裁剪模组(只运行机器人的雷达,关闭IMU、关闭深度相机、关闭测距传感器等等)。

b. 梳理规避措施与前提条件,逐一验证

即:我们上述措施哪条落实之后,机器人是一个稳态。这个稳态可能距离最终目标很遥远,但是没管理。我们先确保其在我们期望的范围。

c. 所有操作都标准化,避免人为干扰;

整理出最简稳定模型的必要条件,每次运行时要确保一定规范操作。手动操作的过程,要完整规范。避免复杂手动操作。

如果有条件和能力尽早进行自动脚本,让计算机代替人的操作。如不能,曾形成操作规范,不要因为人未按照操作规范导致不好结果,而做重复问题定位。最好是每个操作,有个结果确认的过程。

比如我们前两天在定位传感器时钟同步问题,得出一个结论是:在没有RTC时钟的时候,启动时需要获取NPT时钟。但是程序员内心可能觉得这个措施可能不是关键因素,所以他不是每次操作都会执行这步。并且他觉得经常软件重启的时候,没有做这步操作,也没有问题,就没有严格执行这个操作。

但是,其实这个故障激发条件是‘下电’。结果在升级下位机的操作时,他没有严格按照解决问题总结出来的结果去操作。导致又在定位“时钟不同步”的问题。

正确的做法应该规范执行已经拟定的措施,更好的做法是尽早合入软件脚本,而不依赖人的记忆和习惯去保障操作规范。

d. 故障注入,做实“必现条件”

我们在找到可稳定运行最小版本后,再做故意的故障注入,看故障是否稳定复现。确认每个我们怀疑的点是否是真的问题点。

成功运行后,尝试故障注入法,确认可控复现路径;确认故障结果确实是由于某个原因造成的。做实“必现条件”。

e.一次只改一个输入变量

调整输入条件要一步一步进行,避免一次性修改多个变量;
比如,我们去做EMC试验,我们想尽快得到一个好的结果,结果落了一堆措施,又是接地,又是加屏蔽,又是加磁珠,又是加电容。结果:结果更差了。你是不是茫然无措?

你只能回退措施,因为你不知道哪个“整改措施”干了坏事。你应该落一件措施,确认一下结果。如果好了就落实,如果没好就回退。做好记录稳扎稳打。

调试的时候,由于急于求成,思维活跃,往往会在一个措施落实结果还没有出来的时候,就开始思考其他问题,导致思路混乱,东一榔头西一棒。

f. 归档最简稳态模型,以便调试中途回退用;
年轻的工程师有个最严重的问题,就是版本记录的问题。往往干了一堆事情,没有做好版本记录。特别是调试复杂系统的时候,一旦一个最简模型形成稳态之后,需要做归档措施。因为你开始叠加功能时,会新增问题,有可能需要回退。此时需要调试人员保证可以回退到最简稳态。

有结论了,记得抓紧归档。

g. 不要疑神疑鬼,试验能验证的假设就尽快验证

比如你怀疑是环境光影响,你可以快速做试验,拉窗帘,或者换地方,确认环境光是否有影响。有影响就是有影响,立即解决该问题。没影响就是没影响,试验几次,证明没影响。之后就不要疑神疑鬼。

有一种盲目的勤奋,就是我们还没找到主线最简模型的时候,总是在做故障注入 或者考虑复杂场景。这种行为是徒劳。

调试时,忌讳的是在没有掌握主线流程之前,就开始测试边缘条件。这是典型的“盲目勤奋”。

七、调试必须基于事实与数据

调试时不能说“感觉慢”、“不太稳”、“还行”这种模糊语言。需要:

  • 明确每次测试的目标、输入、输出

  • 使用量化手段进行验证,明确是“1ms延迟”还是“偶发丢帧”;

  • 调试阶段不是为了“测试覆盖率”,而是为了“验证理论链条”。


八、沟通:技术闭环的加速器

当你在局部遇到无法自闭环的问题时,一定要及时沟通:

  • 没有硬件人员时,视频远程请教

  • 跟原厂沟通,让FAE先看看问题,不要闷头硬啃;

  • 问题点要细拆,不要一句“调不通”;

  • 尽量避免“词不达意”:
    a. 对方是否听得懂?
    b. 你的表达是否含糊?
    c. 是否通顺、准确、量化、无歧义?


九、调试思维:聚焦 vs 发散

人的思维需要在发散和聚焦的状态灵活切换。发散时充分发散,聚焦时充分聚焦。不要刚发散,就急着收敛、刚开始收敛又开始发散。

如果不擅长切换,则安排只做某一个状态岗位。比如有些人只适合做测试(保守思维、防御性思维、风控思维),有的人只适合做新品研发(冒进思维、进攻型思维、机会思维)

调试是理性与直觉的结合,需要不断在发散与聚焦之间切换:

  • 聚焦:确保最小功能模型稳定运行;

  • 发散:系统性考虑可能的异常路径;

  • 不能快速发散收敛思维切换的人,不适合独立调试复杂系统;

  • 可以根据个性分工:

    • 保守型做测试验证;

    • 冒进型做新品开发。



总结:

以上内容,是我今天夜里做梦总结,凌晨三点多醒来,抓紧用手机快速记录梦里总结了2700多字,今天白天整理了一下,送给正在调试的痛并快乐着的工程师们。

调试是一项综合性的工程能力,需要逻辑、工具、方法和沟通协同。在混乱中建立秩序,在复杂中构建清晰,是调试的本质。

把这些调试习惯沉淀下来,是一个团队从“能做项目”迈向“能做好项目”的关键转折。

研发管理相关文章

  • 如何避免硬件项目进度拖延

  • 好的管理是“过程管理”

  • 项目成功的精髓:做好价值管理

  • 研发KPI迷思

  • 绩效管理

  • 此计甚妙,速速办之

  • 技术人员必须具备哪些“软实力”?

  • 如何找到解决问题的思路和方法

  • 以结果为导向

  • 我们需要什么样的硬件工程师

  • 心中有地图

  • 硬件不是连连线

  • 寻找 能解决问题的人

    技术精进“日积月累”:解构+验证+文档化+分享+总结+改进+夯实

  • “转身”——从技术岗到管理岗

  • 融入开发流程的“技能提升”,达成“事成人爽”

  • 为什么其他公司模仿华为搞流程容易失败

  • 问题攻关

  • 构建 开发流程

  • 需求、进度、成本的基线与管理

  • 从“公司战略”落地到“需求管理”

  • 在华为我是一颗螺丝钉,离开华为我只能拧拧螺丝

  • “雷锋”一直在吃亏!

  • 已发货产品出现问题,如何亡羊补牢

  • 工作要有热情?一定是领导在PUA你

  • 关于“学习的能力”

  • 有效沟通(从李云龙沟通说职场沟通技巧)

  • 计划管理

  • 关于“狼性”

  • 硬件必读质量管理:华为式“持续改进”的深度解密

  • 关于硬件工程师进阶

  • 硬件工程师进阶:系统化思维

  • 产品经理VS项目经理

发布于 2025-07-08 23:51
收藏
1
上一篇:投资理财需谨慎,天门公安揭秘骗局拆解指南 下一篇:没有了