软硬件调试9步速成攻略,轻松破解99%调试难题，告别死局困境
软硬件调试是一项需要耐心和细致工作的技能。以下是一个简化的9步速成法，可以帮助你快速应对调试过程中的常见问题：
1. "明确问题"：
- 确定问题的具体表现，是硬件故障还是软件错误。
- 收集所有相关信息，包括错误信息、异常行为、环境条件等。
2. "重现问题"：
- 尝试在相同的条件下重现问题，以便更好地理解问题发生的情境。
3. "缩小范围"：
- 通过排除法，逐步缩小问题可能存在的范围。
- 逐一检查可能引起问题的组件或代码段。
4. "记录日志"：
- 记录系统或设备运行时的详细信息，如日志文件、系统信息等。
- 分析日志，寻找问题的线索。
5. "使用调试工具"：
- 利用调试器、示波器、逻辑分析仪等工具进行硬件调试。
- 对于软件，使用调试器逐步执行代码，观察变量值的变化。
6. "逐步测试"：
- 对硬件，可以分段测试电路或组件。
- 对软件，可以逐步添加代码或修改现有代码，观察效果。
7. "假设检验"：
- 基于已有的信息，提出可能的解决方案或假设。
- 对每个假设进行验证，看是否能解决问题。
8. "验证修复"：
- 实施修复措施后，重新测试以
相关内容：
调试是一种思维方式，更是一套系统方法。从工程现场的混乱无序，到建立可复现的模型，从“尝试”到因果验证，我们在不断地将不确定因素转化为确定性。本文总结了我在近期项目中的一些调试体会，分享如下。
一、硬件是基础，软件是竞争力
早期样机阶段，硬件可能存在飞线、暂态干扰等问题。我们的目标是将软硬件一起推向“稳态”：
飞线要规范、打胶要及时，确保结构稳定；
大小公司由于技术缺陷、人员能力不足、资金不足、管理问题，积累不足吗，技术探索等原因，很容易导致新产品投板后存在飞线的情况。早期调试很可能是在有飞线的情况进行的。
但是飞线本身是需要稳定可靠的。其实除了一些高速走线飞线可能会引入干扰问题或者SI问题。一般来说低速走线，通过飞线是不会有阻抗和干扰的问题。例如串口、I2C本身都有很强的容忍度。
但是，一些硬件工程师经验不足，或者飞线方案不合理。会导致，焊得不好（手艺潮），或者飞线的走势不合理，导致仍然是个不定态。
软件不要在“破硬件”上调试，软硬件问题要解耦分析；
软件会抱怨，这个硬件有飞线，不稳定。
但是，其实不是飞线本身造成的问题，而是飞线的操作层面的问题。
硬件交付应具备可插拔、可重复、误操作保护等基础可靠性； 利用测试软件验证硬件可靠性，通过后再正式开展软件调试。
软件应该出一些基本功能验证硬件是可用状态。例如我们的机器人应该是，下位机软件出一套可以验证机器人底盘正常的功能性测试软件，下位机正常后，由上位机出一套验证下位机正常工作的软件。
好的软件工程师早期的时候可以出一些版本帮助硬件定位问题，把硬件的问题做实。防止因为硬件的错误导致软件工程师疑神疑鬼，浪费时间。
二、每项操作要确认结果，不能停留在“感觉对了”
操作完成后必须“确认结果”，而不是凭经验判断：
飞线、接线后要用万用表测通断，排查短路、开路；
USB线、电源线要测压降；
I²C干扰等问题要测阻抗、上示波器看波形；
数据通信类问题，示波器+逻辑分析仪确认结果。
三、复杂系统，先解耦，再调试
当系统特别复杂、无从下手时，最重要的是解耦思维：
时间上解耦：按启动流程、通信链路、控制逻辑分阶段排查；
空间上解耦：将上位机、下位机、控制板、电机拆分单独验证；
示例：NAV2加载失败，可以先验证底盘基本功能是否正常，再逐层加复杂度；
示例：轮毂不转，不要一开始就调导航逻辑，先用串口直接控制电机。
四、现场能力闭环，是调试成功的保障
如果现场工作人员，基本操作能力都不够，基本都验证手段没法快速开展 会影响调试。
很多基础问题出现在现场处理能力不足：
接地、EMC、电源、接线问题，其实是需要有经验的硬件工程师在现场处理；
没有飞线、换芯片、万用表、示波器的基本使用能力；
现场需要快速验证，快速给结论。有些怀疑的点，应该直接验证关闭。现场如果人员基础素养不够，结果是调试节奏被严重拖慢。所以，调试前必须完成现场技术能力闭环。
五、调试不是瞎试：要有因果预测和实验验证
我们要每做一个试验，我们清楚输入条件，和可能带来的结果。我们要做因果关系的预测，然后用试验来验证我们的逻辑。
有的人调试，是穷举法，调大调小，先试试，看看结果，再试试。如果基础问题没解决，自己基本预测没有，其实越充分的记录，越多的实验结果，只会扰乱心智，浪费精力。
有保守派调试法，会在这个阶段考虑过多风险。导致主线调试进展缓慢。如同打游戏一样，我们要先打主线任务。支线任务可以在主线任务完成后，再进行。这样的好处是，你首先建立一条可行而稳定的路线。
5.1 调试的核心流程：
明确试验目的；
预测可能结果；
实验验证逻辑；
得出结论，调整方案。
盲目调试、穷举法、随手记录反而扰乱心智、浪费资源。
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项目经理