USB EMBEDDED HOST CONTROLLER （2）

Published:2011/8/3 21:37:00 Author:Phyllis From:SeekIC

By Mark Schultz

SCSI

Many mass storage devices use SCSI commands for communication between the host and the device. We will be using three SCSI commands to perform our file operations. The commands are Inquiry, Read Capacity and Read(lO). The format of the three SCSI commands to be used in this design is shown in Table 2.




Each command takes an Op Code and a Logical Unit Number (LUN). Some commands have an LBA field. An LBA is a Logical Block Address. A Logical Block is the smallest addressable section of a mass storage device, often referred to as a sector. Later on, we will see how to use an LBA to access file data. The Read (10) command also has a field for transfer length. Transfer length generally refers to the number of sectors to be sent or received. For the purpose of simplicity, we will work with only one Logical Unit. Thus, the LUN field will always be ’0’.

UFI

Removable media mass storage devices containing a USB interface use a common interface known as the UFI interface. The SCSI commands are embedded in the UFI packets. A UFI transfer is carried out in three phases: command, data and status. The command phase employs the Command Block Wrapper (CBW) and the status phase, a Command Status Wrapper (CSW).

The CBW is a 31-byte packet with the first 15 bytes containing four bytes of signature and four bytes of tag, three bytes of commands and flags and 4 bytes for the length of the actual data to be read or written. The final 16 bytes comprise the command block, which is the actual SCSI command. The CBW signature is used to identify the device and is hard-coded to 55 53 42 43 by the UFI specification. Interestingly, the signature in ASCII is ’USBC for a USB Command. The tag can be any 4 byte value. The CSW will use the tag value received during the CBW phase to report the status of the CBW.

The CSW is a 13-byte packet and is similar to the CBW in that it contains four bytes of signature hard-coded to 55 53 42 53 which, in ASCII is ’USBS’ for USB Status. There is also a 4-byte tag that will be matched against the tag of the CBW. The CSW also contains four bytes for the residue, which is the expected transfer length minus the actual transferred data length. There is one additional byte used to report transfer status. An example of a USB transfer using a CBW and a CSW is shown in Figure 2.





The first transaction is the CBW. The signature is contained in bytes 0 through 3 and the tag is contained in bytes 4 through 7. The tag can be any random 32-bif number. The CSW will use the tag value to acknowledge completion of the command specified in the CBW. The ’24’ in byte 8 is a hexadecimal value representing 36 decimal and is the actual length of the transferred data in the second phase.

The second transaction is the data stage and includes the 36 bytes of data read back from the USB mass storage device. In this case, the data is in response to an Inquiry command (12H) that can be seen in byte 15 of the first transaction. Converting the 36 bytes of data beginning at the ninth byte to ASCII will reveal the string ’Cypress Flash Disk’.

The third transaction is the CSW. Note the match between the tags of the CBW and the CSW. There is no remaining data to be transferred as shown in bytes 8 through 11. Byte 12 contains the status of the transaction. For this field, a ’0’ denotes success.

The Cypress EZ-Host controller

The Cypress EZ-Host is a 16-bit RISC based microcontroller, which contains two Serial Interface Engines (SIEs). Each SIE controls two USB host ports or one USB peripheral port. The EZ-Host also contains a number of peripherals such as RS-232, SPI, HPI and HSS. There are 16 K bytes of internal memory space and provisions for an external memory interface.

The EZ-Host includes a firmware framework that takes care of most of the USB Host details. With full support for various types of USB transfers, reading and writing to USB mass storage devices is as simple as filling in some information and letting the frameworks handle the rest. The EZ-Host framework contains all of the necessary firmware to implement USB Host functionality. Included in this are task scheduling, device enumeration, bandwidth allocation and power management.

Applications, on the other hand, are the firmware to control specific USB devices and communicate their data to an end application.

At the heart of the frameworks is the TD processor. The TD processor operates on a data structure called a Task Descriptor (TD) using its information to communicate with the USB hardware, specifically the Serial Interface Engine (SIE). It is important to note that each of the SIEs controls two ports and that there is a TD processor for each SIE.

The framework code incorporates a simple round-robin scheduler. The scheduler handles a number of tasks such as checking for device insertion and removal, checking the UART for incoming messages and executing the ’run’ function of every installed device driver.

Basic USB transfers are used to move data in either direction (Host to Peripheral and Peripheral to Host). The host initiates the transfers. To move data to a peripheral, the host uses the function usb_send_bulk_out. To get data from a peripheral, the host uses usb_recv_bulk_in. Each of these functions requires some additional data - a pointer to the device structure, the USB endpoint to be used, the length of transfer, and a pointer to the send or receive buffer. Once these details are specified, the framework takes care of the rest.

Reprinted Url Of This Article: http://www.seekic.com/blog/project_solutions/2011/08/03/USB_EMBEDDED_HOST_CONTROLLER__（2）.html

Print this Page | Comments | Reading(1886)