USB Mass Storage大容量存儲的基本知識

http://www.crifan.com/files/doc/docbook/usb_disk_driver/release/htmls/ch02_msc_basic.html

USB Mass Storage Framework

PC電腦和U盤之間的關系，以及物理上的組成，可以用下圖表示 

更深入的剖析，對於普通U盤的內部結構，則是一個USB物理接口，

加上對應的控制芯片（微控制器（含Nand Flash的控制器）+ USB設備控制器）和一個Nand Flash芯片：

PC和U盤的內部邏輯框圖

PC和U盤的之間的抽象的邏輯關系，可用下圖來表示：

 

USB MSC設備中的固件（firmware）或者硬件（hardware），必須要實現下面這些功能：

1. 檢測和響應通用的USB Request和USB總線上的事件。
2. 檢測和響應來自USB設備的關於信息或者動作的USB Mass Storage Request。
3. 檢測和響應，從USB Transfer中獲得的SCSI Command。這些業界標准的命令，
   是用來獲得狀態信息，控制設備操作，向存儲介質塊中讀取（read block）和寫入（write block）數據的。

另外，設備如果想要向存儲介質中，創建/讀取/寫入，文件/文件夾的話，
那么就涉及到文件系統，還要實現對應的文件系統。嵌入式系統中常見的文件系統有FAT16或FAT32。

對於這些協議，我們一個個的簡單解釋和分析一下：

2.1.1.1. USB MSC Control/Bulk/Interrupt (CBI) Transport

我們所關注的U盤，就是所謂的MSC設備，大容量存儲設備。

U盤的功能，就是數據存儲。而對應的數據傳輸，用的是USB中的Bulk Transfer。
而Control Transfer是用來發送Class-Specific的信息和Clear Stall。
而其他方面的信息交換，是用Bulk-only協議。

而對於CBI，算是Bulk-only的替代品，也可以用來信息交換，
但是只能用於，full-speed的軟盤（Floppy drive），也不推薦將CBI用於其它新出的MSC設備上。

【總結】

USB MSC Control/Bulk/Interrupt (CBI) 主要用於Floppy設備，對於我們關心的U盤，用不到，不需要太關心，可以忽略之。

2.1.1.2. USB MSC Bulk-Only (BBB) Transport

如上所述，Bulk-only是USB設備端，此處的U盤和USB Host端，即普通PC，之間信息交換的協議。

Bulk Only Transport，也被簡稱為BOT。

2.1.1.2.1. 為何USB MSC中Bulk-only Transport被叫做 BBB

USB MSC中的Bulk-Only 常被叫做BBB，是相對於前面所說的CBI來說的。

看起來，USB MSC的CBI，是Control/Bulk/Interrupt的簡寫，但是其具體含義是：

1. Control

   Control端點用於，除了傳送標准的USB請求之外，還用於通過Class-specific的請求，
   將命令塊（command block）傳給設備；即Control端點傳送命令塊

2. Bulk

   Bulk In和Bulk Out端點用於在主機（Host）和設備（Device）之間數據的傳輸。
   即Bulk用於傳送數據

3. Interrupt

   Interrupt端點用於（設備向主機）通知命令完成。即Interrupt用於傳送狀態信息

因此，上面的USB MSC的Control/Bulk/Interrupt，才被簡稱為CBI。

和CBI中的用三種不同的端點來傳送三種類型的信息，而不同的是，
Bulk-only傳送這些全部的信息，都之用Bulk端點。

即用Bulk端點來傳送命令塊，數據，狀態，因此，
才類似於Control/Bulk/Interrupt被簡稱為CBI一樣，而Bulk/Bulk/Bulk被簡稱為BBB。 

【總結】

USB MSC傳輸協議分CBI和BOT，而BOT又稱為BBB。

2.1.1.2.2. 為何已經有了CBI，又再弄出個BBB

既然，對於USB MSC設備來說，USB設備和USB主機之間的通信，
已經定義了一個CBI規范，那么為何還要再新定義一個Bulk-only（BBB）呢？

我的理解是，那是因為，最開始USB協議定義的時候，那時候市場上的Floppy Disk還是用的很多的。

所以針對Floppy設備特點，分別定義了多個端點來傳輸不同的信息，
即Control端點傳命令塊，Bulk傳數據，Interrupt傳狀態信息，

而后來計算機行業的發展了，Floppy類的設置很少用了，存儲數據的話，
多數開始用Flash Memory了，再加上通過合理規划，
可以用同一種端點，即Bulk端點，傳輸上述三種信息，即命令塊，數據，狀態，

因此，只需要物理上實現一個Bulk端點，節省掉了其他兩個端點：
Control端點和Interrupt端點，達到了物理上實現起來方便和節省資源，
而達到同樣的信息傳輸的目的。此部分理解，有待進一步考證。 

【總結】

USB MSC Bulk-Only (BBB) 協議，是我們要重點關注的對象。
因為我們的U盤和USB主機（PC端）直接信息交互，主要是用此協議。

2.1.1.3. USB MSC UFI Command Specification

