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

基于DWC2的USB驅動開發-0x05 DWC2 USB2.0 IP 寄存器介紹 (qq.com)

前言

驅動的編寫無非就是寄存器的配置,所以我們先要對控制器的寄存器現有一個整體的概覽，知道有哪些寄存器，配置某個功能要操作哪些寄存器，寄存器的整體組織架構，等等。現有了整體了解后面具體莫格模塊和功能的配置式就可以找到地方，然后參考具體的寄存器的描述進行配置。

概覽

前面DWC_otg_core架構部分,已經介紹了控制和狀態寄存器CSR的一些內容。從架構的角度看CSR塊位于AHB時鐘域,但是有兩個特殊的，一個是電源和時鐘門控寄存器PCGCCTL和控制器中斷寄存器GINTSTS的b[31:29],這些寄存器位位于BIU從模塊中，在斷電模式下依然處于活動狀態。為什么這兩個不一樣呢? 因為要進行低功耗管理，要對AHB和PHY以及RAM的時鐘進行門控即可關閉和打開，如果位于AHB時鐘域那么關閉AHB時鐘域時這個寄存器本身也就斷電了，也就沒辦法退出斷電模式了，所以這個寄存器必須位于AHB時鐘域以外。GINTSTS的b[31:29] WkUpInt SessReqInt DisConnInt也是類似的原因。

站在USB控制器的角度，對應的是AHB從接口，即外部CPU通過AHB主和控制器的AHB從通訊，讀寫控制器的CSR寄存器，注意控制器本身也是要寫CSR的狀態和中斷相關的寄存器的，因為要設置中斷標志各種狀態等，同時也要讀CSR因為要根據寄存器中的配置決定自己的行為。那么就存在CPU和控制器都同時去寫某些寄存器的可能，主要是中斷相關的，比如控制器要置位某個中斷位，而軟件要去清除某個中斷位，此時控制器的寫是優先的，即控制在寫時軟件的寫會忽略掉，這么做的原因是避免丟失中斷事件。

另外注意所有寄存器都是32位訪問的，哪怕寄存器本身只需要一個字節。由于中斷位的設置和清零分別是控制器和軟件通過AHB接口去訪問的，可能同時寫，所以硬件上做了處理，不同中斷位的寫是完全獨立的，控制器和AHB接口可以同時寫不同的中斷位，這是硬件保證的，而不是我們通常的讀-修改-寫的實現方式就是出于該考慮。如果是寫同樣的中斷位呢，那就是上面說的控制器優先忽略AHB的寫。

為了節省空間，HSOT和DEVICE模式的寄存器是共用物理空間的，因為同一時間要不是主機模式要不是設備模式。另外有些寄存器要根據配置決定是否實現，比如如果只有兩個端點，那么其他端點相關寄存器就沒有實現，但是空間還是占用的，這樣是為了方便代碼兼容，也就是寄存器的偏移地址都是固定的，沒有實現的的就空著。未實現的寄存器寫忽略讀返回值不確定。這里注意只有全局控制, 電源和時鐘門控, Data FIFO 訪問,和 Host Port 寄存器是主機和設備都可以訪問的，其他是模式相關的寄存器。如果主機模式去寫設備相關的寄存器(反之亦然)則會產生GINTSTS.ModeMis事件，該為置位，如果使能了對應中斷還會產生中斷，寫會忽略讀返回值不確定。

如果切換了模式則需要重新編程所有相關寄存器，就好比上電復位之后的狀態一樣。

CSR存儲映射

CSR的地址映射是固定的，不隨著配置改變而改變，即每一個寄存器的偏移是固定的，前面已經解釋過了原因。主機和設備模式寄存器占用不同的地址。

整個寄存器的空間如下所示

閱讀寄存器有一些經驗，

G開頭的代表全局控制寄存器

H開頭的代表主機相關寄存器

D開頭的代表設備相關寄存器

這樣一眼就可以看到寄存器大概是和什么相關的。

Controller Global CSRs (1 KB)部分:主機和設備模式都可以訪問

Host Mode CSRs (1 KB):進入主機模式需要配置的寄存器

Device Mode CSRs (1.5 KB):進入設備模式需要配置的寄存器

Power and Clock Gating CSRs (0.5 KB):實際只有一個寄存器，電源和門控配置，主機和設備模式都可以訪問。

Device EP x/Host Channel x FIFO (4 KB):這些寄存器在主機和設備模式下都可用，用于在給定方向上讀取或寫入特定端點或通道的FIFO空間。在主機通道IN端點則FIFO只讀，OUT端點則FIFO只寫，在設備IN端點則FIFO只寫，OUT端點則FIFO只讀，注意這里的IN和OUT是符合USB規范的IN和OUT即都是針對主機而言的。

Direct Access to Data FIFO RAM for Debugging (128 KB):直接訪問該空間可以查看RAM中數據用于調試使用。

中斷相關寄存器架構

中斷相關寄存器非常重要，可以說USB的驅動就是基于中斷的驅動，所有流都是中斷去驅動的，當然也有所謂的基于事件的驅動比如uC-USB實際也是在中斷服務函數中發送信號量或者事件，在某個線程中或者主循環中去處理事件，本質還是一樣的，還是基于中斷的。中斷中根據狀態決定下一步要做什么。

對應中斷狀態寄存器GINTSTS，中斷是一個分層的結構，即總分的形式，先整體有總的中斷狀態，比如是設備IN還是OUT端點中斷，是主機Port還是通道相關中斷，是OTG的中斷，還是內核相關的中斷。比如如果知道是設別IN或者OUT中斷則往下走一層看是DAINT是哪一個IN端點或者哪一個OUT端點的中斷，找到了然后再往下走一層查看具體的DIEPINTi或者DOEPINTi已確認更詳細的中斷信息。

還有就是編程上需要注意使能中斷時一定要先清除中斷標志再使能中斷，避免一使能中斷標志就是置位的馬上就產生中斷，這也是驅動開發的常識。

中斷架構還支持多處理器模式，即可以將中斷信號分發到不同的處理器，以配合多處理器系統使用。支持多處理器中斷模式時就是多了包含EACH字樣的寄存器，供各自處理器使用對應的中斷寄存器。

中斷的處理如下，即和上面提到的層次結構對應

1. 先看GINGSTS總中斷狀態，處理全局的中斷
2. 然后看主機或者設備通道或者端點相關中斷狀態 比如看DAINT
3. 最后看具體是哪一個端點或者通道比如看DIEPINTi,DOEPINTi。

主要使用的寄存器

這里先對一些高頻使用的寄存器做簡單介紹，介紹其對應的功能，詳細的可以再參考具體的寄存器描述。這樣先從整體有一個了解。

寄存器描述

閱讀寄存器要注意下寄存器的屬性

寄存器組織

寄存器按塊組織

DWC_otg_map/DWC_otg_intreg

所有寄存器如下

可以看到就是分為G開頭，H開頭和D開頭的。

總結

本文對控制器的寄存器有了一個整體上的概覽，先了解各大概，了解寄存器的組織結構，大致了解一下常用的寄存器。后面編程時再一個個對照每一個寄存器的描述去編寫代碼。