我們公司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協議包。本來我對這一塊並不是很懂的，但這次藉助這個機會把這塊的程式碼和基本原理摸了一遍，對自己也是有益無害的。不過這次機會給我最大的鍛鍊是系統分析能力，至少在之前對這塊不是很清楚的情況下能儘快分析出並定位問題。本來之前我對高通驅動部分還是有一絲懷疑的，不過現在我開始相信他們驅動的可靠性了。