The Host Expects No Data Transfer

22 Mar

The Host Expects No Data Transfer
When dCBWDataTransferLength is zero, the host expects the command to have no data-transport phase.

In the most common situation (case 1), the device agrees that there is no data-transport phase. The device sets bCSWStatus to 00h or 01h and sets dCSWDataResidue to zero.

If the device expects to send (case 2) or receive (case 3) data in the data-transport phase when the host expects no data, the devices sets bCSWStatus to 02h and may stall the bulk IN endpoint. On receiving bCSWStatus = 02h, the host ignores dCSWDataResidue and performs a reset recovery or resets the device’s port.

The Host Expects to Receive Data
When dCBWDataTransferLength is greater than zero and the Direction bit in bmCBWFlags = 1, the host expects to receive data in the data-transport phase.

In the most common situation (case 6), the device intends to send dCBWDataTransferLength bytes. The device sets bCSWStatus to 00h or 01h and sets dCSWDataResidue to zero.

If the device expects to send no data (case 4) or less than dCBWDataTransferLength bytes (case 5), the device may pad the data up to the requested length, or the device may send no data or less data. A device that sends less than the requested amount of data must stall the bulk IN endpoint. In either case, the device sets bCSWStatus to 00h or 01h and sets dCSWDataResidue to the difference between dCBWDataTransferLength and the amount of data sent, excluding any pad bytes.

If the device expects to send more than dCBWDataTransferLength bytes (case 7) or expects to receive data from the host (case 8), the device may send up to dCBWDataTransferLength bytes. On sending less than dCBWDataTransferLength bytes, the device must stall the bulk IN endpoint and set bCSWStatus to 02h. On sending dCBWDataTransferLength bytes, the device may stall the bulk IN endpoint and must set bCSWStatus to 02h. On receiving bCSWStatus = 02h, the host ignores dCSWDataResidue and performs a reset recovery or resets the device’s port.

The Host Expects to Send Data
When dCBWDataTransferLength is greater than zero and the Direction bit in bmCBWFlags = 0, the host expects to send data in the data-transport phase.

In the most common situation (case 12), the device expects and receives dCBWDataTransferLength bytes. The device sets bCSWStatus to 00h or 01h and sets dCSWDataResidue to zero.

If the device expects to receive less than dCBWDataTransferLength bytes (case 11) or no data (case 9), the device may accept dCBWDataTransfer- Length bytes (recommended) or the device may end the transfer early by stalling the bulk OUT endpoint. In either case, the device sets bCSWStatus to 00h or 01h and sets dCSWDataResidue to the difference between dCBWDataTransferLength and the amount of data processed. The amount of data processed by the device can be less than or equal to the amount of data received and accepted by the device. Stalling the bulk OUT endpoint in these cases can cause problems under Windows, so most devices accept dCBWDataTransferLength bytes and set dCSWDataResidue to the appropriate value.

If the device expects to receive more than dCBWDataTransferLength bytes (case 13) or expects to send data to the host (case 10), the device may accept up to dCBWDataTransferLength bytes or may end the transfer early by stalling the bulk OUT endpoint. In either case, the device sets bCSWStatus to 02h. If bCSWStatus = 02h, the device may stall the bulk IN endpoint as well. On receiving bCSWStatus = 02h, the host ignores dCSWDataResidue and performs a reset recovery or resets the device’s port.

PC Support
Major operating systems include drivers to support communications with mass-storage devices

Windows
Windows 2000 and later include a driver that supports USB devices that use the bulk-only transport protocol and CBI. When a device’s descriptors identify the device as mass-storage class with a supported bInterfaceSubClass, the operating system loads the USB storage port driver (usbstor.sys). This driver manages communications between the lower-level USB drivers and Windows’ storage-class drivers. The operating system assigns a drive letter to the device’s volume or volumes, which appear in My Computer. Mass-storage devices don’t need a vendor-specific INF file to specify a driver. The Windows file usbstor.inf causes Windows to load the mass-storage drivers
for any mass-storage device in a supported bInterfaceSubClass.

The mass-storage driver in Windows XP supports bInterfaceSubClass codes 02h, 05h, and 06h. Support for drives with multiple LUNs was added in Windows 2000 SP3.

Users with administrator access rights can run applications that send SCSI commands to devices using the IOCTL_SCSI_PASS_THROUGH function. To open a device for sending SCSI pass-through requests, the application must call CreateFile with the dwDesiredAccess parameter requesting both GENERIC_READ and GENERIC_WRITE access.

One point of confusion relating to the mass-storage support under Windows is Windows’ support for Autoplay (previously called Autorun). Autoplay enables the operating system to run a program, play a movie, or perform other actions when a disk or other removable media is inserted. To support Autoplay, a USB flash drive must contain a startup application and an autorun.inf file that identifies the application. For operating systems previous to Windows XP SP2, the drive must report that it has non-removable media in the response to a SCSI INQUIRY command. Chapter 6 has more about the INQUIRY command.

Flash drives that incorporate U3 smart drive technology can hold a self-contained application that runs on a Windows PC without having to install the application on a hard drive, make registry changes, or reserve other system resources. Running an application from a U3 drive copies temporary files to the host computer,. The temporary files run the application and disappear when the application closes. U3 is an open standard developed by SanDisk and M-Systems. More information and development kits are at www.u3.com. A similar technology is available in the Ceedo portable operating system from Ceedo Technologies.

Linux
Linux has two drivers that support communications with USB mass-storage devices. The usb-storage driver in Linux/drivers/usb/storage supports a wide range of devices and has fast performance. The ub driver in Linux/drivers/ block/ub.c focuses on reliable operation but is slower and doesn’t support as many devices. The ub driver supports only the bulk-only transport protocol and PDT = 00h, doesn’t try to accommodate non-compliant devices, uses its own SCSI stack, and waits for each USB request block (URB) to complete before submitting the next one.

Random Posts

No comments yet

Leave a Reply

You must be logged in to post a comment.