网站显示时间代码,未备案网站,四川建筑培训考试网,手机app软件开发http://www.crifan.com/files/doc/docbook/usb_disk_driver/release/htmls/ch02_msc_basic.html USB Mass Storage Framework PC电脑和U盘之间的关系#xff0c;以及物理上的组成#xff0c;可以用下图表示 更深入的剖析#xff0c;对于普通U盘的内部结构#xff0c;则是一… 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-onlyBBB呢 我的理解是那是因为最开始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设备启动那么你就要实现对应的CDBCommand 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 那是因为原先的BOTBulk 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/s640MB/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也就可以查询QueueDevice中的命令了以及对应性能的提升。 【总结】 为了克服旧的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设备所以新的设备都很少用此协议BOTBulk-Only Transport也称BBBBulk/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中的ClassSubclass和Protocol的对应关系 对应的了解USB的都知道每个设备的描述符中都有对应下面这几个域 bInterfaceClassbInterfaceSubClassbInterfaceProtocol 分别对应着USB的ClassSubclassProtocol。 而对于我们此处的U盘 2.1.3.1. bInterfaceClass0x08Mass Storage Class就是USB Mass Storage Class 2.1.3.2. bInterfaceSubClass0x06SCSI Transparent Subclass所支持的列表如下 图 2.8. SubClass Codes Mapped to Command Block Specifications 2.1.3.3. bInterfaceProtocol0x50Bulk Only Transport Protocol所支持的列表如下 图 2.9. Mass Storage Transport Protocol 从上面这些规范中所定义的支持的协议来看加上颜色框的那几个也就是我们前面所解释过的需要我们关心和研究的协议即SCSIBBB和UAS。USB数据流向图 http://blog.csdn.net/kevinyujm/article/details/5423098 Mass Storage设备所使用的SCSI命令集0x00 TestUnitReady0x03 RequestSense0x12 Inquiry0x1A ModeSense60x1B StartStop0x1E MediumRemoval0x23 ReadFormatCapacity0x25 ReadCapacity0x28 Read(10)0x2A Write(10)0x2F Verify0x5A 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-CSWCBW是一个数据块携带主机发给设备的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 BulkOnly 传输协议 下面看看BulkOnly 传输协议详细的规范请阅读《Universal Serial BusMass Storage ClassBulk-Only Transport》 设备插入到USB 后USB 即对设备进行搜索并要求设备提供相应的描述符。在USBHost 得到上述描述符后即完成了设备的配置识别出为BulkOnly 的Mass Storage 设备 然后即进入BulkOnly 传输方式。 在此方式下USB 与设备间的所有数据均通过BulkIn和BulkOut 来进行传输不再通过控制端点传输任何数据。 在这种传输方式下有三种类型的数据在USB 和设备之间传送CBW、CSW 和普通数据。CBWCommand Block Wrapper即命令块包是从USB Host 发送到设备的命令 命令格式遵从接口中的bInterfaceSubClass 所指定的命令块这里为SCSI 传输命令集。USB设备需要将SCSI 命令从CBW 中提取出来执行相应的命令完成以后向Host 发出反映 当前命令执行状态的CSWCommand Status WrapperHost 根据CSW 来决定是否继续发 送下一个CBW 或是数据。Host 要求USB 设备执行的命令可能为发送数据则此时需要将 特定数据传送出去完毕后发出CSW以使Host 进行下一步的操作。USB 设备所执行的操作可用下图描述 CBW的格式如下 dCBWSignature: CBW的标识固定值43425355h (little endian)。dCBWTag: 主机发送的一个命令块标识设备需要原样作为dCSWTagCSW中的一部分再发送给Host;主要用于关联CSW到对应的CBW。 dCBWDataTransferLength: 本次CBW命令要求在命令与回应之间传输的字节数。如果为0则不传输数据。bmCBWFlags: 反映数据传输的方向0 表示来自Host1 表示发至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 为了兼容SCSI1 而设的此处可以不必关心。 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 TransportThe 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 TransportAll 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 TransportThe 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 ErrorThe host shall perform a Reset Recovery when Phase Error status is returned in the CSW.5.3.4 Reset RecoveryFor 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 OverviewA 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 hosts request, and returns status via a CSW. This section describes in more detail this interaction between the host and the deviceduring normal and abnormal Bulk-Only Protocol transactions. 6.2 Valid and Meaningful CBWThe 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 CBWThe 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 CSWThe 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 CSWThe 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 CSWThe 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 Error6.4 Device Error HandlingThe device may not be able to fully satisfy the hosts 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 HandlingIf 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 ClassesIn 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 ValidIf 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 ErrorThe 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 DisagreementsAfter 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 FailureAfter 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 CasesThis 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 tothe 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 differencebetween 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 OperationWhen 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. 转载于:https://www.cnblogs.com/shangdawei/archive/2013/06/13/3133526.html
