基于DWC2的USB驅動開發-數據不能發送問題分析案例

本文轉自公眾號歡迎關注

基于DWC2的USB驅動開發-數據不能發送問題分析案例 (qq.com)

一.前言

對于驅動的開發,調試是一個很痛苦的過程,尤其對于不熟悉的領域，很小的一個問題可能就需要花費大量的時間去調試，甚至以月時間計，甚至可能就解決不了。所以經驗變得很重要，經驗即對相應的IP的熟悉程度，這里的熟悉不是做過，而是分析過調試過。包括遇到過的各種坑，對各種細節的了解，對各種行為的了解，只有遇到足夠多的坑且是實在的去調試分析過的，才可能不斷積累經驗，否則就算做一萬遍也算不上經驗(這也是在嵌入式開發尤其是驅動開發中做過十年的不一定比做過三年的有經驗，做過十年只是改個參數，構建下，跑一下，真算不上任何經驗，而后者如果能從零開始或者真的進行了底層的調試分析那么就是實在的經驗)。DWC2的USB控制器也是一個比較復雜的IP，我們從零開始編寫驅動必然會遇到各種問題，所以這里就會對遇到的各種問題及其分析過程進行記錄，以作為經驗積累，為后續提供checklist。

本篇分析一個IN時數據無法發出的問題。

二.分析過程

問題背景是代碼原本是使用高速傳輸，現在需要支持全速傳輸，所以將DCFG寄存器中速度配置為了全速，但是枚舉失敗。

先確認問題點大致對應的代碼位置，

通過打印確認復位后，全速速度枚舉正常。

所以我們繼續打印中斷信息，以確認更詳細的位置，

可以看出軟件收到了設備描述符請求的8字節內容并進行了解析，

也準備了DMA的描述符以發送18字節的內容。

但是沒有預期的產生IN的XferComplete中斷

于是我們使用分析儀確認總線上的情況

可以看到SETUP之后。主機IN時設備一直是NAK，確實是沒有返回數據

此時我們已經定位到了問題出現在了設備準備了DMA的描述符以返回18字節數據，但是DMA沒有執行，因為沒有產生XferComplete中斷。

以上自然而然我們就要去排查DMA的狀態了，這個時候就需要我們熟悉相關的寄存器了(所以前面專門講寄存器的的內容就派上用場了)。

我們從手冊中看到DMA描述符的第一個WORD以下字段表示DMA狀態

于是我們查看該字段為01即DMA busy

既然DMA的作用是根據DMA描述符從用戶存儲搬運數據到TxFIFO中去，DMA描述符已經準備好了，但是還是DMA busy那么就只能和TxFIFO有關，

猜測就是TxFIFO里沒有足夠 的空間可以滿足本次DMA的搬運。

那么為什么會導致TxFIFO中空間不夠呢，

要不是分配的不夠，要不就是之前里面有數據沒有發送出去，

前者和初始化配置有關，后者和端點狀態是否工作狀態有關。于是分別確認。

先查看端點寄存器狀態

可以看到EPEna為1，USBACtEp為1，

EPEna為1是軟件設置的，硬件的DMA搬運完后自動清零(見前面專門的寄存器講解的文章)，這里沒有搬運完所以一直是1，

USBACtEp為1說明該端點是使能的。

那么排除了端點狀態不對的問題，端點確實是工作的。

那么繼續排查是否TxFIFO緩沖區不夠的問題，

看到TxFIFO的大小配置為了4個WORD即16字節，不足18字節，所以DMA無法一次搬進去。

那么我們是否可以驗證下呢，可以手動改下只發16個字節試一下

此時可以看到，發送了出去，那么確認就是這個原因了。

此時問題就好查了，那么對照下代碼確認應該就是初始化配置時配置的了

代碼如下全速時配置為了包大小為8，且計算TxFIFO時根據雙緩沖，2x8/2=4個WORD和寄存器值一樣。

pep0_in->maxpacket= ((usb_handle -> setspeed& 0x0F) == USB_SPEED_HIGH) ? 64: 8;

那么問題就定位了，但是到此就完了嗎？我們再來回顧下，全速的控制端點也是可以配置最大包大小為8個字節大小的，理論上也應該可以呀?

我們再來看上面的端點0的IN控制寄存器里配置的值

Bit[1:0]為00確是64字節，

再來看代碼

原來是寫死了

所以這個驅動寫的就有問題，應該根據配置參數自動調整而不是寫死。

所以根本原因其實是在這里。

MPS改為8，也是可行的，發送18字節就會拆分為多包發送，這里不再記錄了，可以自行驗證。

以上問題根本點即端點的MPS配置的不對，當然更上一層的根本原因是，TxFIFO的大小不能太小，至于是小于多少呢，小于MPS和發送數據的最小值，因為發送數據可以小于MPS的。于是這里我們又總結出了一個checklist，即FIFO大小不能小于MPS和最小一次發送數據大小的最小值。

三.總結

以上以一個實例進行分析，雖然問題不是復雜的問題，總結一下就是TxFIFO緩沖區不足，使得DMA無法從用戶指定的描述符中指定的存儲區域搬運指定大小數據到TxFIFO，使得DMA一直處于Busy狀態。

但是如果對此不熟則很可能也會耽誤很多時間去分析,以上問題可以總結出checklist以后遇到類似問題可以直接查看，確認排查，這也是經驗積累的過程。對于公司技術的積累也是依賴于此，而不是依賴于人。

主要的是要熟悉整個分析過程，分析思路，對驅動開發這是常態，你將會發現經常改了一點內容可能就有問題，我們一定要找到根本原因，而不是通過修改代碼去回避，這在驅動開發中也是很重要的思想。

以下做一個簡單的方法總結:

1.縮小范圍,定位代碼對應位置,確認問題點,比如上面的定位到問題出現在，準備了IN描述符,但是沒有產生IN的XferComplete中斷之間。一般使用打印，斷點，逐步增刪代碼，二分法增刪代碼邏輯等技術手段進行。

2.定位數據交互在哪里出現問題，比如上面定位到發了請求設備沒有返回數據。一般使用邏輯分析儀，USB分析儀，協議分析軟件等技術手段，配合上述軟件的定位。

3.確認位置后通過狀態寄存器等確認具體的問題，比如上面通過描述符DMA的狀態去判斷。一般需要熟悉IP對應的寄存器，尤其是一些狀態寄存器。

審核編輯 黃宇