一 前言

在高速串行技術如此廣泛應用的今天，簡單易用的USB堪稱是PC平臺上最成功的I/O技術，普及率幾乎100%。而且隨著終端用戶對于高速USB設備應用需求的不斷增加，越來越多的嵌入式通信類終端產(chǎn)品開始增加了USB2.0主機接口的設計以滿足客戶的應用需求。成熟的應用技術由PC平臺轉(zhuǎn)向嵌入式平臺的已經(jīng)成為一種趨勢。為了滿足USB2.0一致性應用的需求，所有的USB2.0設計都必須滿足USB IF發(fā)布的USB2.0物理層一致性測試要求。相對于比較成熟的PC平臺USB2.0 主機測試技術而言，基于通信類終端的嵌入式USB2.0 主機的測試面臨更多的挑戰(zhàn)。特別是進行二次開發(fā)的應用廠商而言，如何滿足USB2.0物理層一致性測試要求很大程度上需要原廠在測試模式以及測試封包方面提供更多的支持。但應用需求的多樣化導致了許多設計架構脫離了原廠的測試狀態(tài)機控制范疇，問題接踵而來。

二 嵌入式USB2.0主機測試

1 產(chǎn)品USB部分原理及測試環(huán)境

產(chǎn)品USB控制原理

USB控制主機采用某大型通訊類方案提供商的IAD解決方案，片內(nèi)集成一個USB2.0控制器，然后通過一個USB HUB中繼對外提供2個高速主機接口。

測試設備：

DUT_USB2.0功能框圖
2 測試中出現(xiàn)的問題

本次測試將主要驗證產(chǎn)品上兩個USB高速主機接口的眼圖。對于USB2.0物理層的眼圖測試，USB IF在USB2.0 SPEC中有著明確的眼圖模板定義如下：

Transmit Waveform. Template

關于USB高速主機眼圖測試的測試方法，USB IF在USB2.0 SPEC中也有清晰的定義，USB2.0主機控制器必須支持規(guī)定的測試模式。對于眼圖的測試則必須支持TEST Packet測試模式，連續(xù)發(fā)送規(guī)范的測試碼流以測定眼圖模板，上升下降時間，傳輸抖動以及其他的一些AC指標。也就是說測試是基于原廠對于測試模式的支持并提供相應的Firmware。準備測試前工程師和原廠溝通后順利拿到了測試Firmware和測試命令。原廠提供的測試方法是在上電啟動之后進入 CFE模式然后下載和運行測試專用Image,這樣就可以使用TEST_Packet命令進行眼圖的測試了。測試連接圖示如下：

測試連接圖

一切看起來都是那么的順利，但是當我們通過串口進行TEST Packet命令下發(fā)之后在兩個主機接口卻看不到信號波形出現(xiàn)。因為是第一次進行嵌入式USB的測試，所以對于出現(xiàn)的問題是沒有任何經(jīng)驗可以參考和借鑒的。從串口信息來看是顯示命令下發(fā)成功的，那問題到底出在哪里呢?只有從信號流向一步一步地查找了。工程師首先測試了USB HUB與CPU之間的UpSTream接口，發(fā)現(xiàn)有相應的信號波形出現(xiàn)。也就是說USB主機控制器已經(jīng)執(zhí)行了TEST Packet命令并發(fā)送了測試碼流,問題出現(xiàn)在了USB Hub這里，它并沒有向兩個Down Stream Facing Port轉(zhuǎn)發(fā)碼流。而且原廠提供的命令也很奇怪，根據(jù)有PC主板測試經(jīng)驗的工程師的意見，對于HUB的測試應該需要指定測試端口才對。而在測試命令中我們并沒有看到相應的指令而只有簡單的TEST Packet命令。在詢問了原廠技術人員后問題有了答案：

(1)原來我們采用的方案只支持一個USB 主機接口，所以在片上只集成一個USB 主機 CONtroller，測試命令也是基于主機控制器類型的。而我們的板級應用是采用了一個USB Hub與主機 Controller中繼來實現(xiàn)多端口應用的擴展，根本無法進行Hub Down Stream Facing Port的測試。

(2)并且原廠的測試是在CFE模式下通過下載運行特定的測試程式來進行測試，在這個階段，并沒有實現(xiàn)USB Hub的初始化以及配置字的操作，也就是說USB Hub是不可控的無法進入測試模式的設定。我們的多USB主機端口的應用設計使得系統(tǒng)架構中加入了USB Hub進行中繼，已經(jīng)超出了原廠設計的USB測試狀態(tài)機控制范疇，導致了無法通過原廠提供的測試命令進行測試。再次和原廠技術支持討論新的測試程式的開發(fā)從時間說來看已經(jīng)不實際了，客戶非常關注并要求我們必須盡快給到USB 主機的測試報告。第一次進行嵌入式USB 主機測試就遇到如此棘手的問題，工程師們一時間束手無策。有沒有另外的方法呢?