奋斗吧，程序员——第五十一章 黑云压城城欲摧，甲光向日金鳞开

Posted 2020-07-20 yuanyun_elber

转眼到了年底，芯原的bit文件出来后，我们持续进行测试。

芯原是大公司，遇到问题习惯性怀疑是我们这里的操作有毛病，于是反复的对比试验和扯皮开始了。

“fpga发现接收数码相机fir信号出现帧错误，因为出现80ns脉冲？”

芯原立马说这个脉冲是错误的。

我只能给对方看datasheet上的冗余度，告诉他们这种情况是在容错范围内的。

同时在开发板上换上EG的芯片，抓到同样的80ns脉冲的情况，EG能识别的现象给他们看。

假如说我这里遇到问题需要求助的话——

“小叶：
上次提到的芯片有时侯发送会把整个bank发送出来的问题，产生原因我现在还没发现什么规律，最近又经常发现了，有时侯还会有没有发送出来的情况．
请给我一些寄存器配置方面的建议
我现在是这样配置的：

......

”

对方就会回答：

“

elber，你好！
从你下面所列出的寄存器配置来看，我觉得应该没有什么问题，所以我目前也没什么建议可以提供。
我个人感觉，这个问题应该跟芯片工作稳定性有关。你最好在出现这种情况的时候，确认一下配置是否正常。（比如相关寄存器是否被正确写入） 

”

基本上很难指望对方能帮得上忙，一切都得靠自己。

这段时间经常要去上海出差，现场解决问题。

FPGA验证持续了月余，其实时间是比较紧的，如果这时候不把问题都测出来，等到流片下去，就是一大笔钱。

而有些问题，我们的确认，是有风险的。

比如说，信号的时钟不准导致的偏差，这里面有个冗余度的问题。

冗余度太大，会引起错的frame识别不出来, 冗余度太小，会识别不了正确的frame，这个是需要反复测试的.
这个问题又和数据有一定关系，假如那个字节里有0的话一般不会出问题，时钟会重新锁定，假如哪个字节里有连续的1的话，就有可能出问题。
协议上并没有规定冗余度，所以不好保证设置好的冗余度能支持所有手机，我们只能用手上所持有的手机试了。

所有的手机通过就认为Pass，当然，风险就来源于手机库里的手机太少，不像我以前的客户，sanyo财大气粗，库里有几百台手机。

FPGA结束后，去中芯国际流片，wafer的芯片又要进行测试。

这一测，又是一堆问题。

“芯片在附近有手机信号或者日光灯直射的时候出现大量frame error。而FPGA没有。
而中午光线较好时无这种现象。清晨和黄昏以及阴雨天是红外线最强的时间。”

芯原回复，“请提供详细对比试验的数据。”

测试这项工作枯燥而无趣，最关键的部分在于，从大量的数据中，提取出有用的信息，并总结出来。

好在芯片总算在2009年的春节前新鲜出炉了。

达真方面也如约发来正式邮件：

“

Dear Peter&Elber,
通知一聲，已接獲Foxconn通知，Sharp案正式開案，
請再幫忙確認貴公司module能支持： 

IRDA/IRSS......

”

Sharp案已經正式kick off，第一階段要在3/4前完成Module的driver porting。

这是我们的第一个项目，我们俱是摩拳擦掌，准备大干一场。

进入第二阶段，联合调试阶段，开始了漫长的煎熬。

因为这次协议的提供方是台湾的另一家公司ACTISYS，我们无需提供协议，只需要根据对方的要求写好底层的API接口就可以。

ACTISYS也是一家大公司，是红外协会的会员，负责接口的工程师是印度人Suresh，特点是遇到问题就发很长很长的英文邮件，大体意思无非两类。

一、这个问题肯定是SP的问题。

二、明天是周末，本人绝对不加班，有问题周一再搞。

芯片提供方ITE是联阳科技，位于台湾新竹，也是一家大公司，他们的付总一口官腔，遇到问题也是往SP身上推。

这种多方合作的项目，有很多问题是很难定位的。

所以，这段时间，Sharp方的日本经理经常在电话会议里发飙，指名道姓要elber 出来解释。

在问题没弄清楚之前，我只得忍气吞声。

这段时间我发的邮件必须有理有力有节，既要提供证据，又要维护大公司的颜面，毕竟以后还要合作下去，撕破脸皮不好。

比如说有一次，台湾ACTISYS方面开始测试协议，我们提供的API发现不能用，数封邮件来回后没有解决问题，我只能出差到深圳，最后抓了波形，发现问题在ITE的spi驱动。

于是还得发邮件向ACT解释：

“

Dear Suresh,
Please update the attached file for testing the IrSS Driver.
It includes these file as follow:

sdk\src\spi\mmp_spi.c
dpf\irphy.c
dpf\irdrv.c
We find a problem in SPI API.......

”

有时候遇到的问题简直百口莫辩。

ACTISYS有个设备叫做IR9200的测试仪，类似压力测试的东西，用来测大量发送数据时的误码率，过红外认证，必须过这么个测试。

大体原理是测试仪对我们发一帧数据，我们必须回复一模一样的帧回去，如此往复。

结果，一开始用EG的芯片可以过测试，而用我们的芯片则不行。

仪器显示我们的芯片会产生CRC 错误。

这下人赃俱获，跑不了了吧。

刚获知这个消息的时候，我一度也怀疑是自己芯片的问题。

结果后来debug后发现问题在于上层调用API的方式，在上层加锁后解决此问题，不然回复数据的时候有时候延时太大。

ITE的人立刻跳出来反对。

“elber你不要捣浆糊，你说是我们调用的问题，如果仅仅是延时了，IR9200也不应该报CRC错误！”

“我的话还没说完，这里面其实是有两个问题，你那边的软件导致回复变慢，IR9200其实也有bug，我接下来会发邮件详细解释这个bug。”

——

“

Dear all,
In our test, we found that every time when the IR9200 show CRC error of the frame sended by DPF,there is a large silence time. That will result in a fail recorded by IR3200.The root cause has ......

”

如此一番折腾，沉冤得雪。