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），必须要实现下面这些功能：
检测和响应通用的USB Request和USB总线上的事件。
检测和响应来自USB设备的关于信息或者动作的USB Mass Storage Request。
检测和响应，从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的简写，但是其具体含义是：
Control
Control端点用于，除了传送标准的USB请求之外，还用于通过Class-specific的请求，
将命令块（command block）传给设备；即Control端点传送命令块
Bulk
Bulk In和Bulk Out端点用于在主机（Host）和设备（Device）之间数据的传输。
即Bulk用于传送数据
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之间的数据通信，主要有两种：
CBI：主要用于Floppy设备，所以新的设备，都很少用此协议
BOT：Bulk-Only Transport，也称BBB（Bulk/Bulk/Bulk），
而对于BOT/BBB来说，对其提高USB总线利用率，提高了USB速度后，
就是对应的UASP协议，故此处称UASP为BOT的增强版的协议。
协议方面说完了，再来看看USB Device这一端。
而USB的Device端，根据内部数据存储的介质类型不同，又分两种：
一种是Floppy设备，对应用的是UFI Command Set；
而另外一种，就是我们常见的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)
【总结】
至此，各个协议和规范之间的关系，就很容易理解了。上面这么多协议中，其中我们所要关心的，
只有三个规范，如前面的图中，已经用星号标识出来了：
最需要关心的是BOT，即Host和Device间数据通讯的协议
★★★ ②USB Mass Storage Class Bulk-Only (BBB) Transport
其次，需要关心USB Device内部和数据存储介质之间通信的协议
★★ SCSI – Small Computer System Interface
最后，对于，如果要实现更好的性能，那么需要关心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.
