上周陸續(xù)接收到一小批量客戶返回的“不合格”產(chǎn)品，回來一測試，主要是兩個問題：一是液晶屏漏液，通常這是由于液晶屏表面被外物碰撞或擠壓造成的，可能是運輸流通環(huán)節(jié)造成的，也可能是用戶使用裝配過程不規(guī)范導致的；最棘手的是另一個問題，用戶提供樣機對其（我們的模塊）做測試，發(fā)現(xiàn)常常出現(xiàn)用戶的第一幅上電開機界面無法正常顯示，本來白色的背景頻繁出現(xiàn)花屏（清屏指令丟失）。
在生產(chǎn)階段，已經(jīng)遇到過類似問題，當時斷定是采購的晶振批次有這樣的問題，已經(jīng)更換了檢驗和老化階段出現(xiàn)問題產(chǎn)品的晶振（其他品牌優(yōu)質(zhì)晶振）。但沒想到的是，整個批次到用戶手中再返回來竟然還有一批這樣的產(chǎn)品。細細想想，一點不稀奇，斬草不除根怎么行，生產(chǎn)階段就應該果斷的將整個批次晶振更換掉。
由于和對方是第一次合作，并且這批產(chǎn)品是用戶的替代產(chǎn)品，所以Y總也很重視。周四下午和Y總驅車趕往用戶現(xiàn)場，這一去不要緊，對方公司什么技術、采購、主管、副總、老總挨個出場，那個老總脾氣火爆，直接當著我們的面劈頭蓋臉口沫橫飛，場面很是尷尬。Y總畢竟是過來人，什么人什么場面沒見識過，心態(tài)也很是平和，沒有硬碰硬，當場檢驗剩下的產(chǎn)品后，坐下來和對方老總好好的溝通了一番，最終雙方都表示應該相互理解，在磨合期相關應該多一些信任和支持。
工程師故事，晶振引發(fā)的系列血案" height="304" src="http://files.chinaaet.com/images/20110727/4493cad0-7ca9-47a3-81e9-22a4a1b3ac3a.jpg" width="421" />
作為技術方面的主要責任人，當晚我好好的做了一番檢討，對整個流程的各個環(huán)節(jié)作了一些檢視。周五整個對能夠召回的產(chǎn)品更換了晶振，但是測試基本沒出現(xiàn)什么異常，只是個別有些不一樣的狀況出現(xiàn)，以為是一類問題，沒太留心，更換晶振了事。
上周陸續(xù)接收到一小批量客戶返回的“不合格”產(chǎn)品，回來一測試，主要是兩個問題：一是液晶屏漏液，通常這是由于液晶屏表面被外物碰撞或擠壓造成的，可能是運輸流通環(huán)節(jié)造成的，也可能是用戶使用裝配過程不規(guī)范導致的；最棘手的是另一個問題，用戶提供樣機對其（我們的模塊）做測試，發(fā)現(xiàn)常常出現(xiàn)用戶的第一幅上電開機界面無法正常顯示，本來白色的背景頻繁出現(xiàn)花屏（清屏指令丟失）。
在生產(chǎn)階段，已經(jīng)遇到過類似問題，當時斷定是采購的晶振批次有這樣的問題，已經(jīng)更換了檢驗和老化階段出現(xiàn)問題產(chǎn)品的晶振（其他品牌優(yōu)質(zhì)晶振）。但沒想到的是，整個批次到用戶手中再返回來竟然還有一批這樣的產(chǎn)品。細細想想，一點不稀奇，斬草不除根怎么行，生產(chǎn)階段就應該果斷的將整個批次晶振更換掉。
由于和對方是第一次合作，并且這批產(chǎn)品是用戶的替代產(chǎn)品，所以Y總也很重視。周四下午和Y總驅車趕往用戶現(xiàn)場，這一去不要緊，對方公司什么技術、采購、主管、副總、老總挨個出場，那個老總脾氣火爆，直接當著我們的面劈頭蓋臉口沫橫飛，場面很是尷尬。Y總畢竟是過來人，什么人什么場面沒見識過，心態(tài)也很是平和，沒有硬碰硬，當場檢驗剩下的產(chǎn)品后，坐下來和對方老總好好的溝通了一番，最終雙方都表示應該相互理解，在磨合期相關應該多一些信任和支持。
作為技術方面的主要責任人，當晚我好好的做了一番檢討，對整個流程的各個環(huán)節(jié)作了一些檢視。周五整個對能夠召回的產(chǎn)品更換了晶振，但是測試基本沒出現(xiàn)什么異常，只是個別有些不一樣的狀況出現(xiàn)，以為是一類問題，沒太留心，更換晶振了事。
周一準備發(fā)貨前再做了一次檢驗，這一查不要緊，整個批次還是存在問題。第一次出現(xiàn)的狀況歸咎于那個批次的晶振起振偏慢，只是影響到用戶的頭幾條指令的鎖存，不會對后續(xù)顯示造成影響。但是，一早發(fā)現(xiàn)的狀況用晶振的起振偏慢卻怎么也解釋不了。因為通常我們推斷用戶送背景色后馬上送清屏指令，如果起振偏慢則整個清屏沒實現(xiàn)屬于正常現(xiàn)象；而這回卻是整個背景黑屏（正常應該為白色背景），黑色就想到背景色初始化時就是黑色，估計是清屏指令送到了，而前面一條背景色指令沒送到位，做了一個測試，使用其他顏色作為初始化驗證了這個假設是成立的。于是一下午加晚上苦心思索驗證，最終解決了問題，這個不僅僅與內(nèi)部代碼的健壯性不夠有關，更是與兩個系統(tǒng)模塊之間上電先后息息相關。
用戶是ARM系統(tǒng)，這邊是CPLD系統(tǒng)，兩邊通過一組準8080并口總線通信。由于本身這是一個替代項目，所以我這邊的CPLD系統(tǒng)處于很被動的地位，必須完全就著用戶ARM系統(tǒng)的脾性來設計。其實一開始的晶振起振偏慢問題完全可以在不更換器件的情況下解決，用戶只要在上電后多做些延時再發(fā)指令即可，但是這個問題到工程師處好解決，那些不懂技術又坐高位的人不這么看，所以我們只好把苦水咽下肚子統(tǒng)統(tǒng)算自己的錯。
而這次出現(xiàn)的問題，顯然不是晶振起振快慢的事，而是兩個系統(tǒng)誰先起來的事情，因此我也一直糾結在CPLD系統(tǒng)這邊的復位快慢問題。說實話，很難把握好，復位若是晚了，和晶振起振偏慢是一回事；復位快了，就出現(xiàn)新的癥狀，那組并口總線上的信號在復位前會是一組不確定的狀態(tài)。此時如果CPLD內(nèi)鎖存這組信號的邏輯（通常可能會用到狀態(tài)機等進行設計）不夠健壯，那么出現(xiàn)異常再所難免，就像特權同學的第一條指令偶爾丟失（100次開機會出現(xiàn)2-4次通常）現(xiàn)象。
對于新開發(fā)的項目，這些問題都是很好解決的，在雙方的聯(lián)調(diào)過程中相互協(xié)調(diào)和改進很容易就可以避免這些系統(tǒng)上電快慢導致的癥狀。但對于某一方不可更改的情況這就有些困難了，在CPLD系統(tǒng)上必須有足夠的出錯容忍機制和可靠健壯的代碼邏輯來保證系統(tǒng)的穩(wěn)定。