UFI，即Universal Floppy Interface，因此看名字就知道，是關於軟盤的。

此USB MSC UFI規范，定義了UFI命令集合（Command Set），設計出來此規范，
就是用於軟盤的。此UFI命令集合，是基於SCSI-2 和SFF-8070i命令集合的。

 

【總結】

看完上面的解釋，就明白了，我們此處關心的是U盤，
是USB Flash Memory類型的，不是Floppy Disk類型的，所以，此處也可以不關心，暫忽略之。

2.1.1.4. USB MSC Bootability Specification

目前常見的電腦啟動，很多都是從MSC大容量存儲設備中啟動的，比如硬盤。

因此，設計了這個規范，以使得操作系統可以從USB MSC設備上啟動。
關於此規范的具體內容，主要是定義了一些命令和相關的一些數據的定義。

即，如果你想要實現讓操作系統從你的這個MSC設備啟動，
那么你就要實現對應的CDB（Command Descriptor Block，命令描述符塊）或者Data數據。

 

【總結】

我們主要關心U盤如何和主機數據交互，暫不關心是否能否從此U盤啟動，所以也可不太關心，暫忽略之。

2.1.1.5. USB MSC Compliance Test Specification

 

【總結】

無須多解釋，看名字就知道，是一個關於兼容性測試的規范，
和我們此處所關心的U盤和主機的數據交互，關系不大，暫忽略之。

2.1.1.6. USB Lockable Storage Devices Feature Specification

“Lockable Storage Devices Feature Specification”，簡稱為 LSD FS。

“Lockable”的意思是，可鎖定，即鎖定以防止其他人訪問或者寫入，即變成只讀，甚至不允許其他人再訪問。

說白了就是對USB存儲設備的安全控制方面的規范。

而基於目前還沒有一個標准的規范去定義，如何去控制那些對於USB存儲設備的訪問，
所以此處才定義了一個這么個和訪問控制相關的協議。

此協議可實現允許主機Host或者設備Device去鎖定Lock或者解鎖Unlock 對應的存儲設備。

 

【總結】

和安全存儲和權限控制相關的協議，我們此處也是暫不關心，可忽略之。

2.1.1.7. USB MSC USB Attached SCSI Protocol (UASP)

“Attached”顧名思義，是附在某個上面的，此處即附在SCSI協議的上面的，即SCSI協議的補充部分。

UASP規范，定義了關於如何在USB 2.0和USB 3.0中，
UAS的傳輸標准是如何實現的，並且給出了一些范例和一些推薦的做法。

2.1.1.7.1. 已有SCSI協議，為何還要再弄一個UASP

既然已經有了對應的SCSI協議，用於發送對應命令，實現對應功能。作為U盤等應用的話，
直接實現對應的協議，符合對應的規范，不是也就可以實現對應功能了嗎，
為何還要另外再弄出一個SSCI的附屬協議UASP？

那是因為，原先的BOT（Bulk Only Transport），雖然協議簡單已實現，
適合用於大容量存儲設備中，但其就像一個單線程，不能同時並行執行多個傳輸。

即，對於BOT，每一個由Host發起數據傳輸（transaction），都必須等待設備完成，
然后設備再返回對應的已完成狀態信息，然后才能開始下一次數據傳輸。
這樣的話，對於整個數據傳輸過程的話，就造成了一個很大（大概有20%）的浪費（overhead）。

而對於USB 3.0來說，速度從USB 2.0的480Mb/s變成了 5.0Gb/s，
而如果繼續用BOT的話，那么相對來說CPU性能的利用率很低，
USB傳輸速度也不太高，例如，有研究表明，2.4 GHz Core Duo™的CPU，
利用率只要大概12%，CPU傳輸速度只有大約250MB/s，
而USB 3.0的理論速度是5.0Gb/s=640MB/s，即還不到理論最大速度的一半。

因此，才有了這個UASP，對於SCSI協議進行了補充，以提高USB 2.0的USB總線利用率，
和充分利用USB 3.0的全雙工能力，可以使得傳輸速度達到大約400MB/s。
此新的協議UASP的實現，也需要對應的新的Host端的軟件，新的Device端的固件（Firmware）。

為了實現設備的向后兼容性，Device同時支持BOT和UAS。

而此UASP規范，定義了就是如何在USB 2.0和USB 3.0上實現對應的UAS協議。

當Host和Device都實現了此UAS協議的話，那么Host將通過Host端的
SCSI Software Stack去訪問Device，而USB的Interface也將從功能上看，
變成Host Stack中的另外一個SCSI Host Adapter。
Device需要實現SAM4的架構模型，這樣Host也就可以查詢
（Queue）Device中的命令了，以及對應性能的提升。

 

【總結】

為了克服舊的BOT協議的總線利用率不高的缺點，所以定義了新的UAS協議，
即UASP，來提升USB的傳輸效率，提升USB速度。

當然，我們此處為了實現U盤功能的話，當然希望性能越高越好了，
所以，這個協議也是我們應該好好研究的。

