硬件问题排查指南
在项目开始阶段绘制甘特图时，硬件工程师最难估计的部分也许是产品开发的调试阶段。它也是规划中最被忽视的部分之一。
多年来，CAD工具在易用性和集成到PCB和机械方面取得了巨大进展。但归根结底，设计工作是由一个人进行的，这个人不仅容易犯错，而且还可能使用不完整或不正确的数据来设计。除了最简单的设计外，一些错误是不可避免的，因此我们非常需要一种排除这些错误的艺术。
Bug的范围从第一次通电时的 "砰 "声到与完全无关的事情有关的间歇性故障，例如 “外面下雨了导致我的设备挂了 ” 或者“不知道在你那不行，反正在我这里是正常的 ”。因此，修复错误的难易程度也从5分钟的工作到几个月的工作不等。
当Debug进展顺利时，它可能是电子设计中最有趣的部分。在发现和修复难以解决的错误时，会有很大的满足感。但是要想成功，重要的是采取系统的方法来修复错误。
本文列出了在产品开发中采用这种系统方法来排除硬件故障所需的步骤。为了说明这些原则，我将偶尔提到我多年前作为初级工程师在一个系统中进行的工作，该系统用于同时监测16个模拟音频输入。它看起来像下面的图1：
图1：同时监听16个模拟音频输入
该系统由一个多通道ADC板组成，数字音频信号通过一个FPGA，将其复用到DSP总线上。DSP收到中断，告诉它当数据准备好时，它要读取和存储这些数据。FPGA的逻辑是完全异步的。
偶尔，DSP会停止接收中断，整个系统会陷入停顿。这种情况可能相隔数天，或在短短几分钟内发生。软件错误的原因已经被排除，所以这看起来像是一个硬件错误，而我负责进行调查。
第一步：想象成功
调试的一个重要部分是有正确的精神态度，因为持续的问题会磨灭你的士气。特别是，连续两天上班，调查卡在完全相同的点上，感觉很不好。在这种情况下，请问自己："一年后我还会继续卡在这个bug上吗？" 答案是：当然不会! 这个bug不会永远存在，它将会被修复。现在并不是说没有解决方案，而是我根本没有看到它。
第二步：保持记录
抵制诱惑，不要直接投入到试图立即修复这个错误中去。但重要的是，首先要确定其他人是否已经成功地处理了类似的问题。从多个来源收集报告，即使它们有时可能附有相互冲突的数据。在这里，电子表格可以很好地组织你所发现的东西。
第三步：复现问题
这往往是最困难和最耗时的部分。不同的硬件错误出现的频率有很大的不同。因此，在这一点上，基于你所收集的信息，你需要创造条件，使得错误在你的命令下发生。
对于这一点，你可以开始诊断。最初的错误报告可能是 "它停止工作了"，"它崩溃了"，或其他同样模糊的报告。继续努力，直到你从报告问题的人那里得到所有的信息，同时也有足够的信息来缩小可能的原因范围。
不要担心或猜测原因，只需专注于重现这个错误。在这一点上要小心。有时，类似但不同的问题可能看起来是由同一个错误引起的，其中一个掩盖了另一个。如果在寻找最初的bug时发现了其他的bug，请记下它们，以后再去找它们，但不要被牵着鼻子走。
在图1所示的例子中，这个bug是小概率出现的，所以测试的第一部分是编写软件，大力锻炼系统，以最大的速率采样，这减少了故障出现的间隔时间，使得分析更容易。
第四步：收集证据
有条不紊地记录你所看到的和所发生的事情。对于这一点，不要去推测故障的原因，只需建立一个表格，列出哪些东西会加重或减轻症状，哪些东西没有影响。要注意多个Bug可能具有相同的症状，这可能产生相互矛盾的证据。
第五步：优先尝试简单的东西
当你可以重现这个问题时，先找一些简单的解释。例如，连接器是从后往前连接的吗？芯片的引脚排列是否符合Datasheet的要求？时钟是否以正确的频率运行？很多时候，Bug都是由一些事后看来很愚蠢的错误引起的。
请记住，当你做设计工作时，你可能有成千上万的小决定要做；其中大部分是正确的。如果错误被证明是 "明显的"，你可以纠正它并跳到第九步。
第六步：将问题分解
现在简单的事情已经检查出来了。你可以重现这个问题，但也许只是偶尔为之，或者有一些相互矛盾的信息。重要的是要记住，在复杂的系统中，多个错误可能在表面上表现为相同的症状，但需要不同的治疗方法。
为了帮助弄清问题，尽可能地消除系统中似乎与该错误无关的部分。例如，在重新测试时要这样做，你可以关闭PCB上不相关的设备，或者拔掉与其他板子的接线。如果当一个不相关的模块被取出来时，错误突然停止了，你就有了最强有力的间接·证据。把它记录下来。尝试在有模块的情况下再次重现该错误，然后在没有模块的情况下再次重现。
在前面描述的DSP系统中（图1），唯一的症状是来自FPGA的中断有时会停止输入。我们写了一个简单的程序，只是对系统进行刺激，以尽可能高的采样率从中断状态寄存器读取数据，但没有对系统的其他部分进行任何访问。
该错误的频率急剧增加，然后我们发现了FPGA中的一个错误，与系统在新的中断到来时同时读取中断状态寄存器有关。我们修复了这个问题，并对电路板进行了24小时的浸泡测试。23小时又45分钟后，彩旗飘扬，我们开始开香槟庆祝....然后它又崩溃了。
第七步：与同事讨论
当处理那些看起来难以解决的错误时，只要和别人讨论一下就可以了，即使这个人是来自不同的工程学科。向别人解释你所看到的东西，可以让你从不同的角度看待这个错误，并意识到一个关键的事实。至少，你可能会发现一些需要解决的不一致之处，或者收到一些可以尝试的其他建议。
这种对话最好是在行动之外进行。确切地说是通过证据，一次一点，然后寻找可以进行的其他实验或调查。然后回到板子上，继续进行。
在我的例子中，我们和办公室的硬件大师开了个会，把系统跑了一遍，在白板上把它全部画出来。看着FPGA逻辑是如何工作的，他表示FPGA中可能有一个元稳定性问题。
第八步：应用修复
你理解了这个错误，并且想出了一个合理的解决方案。你运行了代码，问题似乎得到了解决。然而，你的工作还没有结束。
第九步：尝试再次打破它
尝试再次破坏系统。为了确定你成功了，你需要对系统进行一系列适当的压力测试，测试的数量级要超过原来的实现。
例如，如果像上面这样的实时系统，每隔十分钟就崩溃一次，而且从来没有持续超过一个小时，但现在却能运行十个小时，那么这个错误几乎可以肯定是被修复了。
你可能会发现，系统表现得更好，但仍然崩溃。但是在这一点上，你可能已经发现了一个被以前的错误所掩盖的新错误。你需要把它作为一个问题来处理，并回到第一步，在 "已治愈 "的系统上进行新的调查。
令人高兴的是，在我的例子中，我们的常驻专家是正确的，对FPGA的简单修改就解决了问题。曾经有两个具有相同症状的错误，其中一个导致了大约5分钟的崩溃，另一个导致了许多小时的崩溃（通常大约5小时）。在我们的浸泡测试中，近24小时的时间被证明是一种侥幸。我们终于再现、分析、理解并解决了这个问题。
第十步。记住 "消失 "的bug仍然存在，如果你没有修复它们
有时bug会自己出现消失。这可能是令人沮丧的，但你可以确定你没有修复这个错误。要么是最初的报告不正确，要么是bug还在那里。这些是在你的老板、他的老板或客户在场时重新出现的那种bug。
抬起地毯并把这些错误扫到地毯下可能是很诱人的，但不要这样做。也许可以把它记录下来，继续研究其他问题，因为它可能会自己回来。但最终，你需要在某个时候回去修复它。所以，需要付出更多的努力来加重问题，以重现这个错误。
第十一步：庆祝
还记得当你被Bug折磨的感觉有多糟吗？现在你获胜的时候当然要庆祝。解决问题后，你现在可以继续游戏了，希望你有信心你能够修复下一个bug。