原创 晶振引发的系列血案

晶振引发的系列血案

         上周陆续接收到一小批量客户返回的“不合格”产品，回来一测试，主要是两个问题：一是液晶屏漏液，通常这是由于液晶屏表面被外物碰撞或挤压造成的，可能是运输流通环节造成的，也可能是用户使用装配过程不规范导致的；最棘手的是另一个问题，用户提供样机对其（我们的模块）做测试，发现常常出现用户的第一幅上电开机界面无法正常显示，本来白色的背景频繁出现花屏（清屏指令丢失）。

         在生产阶段，已经遇到过类似问题，当时断定是采购的晶振批次有这样的问题，已经更换了检验和老化阶段出现问题产品的晶振（其他品牌优质晶振）。但没想到的是，整个批次到用户手中再返回来竟然还有一批这样的产品。细细想想，一点不稀奇，斩草不除根怎么行，生产阶段就应该果断的将整个批次晶振更换掉。

         由于和对方是第一次合作，并且这批产品是用户的替代产品，所以Y总也很重视。周四下午和Y总驱车赶往用户现场，这一去不要紧，对方公司什么技术、采购、主管、副总、老总挨个出场，那个老总脾气火爆，直接当着我们的面劈头盖脸口沫横飞，场面很是尴尬。Y总毕竟是过来人，什么人什么场面没见识过，心态也很是平和，没有硬碰硬，当场检验剩下的产品后，坐下来和对方老总好好的沟通了一番，最终双方都表示应该相互理解，在磨合期相关应该多一些信任和支持。

         作为技术方面的主要责任人，当晚我好好的做了一番检讨，对整个流程的各个环节作了一些检视。周五整个对能够召回的产品更换了晶振，但是测试基本没出现什么异常，只是个别有些不一样的状况出现，以为是一类问题，没太留心，更换晶振了事。

         周一准备发货前再做了一次检验，这一查不要紧，整个批次还是存在问题。第一次出现的状况归咎于那个批次的晶振起振偏慢，只是影响到用户的头几条指令的锁存，不会对后续显示造成影响。但是，今天一早发现的状况却怎么也用晶振的起振偏慢解释不了。因为通常我们推断用户送背景色后马上送清屏指令，如果起振偏慢则整个清屏没实现属于正常现象；而这回却是整个背景黑屏（正常应该为白色背景），黑色就想到背景色初始化时就是黑色，估计是清屏指令送到了，而前面一条背景色指令没送到位，做了一个测试，使用其他颜色作为初始化验证了这个假设是成立的。于是一下午加晚上苦心思索验证，最终解决了问题，这个不仅仅与内部代码的健壮性不够有关，更是与两个系统模块之间上电先后息息相关。

         用户是ARM系统，这边是CPLD系统，两边通过一组准8080并口总线通信。由于本身这是一个替代项目，所以我这边的CPLD系统处于很被动的必须完全就着用户ARM系统的脾性来设计。其实一开始的晶振起振偏慢问题完全可以在不更换器件的情况下解决，用户只要在上电后多做些延时再发指令即可，但是这个问题到工程师出好解决，那些不懂技术又坐高位的人不这么看，所以我们只好把苦水咽下肚子统统算自己的错。

         而今天出现的问题，显然不是晶振起振快慢的事，而是两个系统谁先起来的事情，因此我也一直纠结在CPLD系统这边的复位快慢问题。说实话，很难把握好，复位若是晚了，和晶振起振偏慢是**事；复位快了，就出现新的症状，那组并口总线上的信号在复位前会是一组不确定的状态，此时如果CPLD内锁存这组信号的逻辑（通常可能会用到状态机等进行设计）不够健壮，那么出现异常在所难免，就像特权同学的第一条指令偶尔丢失（100次开机会出现2-4次通常）现象。

         对于新开发的项目，这些问题都是很好解决的，在双方的联调过程中相互协调和改进很容易就可以避免这些系统上电快慢导致的症状。但对于某一方不可更改的情况这就有些困难了，在CPLD系统上必须有足够的出错容忍机制和可靠健壮的代码逻辑来保证系统的稳定。