2.1.2. USB MSC的各個協議之間關系總結

為了說明清楚USB Mass Storage各個協議的關系，我們先給這些協議編個號：

①USB Mass Storage Class Control/Bulk/Interrupt (CBI) Transport

②USB Mass Storage Class Bulk-Only (BBB) Transport

③USB Mass Storage Class Universal Floppy Interface (UFI) Command Specification

④USB Mass Storage Class Bootability Specification

⑤USB Mass Storage Class Compliance Test Specification

⑥USB Lockable Storage Devices Feature Specification (LSD FS)

⑦USB Mass Storage Class USB Attached SCSI Protocol (UASP)

直接用圖來表示USB MSC各個協議之間的關系，顯得更加直觀：

圖 2.7. USB Storage Class Protocol Relation

如上圖，我們U盤實現的功能，主要就是數據的讀寫，而Device和Host之間的數據通信，主要有兩種：

1. CBI：主要用於Floppy設備，所以新的設備，都很少用此協議
2. BOT：Bulk-Only Transport，也稱BBB（Bulk/Bulk/Bulk），

而對於BOT/BBB來說，對其提高USB總線利用率，提高了USB速度后，
就是對應的UASP協議，故此處稱UASP為BOT的增強版的協議。

協議方面說完了，再來看看USB Device這一端。

而USB的Device端，根據內部數據存儲的介質類型不同，又分兩種：

1. 一種是Floppy設備，對應用的是UFI Command Set；
2. 而另外一種，就是我們常見的Flash Memory，對應的是用SCSI Command Set。

而SCSI協議，本身就是有的了，所以不是屬於USB MSC協議范疇，即SCSI只是和USB MSC相關的協議。

同樣的，對於USB Device本身，如果需要一些用到其他的特性，比如可啟動性，兼容性，可鎖定性等等，
那么分別對應的規范是

④USB Mass Storage Class Bootability Specification

⑤USB Mass Storage Class Compliance Test Specification

⑥USB Lockable Storage Devices Feature Specification (LSD FS)

 

【總結】

至此，各個協議和規范之間的關系，就很容易理解了。上面這么多協議中，其中我們所要關心的，
只有三個規范，如前面的圖中，已經用星號標識出來了：

1. 最需要關心的是BOT，即Host和Device間數據通訊的協議

   ★★★ ②USB Mass Storage Class Bulk-Only (BBB) Transport

2. 其次，需要關心USB Device內部和數據存儲介質之間通信的協議

   ★★ SCSI - Small Computer System Interface

3. 最后，對於，如果要實現更好的性能，那么需要關心BOT的升級版

   ★⑦USB Mass Storage Class USB Attached SCSI Protocol (UASP)

2.1.3. U盤與USB中的Class，Subclass和Protocol的對應關系

對應的，了解USB的都知道，每個設備的描述符中，都有對應下面這幾個域：

• bInterfaceClass
• bInterfaceSubClass
• bInterfaceProtocol

分別對應着USB的Class，Subclass，Protocol。

而對於我們此處的U盤：

2.1.3.1. bInterfaceClass=0x08=Mass Storage

Class就是USB Mass Storage Class，

2.1.3.2. bInterfaceSubClass=0x06=SCSI Transparent

Subclass，所支持的列表如下：

圖 2.8. SubClass Codes Mapped to Command Block Specifications

2.1.3.3. bInterfaceProtocol=0x50=Bulk Only Transport

Protocol，所支持的列表如下：

圖 2.9. Mass Storage Transport Protocol

從上面這些規范中所定義的支持的協議來看，加上顏色框的那幾個，
也就是我們前面所解釋過的，需要我們關心和研究的協議，即SCSI，BBB和UAS。

USB數據流向圖

 

http://blog.csdn.net/kevinyujm/article/details/5423098

Mass Storage設備所使用的SCSI命令集
0x00    TestUnitReady
0x03    RequestSense
0x12    Inquiry
0x1A    ModeSense6
0x1B    StartStop
0x1E    MediumRemoval
0x23    ReadFormatCapacity
0x25    ReadCapacity
0x28    Read(10)
0x2A    Write(10)
0x2F    Verify
0x5A    ModeSense10

- 主機首先發出Inquiry命令，響應了Inquiry之后就可以看到盤符.

- Inquiry之后會發出ReadFormatCapacity命令，這個命令在SCSI規范中是“廠家自定義命令”,
可以參考UFI命令集文檔（實際上，U盤所使用的所有SCSI命令集都可以參考UFI文檔，它比SCSI標准文檔更簡潔明了）。
注意這個命令在BusHound里是沒有描述的，必須在“Device”選項頁里勾選上
這個U盤所對應的USB Mass Storage Device這個節點，才能看到這個命令的數據流。

- ReadFormatCapacity之后會發出ReadCapacity命令。
ReadCapacity完成后就會發送Read(10)讀取U盤的第一個扇區。

- U盤讀數據（讀扇區）時會發送Read(10)。
- U盤寫數據時（寫扇區）會發送Write(10)。

