本文轉自公眾號，歡迎關注

基于DWC2的USB驅動開發-高速設備枚舉為全速設備問題案例分析 (qq.com)

一.前言

本文分享一個高速設備被枚舉為全速的問題。

高速設備速度握手參見本系列的文章。

二.問題

我們設計的UVC攝像頭工作在高速模式，接一個第三方的主機用于顯示和無線上傳，主機也支持高速模式。

我們的UVC攝像頭接PC測試都能正常枚舉為高速，從來沒有失敗過。接第三方的主機時總是被枚舉為全速，偶爾能成功一兩次枚舉為高速，幾乎都是枚舉為全速。

三.分析過程

既然接電腦沒問題，接第三方主機有問題，那么就懷疑第三方主機的兼容性問題。先前軟件做了一些分析，調試沒法確認問題，進行了一些打印信息的調試，在中斷中關鍵事件進行打印，發現接入第三方設備時進行了兩次復位和速度握手。這是一個異常信號，正常一次復位和速度握手就能完成。于是使用示波器監控，對比接PC正常的和接第三方設備不正常的復位，速度握手過程。

接PC正常的波形，由于要抓長時間所以圖中高速握手的細節顯示不了了，但是整體依舊可以知道各個階段

接第三方主機不正常的

對比可以看到接PC一次完成高速握手

而接第三方復位了兩次第一次嘗試高速握手主機無響應，第二次沒有嘗試高速握手了，注意這里沒有抓前面初始化過程了。

這里主機第一次沒有響應設備的Chirp K是不對的，這里因為主機是按鍵喚醒的，懷疑是剛上電未就緒，但是主機為什么未就緒就要發送復位呢，應該是USB初始化完后就緒才發復位的，所以這里主機肯定是不對的，而且為什么主機要發兩次復位也不得而知，但是肯定是不正常的，有些第三方的東西做的不健壯也沒辦法，我們現在也沒辦法知道主機的處理邏輯。

既然主機不對，這個先不管，但是為什么設備在第2次復位時沒有發Chirp K進行高速握手了呢。

這要從上一篇說的設備驅動說起。

設備驅動的流程如下

1.初始化配置DevSpd設置期望的工作速度，按照該速度去握手

2.配置EnumDoneMsk使能中斷，清除中斷標志EnumDone

3.等待中斷，中斷中查詢實際握手的速度EnumSpd，根據該速度再次重新配置DevSpd設置實際工作速度。并清除中斷標志EnumDone。

上述的邏輯是用戶可以設置最高期望的工作速度，但是實際主機支持多少就工作在多少，這樣不管主機是什么速度，代碼都不需要修改，初始化指定為高速即可，最終按照實際握手結果而定。

原因就在于上述紅色字體部分，第一次由于主機沒有響應Chirp K所以設備握手結果是全速，所以中斷服務函數中設置為了工作模式為全速，下一次復位時依然會按照全速握手此時就不會發Chirp K了。

即如圖所示

那么是不是可以在復位中斷中重新再配置為高速來達到下一次復位進行高速握手呢，因為復位中斷是在握手完成中斷之前的，這樣是不行的，因為設備檢測到復位進入復位中斷時硬件已經開始進行后續的握手處理了，軟件的修改已經來不及了。此時設備已經是正常的全速工作了，并不知道在何時需要重新設置為高速以等待下一次的復位握手，畢竟這個兩次復位握手不是標準流程，是主機的異常導致的。以上導致了第一次握手為全速之后后面就只能是全速了。

既然如此我們還可以修改中斷服務函數中的處理，不在中斷服務函數中根據前一次握手速度設置實際工作速度，這樣第二次就可以握手為高速了，如下所示

這樣看似解決了問題，但是實際導致了用戶API邏輯問題，原來用戶API初始化設置期望的速度為高速，如果主機不支持高速則握手為全速工作，沒有問題，

現在這種情況如果主機不支持高速，則設備一直工作在高速將沒辦法工作，所以這個修改會導致和其他主機通訊異常，不可取。即改變了原來API的邏輯。

四.解決方法

雖然問題在于主機，但是出于兼容性考慮還是要想解決辦法的，畢竟第三方設備健壯性沒法保證，寫驅動考慮兼容性，甚至兼容非標，非健壯設備也是要考慮的。

所以這里對API接口再增加參數區分，原來的參數還是表示期望速度，但是實際工作速度按照握手結果決定，原來的邏輯不變。再增加一個參數即強制固定速度，也就是如果設置為固定速度則握手完成中斷中不根據握手結果更新速度，設置多少就多少不再改。這樣通過參數來應對原來的用戶邏輯和兼容這個有問題的主機。需要修改的地方是API增加一組強制固定速度和原來的期望速度對應，中斷服務函數中根據是強制速度還是期望速度處理，期望速度就根據握手值更新速度，固定值則不更改。

五.總結

本篇以一個實際的案例進行分析，體現了對USB高速握手過程理解的重要性，所以前一篇高速握手詳解的文章非常重要，在此基礎上才能很快的定位問題。之前一直強調知其然知其所以然很重要，只有深入理解才能快速解決問題。同時也體現了驅動開發比一般嵌入式開發更深入的要求，不僅要考慮正常設備能工作，還要兼容不正常的，不標準的，不健壯的設備，這也需要更深的理解和功力。