本文轉自公眾號歡迎關注

基于DWC2的USB驅動開發(fā)-USB復位詳解 (qq.com)

一.前言

上一篇我們詳細介紹了USB枚舉的第一步,連接檢測。那么第二步是干什么呢? 相信做過嵌入式開發(fā)尤其做過驅動開發(fā)的都會想到-復位，基本上所有的外設模塊在開始都需要進行復位操作，以達到一個默認的狀態(tài)，USB也不例外。一方面初始化時復位以達到默認狀態(tài)，一方面在異常時復位以恢復。話說復位可以解決99%的問題就是這么來的，如果還不能解決那就斷電復位，相信這是很多人解決問題的第一板斧，且不說是不是最優(yōu)選擇，至少這樣一般都有效，當然可靠性考慮是否能直接復位一般都需要評估不能這么直接簡單粗暴。

這一篇我們就來詳細講講USB的復位，老規(guī)矩理論結合實踐，先看規(guī)格書的說明再寫驅動實測。

二．USB的復位

2.1復位信號

首先，復位信號到底是什么樣的呢？調試外設時序的時候一般都會關注，復位一般用一組特殊的狀態(tài)時序來表示，USB也一樣。

我們看到USB2.0規(guī)格書中對復位信號的描述如下

對于發(fā)送端要求D+和D-小于VOL(max)持續(xù)10mS以上，VOL(max)的值為0.3V，如下

而對于接收端要求D+和D-小于VIL(max)持續(xù)10mS以上，VIL(max)值為0.8V

可以看到VIL(max)比VOL(max)是要大的，這是對發(fā)送要求嚴格一些，因為要考慮信號傳輸?shù)脑肼暩蓴_等因素，預留一些裕度。

上述10ms的參數(shù)實際有個名字叫(TDRST)，規(guī)格書中要求如下

而一般要求接收端在D+和D-小于VIL(max)持續(xù)2.5uS以上就應該檢測到復位，這個時間記住，我們可能會遇到臨界情況在這個值附近可能出現(xiàn)不穩(wěn)定的情況，調試時留個心眼，一旦出現(xiàn)這種很可能就是疑難雜癥，但是現(xiàn)在留個心眼以后就可能想起來確認這里。

對于根集線器這里還有個要求就是非連續(xù)的復位要有3mS以上的間隔(TRHRSI)，復位持續(xù)周期50mS(TDRSTR)以上(因為USB拓撲最大有5個集線器)

2.2復位過程

參考USB2.0的規(guī)格書《7.1.7.5 Reset Signaling》

在低速/全速模式下運行的設備，如果其面向上游的端口上出現(xiàn)SE0超過2.5μs（TDETRST），則可以將該信號視為復位信號。復位須在復位信號結束之前生效。注意這里是復位信號結束之前就生效。（實際這里還可能導致隱蔽的BUG，我這里有一個精彩的案例分析，高速設備總是枚舉為全速設備的問題，神奇的是在復位中段服務函數(shù)中加個打印就好了，后面會分享）

1.主機(HUB)檢測到設備連接,通過DP還是DM拉高區(qū)分是低速還是全速/高速。

2.主機(HUB驅動信號SE0以產(chǎn)生復位信號。

3.設備檢測到SE0持續(xù)2.5uS(TFILTSE0)以上檢測到復位，產(chǎn)生復位中斷。

對于低速設備完成復位，對于全速和高速設備后面繼續(xù)進行高速設備的檢測。

速度的檢測后面會單獨再講。

如果是從non-suspended全速狀態(tài)復位則必須在SE0

開始后的2.5uS(TFILTSE0)~3.0 ms(TWTRSTFS)時間內(nèi)進行后續(xù)的高速速度檢測握手。

如果是從suspend狀態(tài)復位，則必須在SE0開始后的2.5uS(TFILTSE0)以上時間后進行高速速度檢測握手，為什么這里沒有最長時間3.0 ms(TWTRSTFS)的限制了呢，因為掛起時時鐘是停止的重啟時鐘需要時間，所以這里不限制上限時間。

如果是從non-suspended高速狀態(tài)復位，則設備在恢復到全速之前必須等待不少于3.0ms且不多于3.125ms（TWTREV）。通過移除高速端接電阻并重新連接D+上拉電阻器，可實現(xiàn)全速恢復。該設備對總線狀態(tài)進行采樣，并在開始恢復至全速后檢查SE0（復位而非掛起）、不小于100μs且不大于875μs（TWTRSTHS）。如果檢測到SE0（復位），則設備開始高速檢測握手。

注意

設備必須能夠在復位恢復時間10 ms（TRSTRCY）后接受SetAddress（）請求，這個時間也是一個調試經(jīng)驗，如果不能枚舉可以檢查設備的響應時間是否過長。

由于面向下游的端口在復位期間不會處于傳輸狀態(tài)，因此高速Chirp信號不會引發(fā)斷開連接檢測。

如下圖是DWC2驅動的復位波形，黃色為DP，高速模式。

通過仿真器GDB load程序重新運行，而不是直接上電運行，如果是后者則沒有(1)這個狀態(tài)此時默認是沒有拉高的。

DWC2控制器的軟件復位不會影響SftDiscon位的狀態(tài)，所以load程序后SftDiscon保持之前的拉高狀態(tài)，DWC2控制器復位也不會影響

直到相關UTMI時鐘復位，如下代碼執(zhí)行對應到(2)前面的DP拉低,此時UTMI等復位應該是導致了PHY的相關狀態(tài)復位。

然后是軟件設置SftDiscon位為0，拉高DP，如下代碼處，對應(2)處的拉高

然后DP拉高100mS之后(3)，主機發(fā)送復位(4)，這里看到復位時間非常短，這是因為設備2.5uS以上，實際是8uS就檢測到了復位(如下圖所示,圖中標尺部分，后面的藍色的高DM的高是設備發(fā)出的Chirp K高速握手信號)，進行了后續(xù)的高速握手，所以覆蓋了主機發(fā)送的復位信號，所以看不到復位10mS的持續(xù)時間。

三.總結

復位的信號很簡單，但是承接的是連接檢測到后續(xù)的高速速度握手，時序非常重要，尤其是有個參數(shù)2.5uS，檢測到復位信號持續(xù)2.5uS即檢測到復位，而不需要等復位信號移除即不需要等10mS，所以會出現(xiàn)主機在驅動復位，設備已經(jīng)檢測到復位開始后續(xù)的高速握手，從波形上看就看不到復位信號持續(xù)10mS了，而這也可能導致一些性能不達標的主機，高速握手失敗，這個后面單獨講案例分析。