- TestUnitReady會在無其他數據傳輸時會定時發送，如果設備沒有回應成功的CSW給主機，
則主機認為設備已不存在。此時如果再雙擊磁盤圖標，Windows會提示“請插入磁盤”。

- Verify在寫數據時有用，表示核實數據，一般直接返回成功的CSW就可以了。
一般來說，數據校驗的工作在接收和向介質寫數據時就已經順帶做了，
如果發現錯誤，則直接告訴主機那次的數據傳輸有誤，不會等到主機Verify時。
當然，這不是一個必然的方案。

- RequestSense：如果CSW指示此次傳輸不成功，那么主機會發出此請求。

- StartStop暫時未發現大用處，一般直接返回成功的CSW。

- MediumRemoval在U盤被Eject的時候有用，處理不正確會Windows會彈出錯誤信息。

- ModeSense6/ModeSense10 這兩個命令可以不支持
（不支持不代表不反應，任何一個命令你都要做出反應，對於不支持的命令，可以通過STALL握手來向主機表明），
暫時也未遇到過什么異常情況，而且我查看過一些U盤，有相當一部分就是隨便回了幾個數據給主機。
這兩個命令只會在U盤插入后發送一次，此后不再發送。

USB Mass Storage設備的描述符及枚舉過程

_Interface_Descriptor:
     .dw   0x09                   //bLength: 0x09 byte
     .dw   0x04                   //bDescriptorType: INTERFACE
     .dw   0x00                   //bInterfaceNumber: interface 0
     .dw   0x00                   //bAlternateSetting: alternate setting 0
     .dw   0x02                   //bNumEndpoints: 3 endpoints(EP0,EP1,EP2)
 .dw 0x08 //bInterfaceClass: Mass Storage Devices Class
     .dw   0x06                   //bInterfaceSubClass: .dw 0x50 //bInterfaceProtocol
     .dw   0x00                   //iInterface: index of string
_Interface_Descriptor_End:

_Endpoint1:
     .dw   0x07                   //bLength: 0x07 byte
     .dw   0x05                   //bDescriptorType: ENDPOINT
     .dw   0x81                   //bEndpointAddress: IN endpoint 1
     .dw   0x02                   //bmAttributes: Bulk
     .dw   0x40, 0x00             //wMaxPacketSize: 64 byte
     .dw   0x00                   //bInterval: ignored

_Endpoint2:
        //Endpoint 2 (0x07 byte)
     .dw   0x07                   //bLength: 0x07 byte
     .dw   0x05                   //bDescriptorType: ENDPOINT
     .dw   0x02                   //bEndpointAddress: OUT endpoint 2
     .dw   0x02                   //bmAttributes: Bulk
     .dw   0x40, 0x00             //wMaxPacketSize: 64 byte
     .dw   0x00                   //bInterval: ignored

 

第一，主機首先會發出一系列標准請求。
第二，在標准請求完成之后，會發出兩個類請求：
Bulk-Only Mass Storage Reset請求和
Get Max LUN請求。

Bulk-Only Mass Storage Reset沒有數據階段，
只在狀態階段告訴主機設備的Reset過程完成與否。
如果在狀態階段返回ACK，那么主機就認為設備已經Reset完畢並准備好接收CBW了。

Get Max LUN要求設備返回一個字節的數據給主機，以表明此USB設備有多少個邏輯設備。
返回的這個數據就是最大的設備邏輯號（Logic Unit Number），
范圍是0到15。例如，如果返回2，那么代表有0、1、2三個邏輯設備。 

USB Mass Storage設備的Bulk數據交換流程

通過bulk端點進行的數據傳輸，都遵循這樣一個過程，即三個階段：

CBW->DATA->CSW

CBW是一個數據塊，攜帶主機發給設備的SCSI命令。
接收了CBW后，設備就可以從中知道在接下來的DATA階段中該干什么。

DATA階段有三種情況：
無數據需要傳輸，
IN傳輸（設備到主機）或
OUT傳輸（主機到設備）。

CSW階段反饋這次傳輸的結果給主機。

其中值得注意的是:

- 在設備枚舉完成之后，主機發出的第一個bulk OUT事務就是請求向設備發出CBW。
所以設備可以通過這第一次的bulk OUT事務來判定第一次bulk數據傳輸的開始。
此后的bulk數據傳輸就按照上述的三個階段反復執行。
也就是說，第一次傳輸CBW后，如果有數據要傳輸，那么就會經歷DATA階段，然后進入CSW階段；
如果沒有數據要傳輸，則直接進入CSW階段，就此一次傳輸結束。
接下來，如果又有傳輸，那么再發出CBW。
因此，設備可以認為CSW完成后收到的下一個bulk OUT事務就是主機請求傳輸新的CBW。

- CBW[12]（CBW數據塊的第13個字節）指明了傳輸方向，CBW[8-11]指明了傳輸的數據長度。
實際上，CBW中的SCSI命令就暗含了數據要傳輸的方向和數據長度，
因為SCSI規范中已明確規定這個命令所對應的數據格式。
（在完整的應用中，要將CBW中的傳輸方向、數據長度與SCSI命令所表明的傳輸方向和數據長度做比較，
不對應就要進行錯誤處理（Mass Storage Bulk-Only文檔中有相關描述），
不過正常情況下二者是匹配的，試驗的時候可以暫時不理）。

