我們公司GSM部門有個雙模智能手機的項目。MTK平臺和EVDO平臺通過USB進行通信。結果在項目測試過程中發現，當MTK做HOST控制EVDO做Device時，HOST控制Device進行suspend和resume狀態切換過程中發現狀態出現故障。即設備進入suspend之後無法被喚醒。剛開始MTK認爲是我們的問題。我們自己驗證發現，該功能沒有問題。於是讓對方換PC做HOST驗證。但是因爲手機終端的特點和PC大不相同。因此MTK認爲無法定位問題在他們。後來我們提供了串口打印設備狀態的接口給他們，發現設備狀態和現象是一致的。
MTK仍然不確信我們的終端驅動沒有問題。本着能定位和解決問題的目的，就專門出差到深圳。經過兩天的聯調測試，終於發現MTK的HOST實現suspend和resume中的remote wake up不符合USB協議規範。在諮詢公司的一位技術專家後，更加確認了。MTK工程師修改了HOST代碼後再次測試，果然發現問題沒有出現了。現在就只需要在MTK的質檢部門經過驗證測試就能最終關閉該問題。經過這個事情後，證明高通的底層驅動還是十分可靠的。
最新更新：
後來測試發現上次修改的辦法似乎還是有點問題。這個時候我已經對HOST端處理USB協議規範性已經產生了懷疑。因此不主張從設備端的代碼來分析問題了，我強烈要求對比USB分析儀日誌，分析正常和異常情況，協議包的差異。可是問題有時候總會朝意料之外發展。分析儀好像無法正常工作了，怎麼都不能抓到所需的數據包。在和MTK工程師郵件交流的過程中，我開始懷疑他們resume信號的時間是否符合規範的要求。MTK工程師後來反饋，他們這個時間是靠硬件來保證的，但似乎太過臨界了。於是他認爲用軟件做了個信號冗餘，從實際效果來看問題概率似乎降到了零。所以這也印證了我的猜想。而高通對該SR的回覆也沒什麼新意，和我的意見一樣，讓我們提供USB協議包。本來我對這一塊並不是很懂的，但這次藉助這個機會把這塊的代碼和基本原理摸了一遍，對自己也是有益無害的。不過這次機會給我最大的鍛鍊是系統分析能力，至少在之前對這塊不是很清楚的情況下能儘快分析出並定位問題。本來之前我對高通驅動部分還是有一絲懷疑的，不過現在我開始相信他們驅動的可靠性了。
