IC故障诊断及失效分析：发现事实避免臆测

作者：Maxim应用工程师Bill Laumeister

对一个复杂的设备进行故障诊断的时候，知识储备是最重要的。我们想要并且需要去了解相关的一些问题。它包括正确的IC版本号，在哪里可以找到有关的参考资料，谁真正了解客户端发生了什么。帮助客户是我们最主要关心的，IC的失效分析要求快速而正确地做出响应。但是我们是否应该期望在失效分析的时候，质量保证部可以测试所有条件下的每一个参数呢？不，根本不可能，也来不及。大多数是猜测分析。这可能会引起一些人的吃惊，但质量部门的人也是没有水晶球或者是读心术的。及时有效的IC故障诊断的唯一可能性是从客户端得到关于IC失效的正确信息。

IC的失效分析--它是在浪费时间

我们经常听到，“观念是现实的。”当IC失效的时候或客户认为它失效了，我们必须做一个失效分析。为了更有效，我们必须得到准确的相关信息。这是避免猜测的唯一出路。

让我讲述一个发生在很久以前的小插曲。一个器件由于失效被退回来，我们没有得到任何相关信息。我们对这个器件做了一系列验证，例如运行自动测试设备，台架试验，X光检查，及开盖检查。我们把这个器件浸在软性电子的环境中，放在电子显微镜下观察观察损坏的地方。我们使用液晶涂层来测量温度。这个器件是完好的。我们没发现任何的失效原因。因此质量部在报告中就写了，我们想知道为什么这个器件由于失效被退回来？

大约两个月后，我们几乎是偶然间了解到，当这个器件被加热到+60℃以上，客户的产品会失效。我们再一次做了失效分析。我们在室温下（+25℃）测试这个器件，什么都没发现。当这个器件在测试中被毁坏后，它不再有任何的功能。最终，这是一次返回事件，它没有再次发生。但这里有更重要的教训：没有关键失效数据，我们只能是个盲人，也只能乱加猜测。我们浪费了大量的时间和金钱。（参见附录-IC失效分析在国内的另一个更个人化的古董车故事，接地问题与另一个失效的IC。

彻底的测试对QA来说是徒劳的

多次损坏的IC以至于无法确认损坏的根源。客户从总承包商哪里拿了一块板子回实验室。在实验室里，他们把IC从板子上面取下来，并且声明这个芯片是失效的。很可能，客户会得出一个结论，失效的根本原因是由于芯片本身。他们想要我们做一个失效分析，但失效的数据在哪里呢？当时的境况有被仔细记录吗？如何阻止将来的失效呢？我们又转回到先前的猜测中，而不是实际查看--对有效的失效分析来说，它几乎不是一个良方。

在这个案例中，客户集中在多个输出设备的三个引脚。这是我们所知道的：器件离开工厂的时候有几个部门与数十亿量的认证；在它失效之前，工作了数小时。它会是个初期的失效还是由于外部操作而损坏呢？它已经在客户的电路中了吗？是工作在参考电路环境下吗？是工厂的ESD弱化电路而导致后面的失效吗？也许这是由于运输员忽略了ESD而导致芯片损坏？可能因素的列表看上去是无止境的。

从客户那里收到最初的原理图不是很有帮助。它显示出的既不是什么导致器件失效也没有显示出需要去更改的。FAE需要去检查一下地的处理方式。它是不是有被正确的分割？从原理图上，你无法分辨地的连接。我们收到更多页的原理图，但是现在问题比答案还多。为什么客户仅仅查看很多输出中的三个呢？器件的任何输入或者输出已经和低阻抗连接到板上的引脚吗？电源和地平面是低阻抗连接吗？板上的ESD会有问题吗？我们还是在猜测中。

有效的失效分析--故障诊断是一个犯罪现场

现在我们想问，“怎样在一开始就获得正确的信息呢？”期待QA去做所有的条件下的每一个参数，它是合理的吗？特别是关于这个失效我们什么都不了解的情况下。不是。我们会帮助客户去理解为什么IC会失效，以及纠正它使用正确的应用电路。

显然的，这种做法与那些认为失效分析应该马上做的思路产生冲突。我已经听到，“失效分析经常是第一件要做的事情。在查看IC应用电路之前,先查看IC的内部。”我不能理解这个想法是源自哪里？我也不同意。失效分析不是第一要做的工作。相反地，调查“犯罪现场”和失效事件才是第一步要做的。

故障定位的信息是至关重要的，像警察调查员一样，我们应该竭尽全力去保护现场数据。第一件事是查看IC的应用电路，即，它在哪里失效。这样一个简单的事情，就像焊锡飞溅也可能是真正的答案。IC可能是部分工作，而不是完全失效。事实上，拆卸这颗IC可能会掩盖真实的问题。

对于一个有效的失效分析来说，我们需要查看客户的原理图和收集所有失效的情况，为什么它会失效。是的。这个流程可能会遇到客户保密的问题。这是一个常见的问题，它也就是为什么要有保密协议。这也就是这种情况，FAE作为工厂的眼睛和耳朵在世界各地。FAE可以查看客户的设备，评估他们的原理图，布线，以及应用的其他条件。为了保护客户的秘密，FAE只需要把客户原理图设计的相关部分发送给QA。而现在，QA将要使用这些可信的故障数据做最终处理。