- CSW[12]（CSW數據塊的第13個字節）這個字節很重要，它為0則表示此次傳輸成功，非0就是不成功。
在DATA階段的數據傳完（或者無需數據傳輸）之后，主機會發出IN事務請求設備返回CSW。
如果CSW傳送的是不成功的信息，那么主機會接着發送另一個命令來獲取失敗的詳細信息（即RequestSense命令）。

http://www.hzlitai.com.cn/article/ARM11/SYSTEM/1746.html

 

Bulk－Only 傳輸協議 

下面看看Bulk－Only 傳輸協議：
（詳細的規范請閱讀《Universal Serial BusMass Storage ClassBulk-Only Transport》） 

設備插入到USB 后，USB 即對設備進行搜索，並要求設備提供相應的描述符。
在USBHost 得到上述描述符后，即完成了設備的配置，
識別出為Bulk－Only 的Mass Storage 設備，
然后即進入Bulk－Only 傳輸方式。

在此方式下，USB 與設備間的所有數據均通過Bulk－In和Bulk－Out 來進行傳輸，不再通過控制端點傳輸任何數據。 
在這種傳輸方式下，有三種類型的數據在USB 和設備之間傳送，CBW、CSW 和普通數據。
CBW（Command Block Wrapper，即命令塊包）是從USB Host 發送到設備的命令，
命令格式遵從接口中的bInterfaceSubClass 所指定的命令塊，這里為SCSI 傳輸命令集。
USB設備需要將SCSI 命令從CBW 中提取出來，執行相應的命令，
完成以后，向Host 發出反映 當前命令執行狀態的CSW（Command Status Wrapper），
Host 根據CSW 來決定是否繼續發 送下一個CBW 或是數據。

Host 要求USB 設備執行的命令可能為發送數據，則此時需要將 特定數據傳送出去，
完畢后發出CSW，以使Host 進行下一步的操作。USB 設備所執行的操作可用下圖描述：

CBW的格式如下：

 

dCBWSignature: CBW的標識，固定值：43425355h (little endian)。
dCBWTag: 主機發送的一個命令塊標識，設備需要原樣作為dCSWTag（CSW中的一部分）
再發送給Host;主要用於關聯CSW到對應的CBW。 
dCBWDataTransferLength: 本次CBW命令要求在命令與回應之間傳輸的字節數。如果為0，則不傳輸數據。
bmCBWFlags: 反映數據傳輸的方向，0 表示來自Host，1 表示發至Host； 
bCBWLUN: 對於有多個LUN邏輯單元的設備，用來選擇具體目標。如果沒有多個LUN，則寫0。
bCBWCBLength: 命令的長度，范圍在0~16.
CBWCB: 傳輸的具體命令，符合bInterfaceSubClass.中定義的命令規范，此處是SCSI

CSW命令格式如下：

 

dCSWSignature: CSW的標識，固定值：53425355h (little endian)
dCSWTag: 設置這個標識和CBW中的dCBWTag一致，參照上面關於dCBWTag的解釋
dCSWDataResidue: 還需要傳送的數據，此數據根據dCBWDataTransferLength－本次已經傳送的數據得到 
bCSWStatus: 指示命令的執行狀態。如果命令正確執行，bCSWStatus 返回0 即可。

 

SCSI指令集

 

Bulk-Only 的CBW 中的CBWCB 中的內容即為如下格式的命令塊描述符
（Command Block Descriptor）。SCSI-2 有三種字長的命令，
6 字節、10字節和12字節，Microsoft Windows 環境下支持12 字節長的命令。 

Operation Code： 操作代碼，表示特定的命令。
高3 位為Group Code，共有8 種組合， 即8 個組，
低5 五位為Command Code，可以有32 種命令。 

Logicol unit Number： 為了兼容SCSI－1 而設的，此處可以不必關心。 
Logical block address： 為高位在前，低位在后的邏輯塊地址，即扇區地址。第2 字節為高位，第3、4、5 字節依次為低位。 
Transfer length： 為需要從邏輯塊地址處開始傳輸的扇區數（比如在Write 命令中）。 
Parameter list length： 為需要傳輸的數據長度（比如在Mode Sense 命令中）； 
Allocation length： 為初始程序為返回數據所分配的最大字節數，此值可以為零，表示不需要傳送數據。 

SCSI指令集的Direct Accesss 類型存儲介質的傳輸命令有許多，
Mass Storage協議只用到了其中的一些。
更多的SCSI指令參見：http://en.wikipedia.org/wiki/SCSI_command

 

對於不同的命令，其命令塊描述符略有不同，其要求的返回內容也有所不同，根據相 應的文檔，
可以對每種請求作出適當的回應。比如，下面是INQUIRY 請求的命令塊描述符和其返回內容的數據格式：
如：INQUIRY 命令描述符：

 

