一位研发客初做项目的感概，然我们共同回忆一下当初做项目的的苦涩与收获吧！
经过一个多月的紧急备战，X1的EVT经历诸多磨难之后终于在9月底进行。
由于客户要在10月3号看DEMO，在这仅有的三、四天内把所有的功能调好对于任何一个公司都是来说都是一个挑战，更别说我们这一帮都是刚毕业的从未做过手机的菜鸟了。
由于时间紧急，尽可能的压缩路上的时间。本次出差特许我们乘坐飞机，以前也只是在电视上了解到乘坐飞机有漂亮的空姐，高档的服务，地球上的美景尽收眼底，想想这些心里还是有点小激动呢。
9月24号，终于踏上了惠州旅程。在去往机场的路上，HL和我聊天说，你认为飞机上空姐长什么样子？我说不就和电视上一样，漂亮，有气质。他说，我提醒你一句，不要抱太大希望。踏上飞机，机舱门口两个空姐来了一句“欢迎乘坐南方航空”。盯着空姐看了看，幸亏HL提前给我打了预防针。顿时感觉这个世界充满了欺骗。
在飞机上却无心赏景，虽然提前做足了充分的准备，把自己能想到的问题都排查了一遍，但是心里时不时想起"如果去了惠州不能Download，开不了机怎么办？这个项目千万不能砸在自己的手中。"就这样自己又把可能预见的问题在大脑重新过了一遍。就这么会儿功夫，我们已经抵达深圳。
下午3点多，我们抵达惠州，安排了住宿之后，到办公室和惠州的同事闲聊之中，他们提醒了我们”晚上千万不要单独出去！“难道这里闹鬼不成？”闹鬼倒不至于，但是这里不安全。接下来，他给我们讲了近期发生的几个案例。心想：“这是什么破地方，在来的路上都感觉怪怪的，怎么越走越偏，我们还以为司机走错路了呢”趁着天还没黑，我们几个出去吃了饭，顺便熟悉一下周边环境。走出公司，发现这里的街上人非常少，公司路边排了一排摩的，没有公交车，更没有出租车。公司员工出行只能靠黑摩的，但是公司同事又说外面的摩的不安全，外地人不要乘坐。本来打算出差期间还可以出去玩玩，看来计划又要泡汤了。
来惠州已经两三天了，因为物料一直没有备齐，物料一直压在海关没有放行，EVT打件一再推迟，但是客户DEMO时间又不能耽误。这样留给我们调试的时间就更少了。26号除PCB外其余物料都已就绪，在27号下午终于盼来了好消息，物料海关在晚上会放行，大概28号凌晨2点到公司。可是谁去取物料呢，惠州公司没有夜班，只能我们自己取。可是这里不安全，大家商量了下，晚上我们一起去。我们5个走到送PCBA的师傅那，他一愣，说你们取个物料至于来这么多人，知道的你们是取东西的，不知道的还以为你们打劫的呢。我们只是笑了笑，什么也没说。28号下午在急切的盼望下，第一版PCMA终于诞生了。立马焊线上电Download，看着工具弹出OK，心里终于松了一口气。紧接着就是验证开机了，由于没有LCM，不能直观的判断，只能从开机电流来判断。HW工程师验证后，说应该开机了。我们的神经终于又放松了一下。正当我们认为没有什么大的问题的时候，我们插上USB线，发现主板重启了，一开始还以为是偶然现象。在做了多次试验之后，确定这不是偶然，而是必然，一下子大家的神经又紧绷了起来，大家都束手无策。这时已经快6点，我们计划今天由HW一位工程师先带第一版回郑州，我留在明天上午再带几版回去，现在没有时间来分析重启的原因。晚上回到宿舍却无心睡眠，心里一直在想导致重启的原因，注定又是一个不眠的夜晚。
29号一大早就赶到了机场，在机场等机时，突然想起在来惠州前曾向NJ同事请教过EVT的排查要点，其中有一项就是需要屏蔽电池检测。但是因为我当时在其他手机上做过实验，用电源供电也能开机，我却忽略了插上USB的情况。而现在的情况也是能开机，但插USB就重启，会不会就是因为没有屏蔽电池检测导致的呢?立刻给郑州的同事打电话，在电池温度PIN与GND之间焊接10K电阻看还会不会重启。
又踏上了回去旅程，与来的时间不同。这次感觉时间过得好慢好慢，恨不得自己飞过去。下了飞机，第一时间打电话问实验结果，得到一个令人兴奋的消息“不再重启了”。
下午开始调试LCM，心想这个应该不会有什么问题。前期最害怕TP和LCM出问题，这块Review了一遍又一遍。但是上天总喜欢捉弄人，LCM接上之后只有背光会亮，LCM显示白屏，瞬间我们都蒙了。大家都开始检查参数配置，联系厂商，向有经验的同事请教，总之使用浑身解数。晚上折腾到11点，仍没有任何进展。这时去天津调试TP的LD已经到达TP厂，那边的结果也不容乐观，TP没有反应。这真是祸不单行，原以为很有把握的两个模块都出了问题，而且都还不是小问题。
晚上回到宿舍，LD的电话一个接一个，我们开始远程沟通调试，逐步排查问题。最后发现TP没有上电，我们尝试用外接电源给TP供电，但是仍没有反应。由于那边没有源码，条件有限，一时间也找不到更好的解决办法。就这样大家把能想到的问题点都逐一尝试、验证。直到凌晨4点，问题仍未解决。感动的话就不多说，说出来感觉太轻太轻。
首要任务仍然解决LCM问题，这个如果搞不定，3号的DEMO就无法交货。一大早就来到了公司，开始了忙碌的工作。又是量供电，量波形，检查Code。排查了诸多原因之后，在MTK工程师那了解到好像我们的GPIO配置与MTK说的DBI口的GPIO配置不同。尝试修改GPIO配置，重新Download，屏幕终于显示了LOGO。大家都又长舒一口气。
LCM已经OK，还有TP不能Work。此时我们至少知道了问题所在--TP没上电。于是重点解决上电问题，在查阅了很多资料后，发现PMIC在切换电平前必须先下电才能将新的电上上去。问题可能就出在这个地方，很有可能这个管脚在其他地方也上过电，而我们程序中又没有做下电操作，可能导致上电异常。修改Code后重新量测TP供电，一切正常。
写在最后，经历了这个项目，兄弟们都付出了很多很多，能在这么短的时间内把功能调通真的很不容易。虽然中间出了一些差错，这都是我们成长所必须经历的。调试的过程写的很简短，但这个过程却很漫长。送给新来的学弟学妹：不要担心自己做不了项目，勇敢的冲吧。一开始老大说刚毕业的都可以做手机项目，连我们自己都不相信。现在我无话可说，兄弟们都做到了。相信后面我们会做的更好！
说句老实话，XD1项目是我做的第一个项目，也算是完成了做项目处女之旅。通过这个项目，自身完成了从一个门外汉到入门级的转变。之前忙活了好几个月做的demo，跟这十月份一个遇到的学到的，简直是小巫见大巫。
然而，这里边有个集万千光环为一体的问题——它最令人难忘的问题，最古怪的问题，也是耗费了我们最大精力的问题，最终证明不是我们问题的问题——非常值得写出来跟小伙伴们分享一下：
在我们拿到codebase，拿到板子，点亮了屏幕，使手机能够坚持开机几分钟后，就开始搞camera了。正常情况下，只要把从MTK那里拿来的camerasensor驱动放入工程，编译，刷机，就可以看到图像了。可是这次我们遇到特别诡异的现象，后置camera，一下就点亮了；转到前置——要么卡，要么黑屏。
怎么回事？？
赶紧看上电函数，查了一整天，更换上电时序，增加延时，删了main只上sub，种种方法试了个遍，现象依然，没有改变，找不出问题。
看i2c。
sensor的i2c正常吗？有信号，看起来没问题。要不然，根本找不到sensor；而且那条i2c bus总线上，挂载的后置camera跑的很好。而且，前置camera驱动也在跑。为什么不出图？驱动也在跑。为什么不出图？莫不是跟数据传输有关？会不会是新加的mipi_switch问题？它干扰了sensor数据的传输？找硬件，看原理图，做跳线，绕过mipi switch，直接连sensor和AP。再看——还是没图像。测量sensor的外部输入pllmclk，有波形，正常。抓mipi波形，有，但是振幅不太正常。
怎么办？会不会是sensor的问题？传输数据的电流驱动力不够？找sensor厂商。厂商说，根据以往经验，先降了mclk的频率，从24M降到13M。试一下，有变化！！从黑屏到花屏啦！偶尔还能看到模糊的人影。
会不会真的是mclk频率太高？mipi传的数据太多？导致信息丢失。mipi的设计最高频率是1.5G HZ，现在只是400MHZ，不该出现这个问题。
找MTK，拉三方会议，大家一块儿查。啊！这个突然发现了一个问题——驱动用的老版本，不是最新的！要找到原因啦！或许就是这个问题！怎么能这么粗心！赶紧拿最新的！新的驱动code从MTK拿来，放进去————现状依然~~这鬼现象，当真令人喷口老血！！
再查！
抓mipi波形图，从clk，和data0，data1，挨个抓。抓完了，送给MTK和sensor厂来分析。sensor厂这时说：振幅不太够，给你们两个寄存器地址，往里边写数据，可以增加mipi振幅。——好，试一下！简直有种病急乱投医的感觉。可是没办法，现在，任何一个解决方式都要尝试，都是救命稻草啊~~
这时，MTK说，我瞧着，这个mipi的波形，偏离不太正常。基准电压不是0啊。
我们这时看了看，嗯，确实有这个问题。但是波形振幅不对，先查这个吧。
这时，时间已经拖的太久了，已经四五天没有结果，大家都等不及了。人人都要出一份力的时候到了。Layout说，我们去查下前置camera的布线图；硬件说，我们再去测一遍电压，和正常main相比看一下差异。
当天晚上，结果出来啦！
mipi的引脚地线没有和公共地连接。。。。
怎么会这样~~
Mipi是高速公路，没了地线，相当于地基不好的路，坑坑洼洼。跑得快了，肯定颠的人多没影了，还怎么通。降了速，反而能跑过去一小部分。
这个问题，最终竟然是这样！在我们经历了一路的惊喜&惊悲之后，原来问题竟是这样。没有连线，这不是个大问题。只要看到图，稍微一查，就可以发现。
可是为什么花了这么多天才发现？
曾听过一句话，大意是说，在我们确定了一部分假设没有问题的时候，去查了剩下所有有问题的部分，发现这部分依然没有问题——那么，就是我们的假设不对！
我们在查了自己所有能改的问题之后，还是没有发现rootcause。我们在自证清白，最终罪魁祸首出来自首，问题解决，我们自己才算干净。这中间耗费了太多的精力。
为什么会花了这么久？
1、我们的经验还是不够，在查看mipi传输的波形时，没有及时发现到不正常的地方。
2、做项目，是一个相互协作的工作。没有在第一时间把问题相关的人员全部集合起来共同努力。3、我们做了错误的假设。老大常说，做MTK方案，就是在正常跑通的项目上，改改硬件。我们拿到相应的code base，针对硬件修改做相应的coding。然而，这次的问题，确实出在了硬件设计之后的lay 板子上。
我们常说我们做项目是三方：MTK，厂商，我们自己。
但是经历过这次后，发现：我们不仅有三方。MTK，厂商，对应都是我们BSP这块儿。在我们内部，还有BB，layout等。我们要协调的是四方，五方。
经过这次战役，深深感觉，自己在本身的BSP工作还有很多要学。要学习技术知识，还在学习项目中做事的一些关键点：及时保持code和MTK一致，最新；正确记录自己对code的修改和patch版本；分条理搞清楚手机中镜像是哪个版本。
路漫漫其修远兮，吾将上下而求索。
联系客服