返回數據格式

Host 會依次發出INQUIRY、Read Capacity、UFI Mode Sense 請求，
如果上述請求的返回結果都正確，則Host 會發出READ 命令，
讀取文件系統0 簇0 扇區的MBR 數據，進入文件系統識別階段。

http://www.usb.org/developers/devclass_docs/usbmassbulk_10.pdf

 

Data Transfer Conditions

This section describes how the host and device remain synchronized.

The host indicates the expected transfer in the CBW using the Direction bit
and the dCBWDataTransferLength field.

The device then determines the actual direction and data transfer length. 
The device responds as defined in 6 -
Host/Device Data Transfers by transferring data,
STALLing endpoints when specified, and returning the appropriate CSW.

5.3.1 Command Transport
The host shall send each CBW, which contains a command block,
to the device via the Bulk-Out endpoint.
The CBW shall start on a packet boundary and end as a short packet
with exactly 31 (1Fh) bytes transferred.

The device shall indicate a successful transport of a CBW by accepting (ACKing) the CBW.
If the CBW is not valid see 6.6.1 - CBW Not Valid.
If the host detects a STALL of the Bulk-Out endpoint during command transport,
the host shall respond with a Reset Recovery (see 5.3.4 - Reset Recovery).

5.3.2 Data Transport

All data transport shall begin on a packet boundary.
The host shall attempt to transfer the exact number of bytes
to or from the device as specified by the dCBWDataTransferLength and the Direction bit.
The device shall respond as specified in 6 - Host/Device Data Transfers.

To report an error before data transport completes and to maximize data integrity,
the device may terminate the command by STALLing the endpoint in use
(the Bulk-In endpoint during data in, the Bulk-Out endpoint during data out).

5.3.3 Status Transport
The device shall send each CSW to the host via the Bulk-In endpoint.
The CSW shall start on a packet boundary and
end as a short packet with exactly 13 (Dh) bytes transferred.
Figure 2 - Status Transport Flow defines the algorithm
the host shall use for any CSW transfer.

The CSW indicates to the host the status of the execution of the command block
from the corresponding CBW.
The dCSWDataResidue field indicates how much of the data transferred is
to be considered processed or relevant.
The host shall ignore any data received beyond that which is relevant.

5.3.3.1 Phase Error

The host shall perform a Reset Recovery
when Phase Error status is returned in the CSW.

5.3.4 Reset Recovery

For Reset Recovery the host shall issue in the following order: :

(a) a Bulk-Only Mass Storage Reset
(b) a Clear Feature HALT to the Bulk-In endpoint
(c) a Clear Feature HALT to the Bulk-Out endpoint

Host/Device Data Transfers

6.1 Overview

A Bulk-Only Protocol transaction begins with the host sending a CBW to the device
and attempting to make the appropriate data transfer (In, Out or none).
The device receives the CBW, checks and interprets it, attempts to satisfy the host's request,
and returns status via a CSW.

This section describes in more detail this interaction between the host and the device
during normal and abnormal Bulk-Only Protocol transactions.

6.2 Valid and Meaningful CBW

The host communicates its intent to the device through the CBW.
The device performs two verifications on every CBW received.
First, the device verifies that what was received is a valid CBW.
Next, the device determines if the data within the CBW is meaningful.

The device shall not use the contents of the dCBWTag in any way
other than to copy its value to the dCSWTag of the corresponding CSW.

6.2.1 Valid CBW

The device shall consider the CBW valid when:
· The CBW was received after the device had sent a CSW or after a reset,
· the CBW is 31 (1Fh) bytes in length,
· and the dCBWSignature is equal to 43425355h.

6.2.2 Meaningful CBW
The device shall consider the contents of a valid CBW meaningful when:
· no reserved bits are set,
· the bCBWLUN contains a valid LUN supported by the device,
· and both bCBWCBLength and the content of the CBWCB are in accordance with bInterfaceSubClass.

6.3 Valid and Meaningful CSW
The device generally communicates the results of its attempt to satisfy the host’s request through the CSW.
The host performs two verifications on every CSW received.
First, the host verifies that what was received is a valid CSW
Next, the host determines if the data within the CSW is meaningful.

6.3.1 Valid CSW
The host shall consider the CSW valid when:
· the CSW is 13 (Dh) bytes in length,
· and the dCSWSignature is equal to 53425355h,
· the dCSWTag matches the dCBWTag from the corresponding CBW.

6.3.2 Meaningful CSW
The host shall consider the contents of the CSW meaningful when:
either the bCSWStatus value is 00h or 01h < Command Passed or Command Failed >
and the dCSWDataResidue is less than or equal to dCBWDataTransferLength..
or the bCSWStatus value is 02h. < Phase Error>

6.4 Device Error Handling
The device may not be able to fully satisfy the host's request.
At the point when the device discovers that it cannot fully satisfy the request,
there may be a Data-In or Data-Out transfer in progress on the bus,
and the host may have other pending requests.
The device may cause the host to terminate such transfers by STALLing the appropriate pipe.
The response of a device to a CBW that is not meaningful is not specified.

Please note that whether or not a STALL handshake actually appears on the bus
depends on whether or not there is a transfer in progress at the point in time
when the device is ready to STALL the pipe.

6.5 Host Error Handling
If the host receives a CSW which is not valid, then the host shall perform a Reset Recovery.
If the host receives a CSW which is not meaningful, then the host may perform a Reset Recovery.

6.6 Error Classes
In every transaction between the host and the device, there are four possible classes of errors.
These classes are not always independent of each other and may occur at any time during the transaction.

6.6.1 CBW Not Valid
If the CBW is not valid, the device shall STALL the Bulk-In pipe.
Also, the device shall either STALL the Bulk-Out pipe,
or the device shall accept and discard any Bulk-Out data.
The device shall maintain this state until a Reset Recovery.

6.6.2 Internal Device Error
The device may detect an internal error for which it has no reliable means of recovery other than a reset.
The device shall respond to such conditions by:
either STALLing any data transfer in progress and returning a Phase Error status (bCSWStatus = 02h).
or STALLing all further requests on the Bulk-In and the Bulk-Out pipes until a Reset Recovery.

6.6.3 Host/Device Disagreements
After recognizing that a CBW is valid and meaningful, and in the absence of internal errors,
the device may detect a condition where it cannot meet the host’s expectation for data transfer,
as indicated by the Direction bit of the bmCBWFlags field and the dCBWDataTransferLength field of the CBW.
In some of these cases, the device may require a reset to recover.
In these cases, the device shall return Phase Error status (bCSWStatus = 02h).
Details on which cases result in Phase Error vs. non-Phase Error status are given in 6.7 The Thirteen Cases.

6.6.4 Command Failure
After recognizing that a CBW is valid and meaningful,
the device may still fail in its attempt to satisfy the command.
The device shall report this condition by returning a Command Failed status (bCSWStatus = 01h).

6.7 The Thirteen Cases
This section describes the thirteen possible cases of host expectations and device intent
in the absence of overriding error conditions.
Table 6.1 – Host/Device Data Transfer Matrix graphically displays these thirteen cases.

Important notes about the thirteen cases.

· Cases (1), (6) and (12) represent the majority of host and device transactions.
They indicate those conditions where the host and device agree as to the direction
and amount of data to be transferred. 
These cases are also referred to as “the thin diagonal.”

· Any host or device behavior not specifically outlined in the following sections
shall be considered outside this specification and the results are indeterminate.

6.7.1 Hn - Host expects no data transfers : Case (1), (2), (3)
These cases occur when dCBWDataTransferLength is zero.
This indicates that the host is not expecting to send or receive any data
to or from the device.
The general requirements of these cases are:
· The value of the Direction bit shall not influence the results of these cases.

The specific host requirements are:                           The specific device requirements are:
1. The host shall send a valid and meaningful CBW :           1. The device shall receive a CBW.
The host may set or clear the Direction bit.
2. The host shall attempt to receive a CSW.                   2. When the CBW is valid and meaningful, then:
                                                              · The device shall attempt the command.
3. When the CSW is valid and meaningful, then:
· [Case (1)]                                                   · [Case (1)]
The bCSWStatus = 00h or 01h, and the dCSWDataResidue is 0.    If the device had no data to send or receive, then:
                                                              The device shall set bCSWStatus to 00h or 01h.
                                                              The device shall set the dCSWDataResidue to 0.

· [Case (2) or (3)]                                            · [Case (2) or (3)]
If bCSWStatus = 02h, then:                                    If the device did have data to send or receive, then:
The host shall Ignore the value of the dCSWDataResidue.       The device shall set bCSWStatus to 02h.
The host shall Perform a Reset Recovery. 4. On a STALL condition receiving the CSW, then:             3. The device shall return a valid and meaningful CSW.
· The host shall clear the Bulk-In pipe.                     · The device may STALL the Bulk-In pipe if bCSWStatus is not 00h or 01h.
· The host shall attempt to receive the CSW again.

 

6.7.2 Hi - Host expects to receive data from the device : Case (4), (5), (6), (7), (8)

These cases occur when dCBWDataTransferLength is non zero and the Direction bit is 1 (Data-In).
This indicates that the host is expecting to receive data from the device.

The specific host requirements are:                                               The specific device requirements are:                                          
1. The host shall send a valid and meaningful CBW.                                1. The device shall receive a CBW.                                             
2. The host shall attempt to receive data from the device.                        2. When the CBW is valid and meaningful, then:                                 
                                                                                  · The device shall attempt the command.                                       
3. On a STALL condition receiving data, then:                                                                               
· The host shall accept the data received.                                       · [Case (4)or (5)]                                                            
· The host shall clear the Bulk-In pipe.                                         If the device intends to send less data than the host indicated, then:         
                                                                                The device shall send the intended data.                                     
                                                                                The device may send fill data to pad up to a total of dCBWDataTransferLength.
4. The host shall attempt to receive a CSW.                                     If the device actually transfers less data than the host indicated, then:      
                                                                                    The device may end the transfer with a short packet.                         
5. On a STALL condition receiving the CSW, then:                                    The device shall STALL the Bulk-In pipe.                                     
· The host shall clear the Bulk-In pipe.                                             The device shall set bCSWStatus to 00h or 01h.                               
· The host shall again attempt to receive the CSW.                                   The device shall set dCSWDataResidue to the difference between               
                                                                                    dCBWDataTransferLength and the actual amount of relevant data sent.          
6. When the CSW is valid and meaningful, then:                                                                               
                                                                                  · [Case (6)]                                                                  
· [Case (4) or (5)]                                                              If the device intends to send dCBWDataTransferLength, then:                    
If bCSWStatus = 00h or 01h, then:                                                     The device shall send dCBWDataTransferLength bytes of data.                  
The host shall determine the amount of relevant data received from the                The device shall set bCSWStatus to 00h or 01h.                               
difference between dCBWDataTransferLength and the value of dCSWDataResidue.           The device shall set dCSWDataResidue to zero.                                
                                                                               
· [Case (6)]                                                                     [Case (7) or (8)]                                                              
If bCSWStatus = 00h or 01h, then:                                                 If the device either intends to send more data than the host indicated or      
The host shall determine the amount of relevant data received from the            intends to receive data from the host, then:                                   
difference between dCBWDataTransferLength and the value of dCSWDataResidue.           The device may send data up to a total of dCBWDataTransferLength.            
                                                                               
· [Case (7) or (8)]                                                              If the device actually transfers less data than the host indicated, then:      
If bCSWStatus = 02h, then:                                                            The device may end the transfer with a short packet.                         
The host shall ignore the value of the dCSWDataResidue.                               The device shall STALL the Bulk-In pipe.                                     
The host shall perform a Reset Recovery.                                                                               
                                                                                  If the device actually transfers dCBWDataTransferLength then:                  
                                                                                      The device may STALL the Bulk-In pipe.                                       
                                                                                      The device shall set bCSWStatus to 02h.                                      
                                                                               
                                                                                  3. The device shall return a valid and meaningful CSW:                         
                                                                               

 

6.7.3 Ho - Host expects to send data to the device : Case (9), (10), (11), (12), (13)

These cases occur when dCBWDataTransferLength is non zero-and the Direction bit is 0 (Data-Out).
This indicates that the host is expecting to send data to the device.

The general requirement of these cases is:
· The host shall not send zero length packets.

The specific host requirements are:                                           The specific device requirements are:
1. The host shall send a valid and meaningful CBW.                            1. The device shall receive a CBW.

2. The host shall send data to the device.                                    2. When the CBW is valid and meaningful, then:
· The host shall send a short packet only at the end of the data transfer.   · The device shall attempt the command.

3. On a STALL condition sending data, then:                                   · [Case (9), (11), or (12)]
· The host shall clear the Bulk-Out pipe.                                    If the device intends to process less than or equal to
                                                                              the amount of data that the host indicated, then:
4. The host shall attempt to receive a CSW.                                     The device shall receive the intended data.
                                                                                The device shall either accept a total of dCBWDataTransferLength,
5. On a STALL condition receiving the CSW, then:                                or end the transfer prematurely by STALLing the Bulk-Out pipe.
· The host shall clear the Bulk-In pipe.                                       The device shall set bCSWStatus to 00h or 01h.
· The host shall again attempt to receive the CSW.                             The device shall set dCSWDataResidue to the difference
                                                                                between dCBWDataTransferLength and the actual amount of data
6. When the CSW is valid and meaningful, then:                                  that was processed by the device.

· [Case (9), (11), or (12)]                                                  · [Case (10) or (13)]
If bCSWStatus = 00h or 01h, then:                                             If the device either intends to process more data
The host shall determine the amount of data that was processed                than the host indicated or intends to send data,then:
from the difference of dCBWDataTransferLength and
the value of dCSWDataResidue.                                                 The device may receive data up to a total of dCBWDataTransferLength.
                                                                              The device shall either accept a total of dCBWDataTransferLength,
· [Case (10) or (13)]                                                          or end the transfer prematurely by STALLing the Bulk-Out pipe.
If bCSWStatus = 02h, then:                                                    The device shall set bCSWStatus to 02h.
The host shall ignore the value of the dCSWDataResidue.
The host shall perform a Reset Recovery.                                      3. The device shall return a valid and meaningful CSW.
                                                                              · The device may STALL the Bulk-In pipe if bCSWStatus is not 00h or 01h.

USB MSD RD System Architecture

Mass Storage Device Mode Operation
When the device is in Mass Storage Device Mode,
the following blocks are used.
See Figure 3 for the connections between the blocks.

„ USB Low-level Interface
„ Mass Storage Device Class Command Interpreter
„ SCSI Command Interpreter
„ Sector Server
„ Media Access Firmware

The interactions between the USB, MSD, SCSI, and Sector Server blocks
are shown in Figure 6 and Figure 7.