USB Interface becomes very popular in modern computer technology. Some desk top computers provide 12 USB ports. Most digital camera, camcorder, cell phone, PDA and notebook computer etc. all provide USB interface or Blue tooth. On some legacy free computer systems, the traditional PS2 keyboard & mouse interface, parallel printer interface, 1394 scanner interface, analog audio interface are replaced with USB interface. I expect that the video interface will be replaced by USB interface soon. In the future, on the back plate of the computer, we will see only two kinds of ports: USB ports and Ethernet ports.
Started in 1994, the USB core companies assembled. In 1996, USB 1.0 specification was released. In 1998, USB 1.1 specification was released. In 2000, USB 2.0 specification was released. In 2008,USB 3.0 specification was released. We walked into USB era. Although USB 3.0 improved the bandwidth ( it can reach 4.8Gbps), its connections also increased to 8. For small devices, 8 connections will be big disadvantage. I believe, USB 2.0 will continue to dominate the market in the near future.
To design a USB chipset or a USB device and write driver and firmware for it, we need to look the USB transaction between the host and device pretty often. All the USB transactions must follow the USB specification. If we compare the USB transaction as a English story, the USB specification will be the book combined English dictionary with English grammar book. In the English story, the English words must come from the dictionary and the grammar must come from the English grammar book. However, to read the English story, we do not need to remember all the English words in the English dictionary. A good English story can help us understand the English words and English grammar. In this paper, I will show you a good “English story” – a real example for USB packets transferring. I will tell you what each “word” means and the grammar for each sentence.
Before you read a English story, you had better to prepare the English dictionary and English grammar book, assuming you are learning English. Before you read the real example for USB packets transferring, please find the following 5 books from Internet. They are free.
(1) Universal Serial Bus Specification 2.0
(2) USB Simply Buffered Mass Storage Class – Bulk-Only Transport
(3) Universal Serial Bus Mass Storage Class Specification Overview
(4) Universal Serial Bus Mass Storage Class UFI Command Specification
(5) Universal Serial Bus Mass Storage Class Bulk-Only Transport
In the following example, we will show the USB transaction between a host and a composite device (virtual floppy and virtual CD). The virtual floppy is connected. There is no media inside the virtual CD. This is why we see a lot of yellow marks in the transaction. The overview of the USB transaction is shown in Figure 1. We will expand each sentence one by one.
Figure 1. The overview of the USB transaction.
1 Reset
The USB transaction started with “Reset”. This state occurs when a SE0(single ended zero) state is held more than 2.5 microseconds. When no device is connected to the USB port, two pull-down resistors on the data lines of USB port, leading a SE0 state, is the default state. When a device is connected to the USB port, it will enter the “Reset” state.
2 High-speed Detection Handshake
The second sentence is the High Speed Detection Handshake. All high speed devices start at full speed to guarantee USB 1.1backward compatibility. If the USB device supports high speed signaling, it will generate a Chirp K state on the USB bus after “Reset” state. No more than 100 μs after the bus leaves the Chirp K state, the host must begin to send an alternating sequence of Chirp K’s and Chirp J’s. Then the host and USB device transition to the high-speed mode.
3 SetAddress (6)
The data sequence:
2D 00 10 //SETUP packet , 2D is the SETUP Token PID value, ADDR is 0, ENDP is 0.
C3 00 05 06 00 00 00 00 00 EA 92
// DATA0 packet, C3 means DATA0 token, “EA 92” is the CRC16
// data payload: 00 05 06 00 00 00 00 00
D2 // ACK packet
69 00 10 //IN packet
4B 00 00 //DATA1 packet
D2 //ACK packet
Figure 2. SETUP packet
Figure 3. Data payload format
4 GetDescriptor (Device)
This paragraph is decoded as shown in Figure 4. We will explain the decoding one by one.
Figure 4. GetDescriptor (Device)
4.1 SETUP transaction
4.1.1 SETUP packet (from host to device)
Data sequence: 2D 06 90 //2D SETUP token PID value, ADDR=6,
//ENDPOINT=0
4.1.2 DATA0 packet (from host to device)
Data sequence: C3 80 06 00 01 00 00 08 00 EB 94
//C3 DATA0 token PID value
// Data payload: 80 06 00 01 00 00 08 00
// EB 94: CRC16
//The data payload format for SETUP packet of SETUP transaction is shown in
//Figure 5 and 6. The “06” and “01” in data payload is explained in Figure 7 and 8.
Figure 5. Data format for SETUP packet of SETUP transaction
Figure 6. Standard Device Request
Figure 7. Standard Request Codes
Figure 8. Descriptor Types
4.1.3 ACK packet (from device to host)
Data: D2 //ACK packet
4.2 IN transaction
4.2.1 IN packet
Data sequence: 69 06 90 // 69: IN token pid, ADDR=06 ENDPOINT=0
4.2.2 DATA1 packet
Data sequence: 4B 12 01 00 02 00 00 00 40 6B 04 92 FF 00 01 01 02 03 01 36 DB
// For data packet format, refer to Figure 9.
// 4B: DATA1 PID value, “36 DB” is CRC16.
// The data payload decoding is described in Figure 10 and Figure 11.
Figure 9 Data Packet Format
4.2.3 ACK packet
Data: D2 //ACK packet
Figure 10. Standard Device Descriptor
Figure 11. Standard Device Descriptor (continued)
4.3 PING transaction
4.3.1 PING packet
Data sequence: B4 06 90 // PING packet has the same field as the token packet.
// It was written on page 199 of USB specification 2.0.
//B4: PING PID value, ADDR =6, ENDPOINT=0
4.3.2 ACK packet
Data: D2 //ACK packet
4.4 OUT transaction
4.4.1 OUT packet
Data sequence: E1 06 90 // E1: OUT token PID value, ADDR=6, ENDPOINT=0
4.4.2 DATA1 packet
Data sequence: 4B 00 00 //4B: Data1 token PID. Data payload is empty, “00 00”: CRC16.
4.4.3 ACK packet
Data: D2
5 GetDescriptor (Configuration)
5.1 SETUP transaction
5.1.1 SETUP packet
Data sequence: 2D 06 90 //2D SETUP token PID value, ADDR=6,
//ENDPOINT=0. Refer to Figure 2.
5.1.2 DATA0 packet
Data sequence: C3 80 06 00 02 00 00 09 00 AE 04
//C3: DATA0 PID value,
//Payload: 80 06 00 02 00 00 09 00
//Refer to Figure 6, Figure 7 and Figure 8.
//06: Descriptor, 02: Configuration,09:Data length
//AE 04: CRC16
5.1.3 ACK packet
Data D2
5.2 IN transaction
5.2.1 IN packet
Data sequence:69 06 90 //69: IN token, 06:ADDR, ENDPOINT = 0, refer to Figure 2.
5.2.2 DATA1 packet
Data sequence: 4B 09 02 20 00 01 01 00 E0 00 4A B8 //4B:DATA1 PID,
//Configuration descriptor format is shown in Figure 13 and Figure 14.
//09: data length, 02: CONFIGURATION Descriptor type.
// “0020” Total length is 32 bytes.
// The decoding of remained bytes: refer to Figure 12.
Figure 12. Configuration descriptor
5.2.3 ACK packet
Data: D2
5.3 PING transaction
5.3.1 PING packet
Data sequence: B4 06 90 // Refer to 4.3.1
5.3.2 ACK packet
Data: D2
5.4 OUT transaction
5.4.1 OUT packet
Data sequence: E1 06 90 // E1: OUT token PID value, ADDR=6, ENDPOINT=0
5.4.2 DATA1 packet
DATA sequence: 4B 00 00 //4B: DATA1 PID value, “00 00” CRC16
5.4.3 ACK packet
DATA: D2
Figure 13. Standard Configuration Descriptor Format
Figure 14. Standard Configuration Descriptor Format (Continued)
6 GetDescriptor (Configuration) (continued)
6.1 SETUP transaction
The SETUP transaction is shown in Figure 15.
Figure 15. SETUP transaction for GetSescriptor (Configuration)
6.1.1 SETUP packet
Data sequence: 2D 06 90 //2D: SETUP token PID value, ADDR=6, ENDPOINT=0
6.1.2 DATA0 packet
Data Sequence: C3 80 06 00 02 00 00 20 00 B1 94 //C3: DATA0 PID value
//Data payload: 80 06 00 02 00 00 20 00
// B1 94: CRC16
//For Data payload format, refer to Figure 5, 6, 7 and 8.
6.1.3 ACK packet
Data: D2
6.2 IN transaction
6.2.1 IN packet
Data sequence: 69 06 90 //69: IN token PID, ADDR=6, ENDPOINT=0.
6.2.2 DATA1 packet
Data sequence: 4B 09 02 20 00 01 01 00 E0 00 09 04 00 00 02 08 06 50
04 07 05 01 02 00 02 0A 07 05 81 02 00 02 0A 2D 4E
//4B: DATA1 PID
//Data payload: 09 02 20 00 01 01 00 E0 00 09 04 00 00 02 08 06 50
// 04 07 05 01 02 00 02 0A 07 05 81 02 00 02 0A
// CRC16: 2D 4E
We can divide the data payload into the following segments:
Segment1: 09 02 20 00 01 01 00 E0 00 //We can see this is the same data
//sequence as described in Chapter 5.
Segment2: 09 04 00 00 02 08 06 50 04 //Decoding is shown in Figure 16.
//Also refer to Figure 8, 19, and 20.
Segment3: 07 05 01 02 00 02 0A //Decoding is shown in Figure 17
//Also refer to Figure 8 and 21
Segment4: 07 05 81 02 00 02 0A //Decoding is shown in Figure 18
//Also refer to Figure 8 and 21
6.2.3 ACK packet
Data: D2
6.3 OUT transaction
6.3.1 OUT packet
Data sequence: E1 06 90 //E1: OUT token PID value, ADDR=6 and ENDPOINT=0
6.3.2 DATA1 packet
Data sequence: 4B 00 00 //4B: DATA1 PID value and “00 00”: CRC16
6.3.3 ACK packet
Data:D2
Figure 16. Segment2 Decoding
Figure 17. Segment3 Decoding
Figure 18. Segment4 Decoding
Figure 19 Standard Interface Descriptor
Figure 20 Standard Interface Descriptor (coninued)
Figure 21 Standard Endpoint Descriptor
7 GetDescriptor (String lanuage IDs)
7.1 SETUP transaction
7.1.1 SETUP packet
DATA sequence: 2D 06 90 //2D: SETUP token PID value, ADDR=06 and ENDPOINT=0
7.1.2 DATA0 packet
DATA sequence: C3 80 06 00 03 00 00 FF 00 D4 64 //C3: DATA0 PID value
//Data payload: 80 06 00 03 00 00 FF 00
//CRC16: D4 64
//For daa payload format, refer to Figure 5, 6, 7 and 8.
// “03” means “String” descriptor type
7.1.3 ACK packet
Data: D2
7.2 IN transaction
7.2.1 IN packet
Data sequence: 69 06 90 //69: IN PID value, ADDR=6 and ENDPOINT=0
7.2.2 DATA1 packet
Data sequence: 4B 04 03 09 04 09 78 //4B: DATA1 PID value
//Data payload: 04 03 09 04
//CRC16: 09 78
//For String Descriptor format, refer to Figure 22
// 04: length, 03: STRING Descriptor and “09 04” means “English”.
Figure 22. String Descriptor Format
7.2.3 ACK packet
Data D2
7.3 PING transaction
7.3.1 PING packet
Data sequence: B4 06 90 //B4: PING PID value,ADDR=6 and ENDPOINT=0
7.3.2 ACK packet
Data: D2
7.4 OUT transaction
7.4.1 OUT packet
Data sequence: E1 06 90 //E1: OUT PID value, ADDR=6 and ENDPOINT=0
7.4.2 DATA1 packet
Data sequence: 4B 00 00 //4B: DATA1 PID value and CRC16: 00 00
7.4.3 ACK packet
Data: D2
8 GetDescriptor (String iProduct)
8.1 SETUP transaction
8.1.1 SETUP packet
Data sequence: 2D 06 90 //2D: SETUP token PID value, ADDR=6 and ENDPOINT=0
8.1.2 DATA0 packet
Data sequence: C3 80 06 02 03 09 04 FF 00 97 DB //C3: DATA0 PID value
//Data payload: 80 06 02 03 09 04 FF 00
//CRC16: 97 DB
//For data payload format, refer to Figure 5, 6, 7 and 8.
// “02” means index 2 and “03” means String Descriptor.
// “09 04” means English and “FF 00”: data length 255 bytes.
8.1.3 ACK packet
Data: D2
8.2 IN transaction
8.2.1 IN packet
Data sequence: 69 06 90 //69: IN PID value
8.2.2 DATA1 packet
Data sequence: 4B 24 03 43 00 6F 00 6D 00 70 00 6F 00 73 00 69 00 74 00 65 00 20
00 44 00 65 00 76 00 69 00 63 00 65 00 00 00 D9 E5
//4B: DATA1 PID value
//Data payload: 24 03 43 00 6F 00 6D 00 70 00 6F 00 73 00 69
//00 74 00 65 00 20 00 44 00 65 00 76 00 69 00 63 00 65 00 00 00
//CRC16: D9 E5
//For String data payload format, refer to Figure 23.
//The data payload is encoded in UNICODE format.
//Refer to the reference A for the UNICODE standard.
//Data decoding: “Composite Device ”
8.2.3 ACK packet
Data: D2
8.3 PING transaction
8.3.1 PING packet
B4 06 90 //B4: PING PID value, ADDR=6 and ENDPOINT=0
8.3.2 ACK packet
Data: D2
8.4 OUT transaction
8.4.1 OUT packet
Data sequence: E1 06 90 //E1: OUT PID value, ADDR=6 and ENDPOINT=0
8.4.2 DATA1 packet
Data sequence: 4B 00 00 //4B: DATA1 PID value
8.4.3 ACK packet
Data: D2
Figure 23. UNICODE String Descriptor
9 GetDescriptor (String iManufacture)
9.1 SETUP transaction
9.1.1 SETUP packet
DATA sequence: 2D 06 09 //2D: SETUP token PID value, ADDR=6 and ENDPOINT=0
9.1.2 DATA0 packet
Data sequence: C3 80 06 01 03 09 04 FF 00 97 E8 //C3: DATA0 PID value
//Data payload: 80 06 01 03 09 04 FF 00
//CRC16: 97 E8
// For data payload format, refer to Figure 5, 6, 7 and 8.
// “01” means index 1 and “03” means String Descriptor.
// “09 04” means English and “FF 00”: data length 255 bytes.
9.1.3 ACK packet
Data: D2
9.2 IN transaction
9.2.1 IN packet
Data sequence: 69 06 90 //69: IN PID value, ADDR=6 and ENDPOINT=0
9.2.2 DATA1 packet
Data sequence: 4B 34 03 41 00 6D 00 65 00 72 00 69 00 63 00 61 00
6E 00 20 00 4D 00 65 00 67 00 61 00 74 00 72 00
65 00 6E 00 64 00 73 00 20 00 49 00 6E 00 63 00
2E 00 00 00 B2 2C
//4B: DATA1 PID value
//Data payload: 34 03 41 00 6D 00 65 00 72 00 69 00 63 00 61 00
//6E 00 20 00 4D 00 65 00 67 00 61 00 74 00 72 00
//65 00 6E 00 64 00 73 00 20 00 49 00 6E 00 63 00
//2E 00 00 00
//CRC16: B2 2C
//For String data payload format, refer to Figure 23.
//Data decoding: “AmericanMegatrends Inc.”
9.2.3 ACK packet
Data: D2
9.3 PING transaction
9.3.1 PING packet
Data sequence: B4 06 09 //B4: PING PID value
9.3.2 ACK packet
Data: D2
9.4 OUT transaction
9.4.1 OUT packet
Data sequence: E1 06 90 //E1: OUT PID value, ADDR=6 and ENDPOINT=0
9.4.2 DATA1 packet
Data sequence: 4B 00 00 //4B: DATA1 PID value and CRC16: 00 00
9.4.3 ACK packet
Data: D2
10 GetDescriptor (String iSerialNumber)
10.1 SETUP transaction
10.1.1 SETUP packet
DATA sequence: 2D 06 09 //2D: SETUP token PID value, ADDR=6 and ENDPOINT=0
10.1.2 DATA0 packet
Data sequence: C3 80 06 03 03 09 04 FF 00 96 0A //C3: DATA0 PID value
//Data payload: 80 06 03 03 09 04 FF 00
//CRC16: 96 0A
// For data payload format, refer to Figure 5, 6, 7 and 8.
// “03” means index 3 and “03” means String Descriptor.
// “09 04” means English and “FF 00”: data length 255 bytes.
10.1.3 ACK packet
Data: D2
10.2 IN transaction
10.2.1 IN packet
Data sequence: 69 06 90 //69: IN PID value, ADDR=6 and ENDPOINT=0
10.2.2 DATA1 packet
Data sequence: 4B 10 03 73 00 65 00 72 00 69 00 61 00 6C 00 00 00 81 7F
//4B: DATA1 PID value
//Data payload: 10 03 73 00 65 00 72 00 69 00 61 00 6C 00 00 00
//CRC16: 81 7F
//For String data payload format, refer to Figure 23.
//Data decoding: “serial ”
10.2.3 ACK packet
Data: D2
10.3 OUT transaction
10.3.1 OUT packet
Data sequence: E1 06 90 //E1: OUT PID value, ADDR=6 and ENDPOINT=0
10.3.2 DATA1 packet
Data sequence: 4B 00 00 //4B: DATA1 PID value and CRC16: 00 00
10.3.3 ACK packet
Data: D2
11 SetConfiguration (1)
11.1 SETUP tranasaction
11.1.1 SETUP packet
Data sequence: 2D 06 90 //2D: SETUP token PID value, ADDR=06 and ENDPOINT = 0
11.1.2 DATA0 packet
Data sequence: C3 00 09 01 00 00 00 00 00 27 25
//C3: DATA0 PID value
//Data payload: 00 09 01 00 00 00 00 00
//CRC16: 27 25
//For data format, refer to Figure 5, 6 and 7
// “00”: from Host to Device
// “09”: SET CONFIGURATION.
// “01”: Configuration 1.
11.1.3 ACK packet
Data: D2
11.2 IN transaction
11.2.1 IN packet
Data sequence: 69 06 90 //69: IN PID value, ADDR=6 and ENDPOINT=0
11.2.2 DATA1 packet
Data sequence: 4B 00 00 //4B: DATA1 PID value and CRC16: 00 00
11.2.3 ACK packet
Data: D2
12 GetSescriptor (String iInterface)
12.1 SETUP transaction
12.1.1 SETUP packet
Data sequence: 2D 06 90 //2D: SETUP token PID value, ADDR=6 and ENDPOINT=0
12.1.2 DATA0 packet
Data sequence: C3 80 06 04 03 09 04 FF 00 97 BD
//C3: DATA0 PID value.
//Data payload: 80 06 04 03 09 04 FF 00 97
//CRC16: 97 BD
//For data payload format, refer to Figure 5, 6, 7 and 8
//80: Device to host. 06: GetDescriptor. 04 03: String (4). 09 04:English. FF 00: Datalength=255.
12.1.2 ACK packet
Data: D2
12.2 IN transaction
12.2.1 IN packet
Data sequence: 69 06 90 //69: IN PID value, ADDR=6 and ENDPOINT=0.
12.2.2 DATA1 packet
Data sequence: 4B 16 03 49 00 6E 00 74 00 65 00 72 00
66 00 61 00 63 00 65 00 00 00 07 A2
//4B: DATA1 PID value.
//Data payload: 16 03 49 00 6E 00 74 00 65 00 72 00
// 66 00 61 00 63 00 65 00 00 00
// CRC16: 07 A2
//For String data payload format, refer to Figure 23.
//Data decoding as “Interface ”
12.2.3 ACK packet
Data: D2
12.3 PING transaction
12.3.1 PING packet
Data sequence: B4 06 90 //B4: PING PID value, ADDR=6 and ENDPOINT=0
12.3.2 ACK packet
Data: D2
12.4 OUT transaction
12.4.1 OUT packet
Data sequence: E1 06 90 //E1: OUT PID value, ADDR=6 and ENDPOINT=0
12.4.2 DATA1 packet
Data sequence: 4B 00 00
12.4.3 ACK packet
Data: D2
13 GetMaxLun
The device may implement several logical units that share common device characteristics. The host uses bCBWLUN (Command Block Wrapper (CBW)) to designate which logical unit of the device is the destination of the CBW. The Get Max LUN device request is used to determine the number of logical units supported by the device. Logical Unit Numbers on the device shall be numbered contiguously starting from LUN 0 to a maximum LUN of 15 (Fh).
To issue a Get Max LUN device request, the host shall issue a device request on the default pipe of:
bmRequestType: Class, Interface, device to host
bRequest field set to 254 (FEh)
wValue field set to 0
wIndex field set to the interface number
wLength field set to 1
The data format of GetMaxLUN is shown in Figure 24.
Figure 24. GetMax LUN
The device shall return one byte of data that contains the maximum LUN supported by the device. For example, if the device supports four LUNs then the LUNs would be numbered from 0 to 3 and the return value would be 3. If no LUN is associated with the device, the value returned shall be 0. The host shall not send a command block wrapper (CBW) to a non-existing LUN. Devices that do not support multiple LUNs may STALL this command.
13.1 SETUP transaction
13.1.1 SETUP packet
Data sequence: 2D 06 90 //2D: SETUP TOKEN PID value, ADDR=6 and ENDPOINT=0
13.1.2 DATA0 packet
Data sequence: C3 A1 FE 00 00 00 00 01 00 6A 1F
//C3: DATA0 PID value
//Data payload: A1 FE 00 00 00 00 01 00
//CRC16: 6A 1F
//For the data format, refer to Figure 24.
13.1.3 ACK packet
Data: D2
13.2 IN transaction
13.2.1 IN packet
Data sequence: 69 06 90 //69: IN PID value, ADDR=6 and ENDPOINT=0
13.2.2 DATA1 packet
Data sequence: 4B 01 81 7F //4B: DATA1 PID, data payload: 01 and CRC16: 81 7F
//It means the device supports LUN 0 and LUN 1.
13.2.3 ACK packet
Data: D2
13.3 OUT transaction
13.3.1 OUT packet
Data sequence: E1 06 90 //E1: OUT PID value, ADDR=6 and ENDPOINT=0
13.3.2 DATA1 packet
Data sequence: 4B 00 00 //4B: DATA1 PID value and CRC16: 00 00
13.3.3 ACK packet
Data: D2
14 Inquiry (Page 0)
Before we decode the Inquiry paragraph, lets talk about Command Block Wrapper (CBW). The CBW shall start on a packet boundary and shall end as a short packet with exactly 31 (1Fh) bytes transferred. Fields appear aligned to byte offsets equal to a multiple of their byte size. All subsequent data and the CSW shall start at a new packet boundary. All CBW transfers shall be ordered with the LSB (byte 0) first (little endian). Refer to the USB Specification Terms and Abbreviations for clarification.
14.1 Command Transport
14.1.1 OUT transaction
14.1.1.1 OUT packet
Data sequence: E1 86 20 //E1: OUT PID value, ADDR= 6 and ENDPOINT=0.
14.1.1.2 DATA0 packet
Data sequence: C3 55 53 42 43 01 00 00 00 24 00 00 00 80 00 06 12
00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 D6 59
//C3: DATA0 PID value
//Data payload: 55 53 42 43 01 00 00 00 24 00 00 00 80 00 06 12
//00 00 00 24 00 00 00 00 00 00 00 00 00 00 00
//CRC16: D6 59
//For data format, refer to Figure 25.
//55 53 42 43: CBW signature.
//01 00 00 00: CBW tag
//24 00 00 00: CBW data transfer length (36 bytes).
//Direction: Data in
//LUN = 0 and Command Block Length=6 bytes
//Command: 12 00 00 00 24 00
//12: Inquiry, LUN=0 and maximum number of data inquiry=36bytes.
14.1.1.3 NYET packet
Data: 96
14.2 Data Transport
14.2.1 IN transaction
14.2.1.1 IN packet
Data sequence: 69 86 20 //69: IN PID value. ADDR=6 and ENDPOINT=1.
14.2.1.2 DATA0 packet
Data sequence: C3 05 80 00 01 1F 00 00 00 41 4D 49 20 20 20 20 20 56 69 72 74 73
61 6C 20 43 44 52 4F 4D 20 20 20 31 2E 30 30 E9 12
//C3: DATA0 PID value
//Data payload: 05 80 00 01 1F 00 00 00 41 4D 49 20 20 20 20 20 56
//69 72 74 73 61 6C 20 43 44 52 4F 4D 20 20 20 31 2E 30 30
//CRC16:E9 12
// For data format, refer to Figure 27.
//05: CD-ROM device and 80: Removable Media.
//01: UFI device and 1F: additional length.
//Vendor Information: “AMI”.
//Product Identification “Virtual CDROM”.
//Produt Revision: “1.00”.
14.2.1.3 ACK packet
Data: D2
14.3 Status Transport
The CSW (Command Status Wrapper) shall start on a packet boundary and shall end as a short packet with exactly 13 (0Dh) bytes transferred. Fields appear aligned to byte offsets equal to a multiple of their byte size. All CSW transfers shall be ordered with the LSB (byte 0) first (little endian). Refer to the USB Specification Terms and Abbreviations for clarification.
14.3.1 IN transaction
14.3.1.1 IN packet
Data sequence: 69 86 20 //69: IN PID value. ADDR=6 and ENDPOINT=1.
14.3.1.2 DATA1 packet
Data sequence: 4B 55 53 42 53 01 00 00 00 00 00 00 00 00 54 22
//4B: DATA1 PID value.
//Data payload: 55 53 42 53 01 00 00 00 00 00 00 00 00
//CRC16: 54 22.
//For data format, refer to Figure 28.
//CSW data: 00 00 00 00. It means there is no difference between data
// length expected and the data length sent by device.
14.3.1.3 ACK packet
Data: D2
Figure 25. Command Block Wrapper
dCBWSignature:
Signature that helps identify this data packet as a CBW. The signature field shall contain the value 43425355h (little endian), indicating a CBW.
dCBWTag:
A Command Block Tag sent by the host. The device shall echo the contents of this field back to the host in the dCSWTag field of the associated CSW. The dCSWTag positively associates a CSW with the corresponding CBW.
dCBWDataTransferLength:
The number of bytes of data that the host expects to transfer on the Bulk-In or Bulk-Out endpoint (as indicated by the Direction bit) during the execution of this command. If this field is zero, the device and the host shall transfer no data between the CBW and the associated CSW, and the device shall ignore the value of the Direction bit in bmCBWFlags.
bmCBWFlags:
The bits of this field are defined as follows:
Bit 7 Direction – the device shall ignore this bit if the dCBWDataTransferLength field is zero, otherwise:
0 = Data-Out from host to the device,
1 = Data-In from the device to the host.
Bit 6 Obsolete. The host shall set this bit to zero.
Bits 5..0 Reserved – the host shall set these bits to zero.
bCBWLUN:
The device Logical Unit Number (LUN) to which the command block is being sent. For devices that support multiple LUNs, the host shall place into this field the LUN to which this command block is addressed. Otherwise, the host shall set this field to zero.
bCBWCBLength:
The valid length of the CBWCB in bytes. This defines the valid length of the command block. The only legal values are 1 through 16 (01h through 10h). All other values are reserved.
CBWCB:
The command block to be executed by the device. The device shall interpret the first bCBWCBLength bytes in this field as a command block as defined by the command set identified by bInterfaceSubClass. If the command set supported by the device uses command blocks of fewer than 16 (10h) bytes in length, the significant bytes shall be transferred first, beginning with the byte at offset 15 (Fh). The device shall ignore the content of the CBWCB field past the byte at offset (15 + bCBWCBLength – 1).
Figure 26. INQUIRY Command
The EVPD (Enable Vital Product Data) is set to zero.
The Logical Unit Number field specifies the logical unit (0~7) for which Inquiry data should be returned.
The Page Code field specifies which page of vital product data information the UFI device shall return to the Host Computer. The UFI device supports only Page Code zero (00h), Standard Inquiry Data.
Allocation Length specifies the maximum number of bytes of inquiry data to be returned. A value of zero will not cause an error. The UFI device shall always return the Inquiry Data, up to the number of bytes requested. The UFI device does not use the INQUIRY command to report the media status, such as media change or drive not ready. The Inquiry command shall not effect the drive unit condition or media status.
Figure 27 INQUIRY Data Format
Peripheral Device Type: identifies the device currently connected to the requested logical unit.
00h Direct-access device (floppy)
1Fh none (no FDD connected to the requested logical unit)
RMB: Removable Media Bit: this shall be set to one to indicate removable media.
ISO/ECMA: These fields shall be zero for the UFI device.
ANSI Version: must contain a zero to comply with this version of the Specification.
Response Data Format: a value of 01h shall be used for UFI device
The Additional Length field shall specify the length in bytes of the parameters. If the Allocation Length of the Command Packet is too small to transfer all of the parameters, the Additional Length shall not be adjusted to reflect the truncation. The UFI device shall set this field to 1Fh.
The Vendor Identification field contains 8 bytes of ASCII data identifying the vendor of the product. The data shall be left aligned within this field.
The Product Identification field contains 16 bytes of ASCII data as defined by the vendor. The data shall be left-aligned within this field.
The Product Revision Level field contains 4 bytes of ASCII data as defined by the vendor. The data shall be left-aligned within this field. For a UFI device, this field indicates the firmware revision number.
Figure 28. Command Status Wrapper
dCSWSignature:
Signature that helps identify this data packet as a CSW. The signature field shall contain the value 53425355h (little endian), indicating CSW.
dCSWTag:
The device shall set this field to the value received in the dCBWTag of the associated CBW.
dCSWDataResidue:
For Data-Out the device shall report in the dCSWDataResidue the difference between the amount of data expected as stated in the dCBWDataTransferLength, and the actual amount of data processed by the device. For Data-In the device shall report in the dCSWDataResidue the difference between the amount of data expected as stated in the dCBWDataTransferLength and the actual amount of relevant data sent by the device. The dCSWDataResidue shall not exceed the value sent in the
dCBWDataTransferLength.
bCSWStatus:
bCSWStatus indicates the success or failure of the command. The device shall set this byte to zero if the command completed successfully. A non-zero value shall indicate a failure during command execution according to the following table:
15 Request Sense
15.1 Command Transport
15.1.1 PINT transaction
15.1.1.1 PING packet
Data sequence: B4 86 20 //B4: PING PID value. ADDR=6 and ENDPOINT=1.
15.1.1.2 ACK packet
Data: D2
15.1.2 OUT transaction
15.1.2.1 OUT packet
Data sequence: E1 86 20 //E1: OUT PID value.
15.1.2.2 DATA1 packet
Data sequence: 4B 55 53 42 43 12 00 00 00 12 00 00 00 80 01 06 03 20 00 00
12 00 00 00 00 00 00 00 00 00 00 20 5E
//4B: DATA1 packet
//Data payload: 55 53 42 43 12 00 00 00 12 00 00 00 80 01 06 03
//20 00 00 12 00 00 00 00 00 00 00 00 00 00
//CRC16: 20 5E
//For data format decoding, refer to Figure 25.
//55 53 42 43: Signature. 12 00 00 00: Tag
//12 00 00 00: data transfer length 18 bytes.
//80: from device to host.
//01: LUN=1. 06: CBWCB length=6
//CBWCB: 03 20 00 00 12 00
//Refer to Figure 29 for this CBWCB decoding.
//03: Request sense. 20: LUN=1.
//12: allocation length =18 bytes.
15.1.2.3 NYET packet
Data:96
15.2 Data Transport
15.2.1 IN transaction
15.2.1.1 IN packet
Data sequence: 69 86 20 //IN PID value.
15.2.1.2 DATA0 packet
Data sequence: C3 70 00 06 00 00 00 00 0A 00 00 00 00 28 00 00 00 00 00 30 92
//C3: DATA0 PID value.
//Data payload: 70 00 06 00 00 00 00 0A 00 00 00 00 28 00 00 00 00 00
//CRC16: 30 92
//For data format, refer to Figure 30.
//70: current errors. 06: Unit attention (sense key).
//0A: additional sense length. 00 28: Not ready to ready transiion-
//Media changed.
15.2.1.3 ACK packet
Data: D2
15.3 Status Transport
15.3.1 IN transaction
15.3.1.1 IN packet
Data sequence: 69 86 20 //69: IN PID value. ADDR= 6 and ENDPOINT=1.
15.3.1.2 DATA1 packet
Data sequence:4B 55 53 42 53 12 00 00 00 00 00 00 00 00 8D 12
//4B: DATA1 PID value.
//Data payload: 55 53 42 53 12 00 00 00 00 00 00 00 00
//CRC16: 8D 12
//For data format, refer to Figure 28.
//CSW data residue: 00 00 00 00
15.3.1.3 ACK packet
Data D2
Figure 29. Request Sense Command
Allocation Length: specifies the maximum number of bytes of sense data the host can receive. If this is less than the size of sense data, the UFI device shall return only the number of bytes requested. However, UFI device shall not adjust the Additional Sense Length in the sense data to reflect truncation if the Allocation Length is less than the sense data available.
Description
After the processing of each command block, the UFI device sets the sense data to indicate the execution result. The sense data is output to the host in a Request Sense Standard Data Block by the UFI device in response to a REQUEST SENSE command block.
The UFI device shall preserve the sense data until it is overwritten by the execution result of the next command block. The UFI device shall not change the sense data upon completion of the REQUEST SENSE command block.
Persistent Command Block Failure and UNIT ATTENTION conditions, such as media change or power on reset, shall be cleared by the UFI device when retrieved by a REQUEST SENSE command block.
If the UFI device receives a REQUEST SENSE command while an command block is still executing, the UFI device shall first finish execution of the current command block, then process the REQUEST SENSE command.
Figure 30. Request Sense Standard Data.
Error Code: this field shall contain a value of 70h to indicate current errors.
Valid: A Valid bit of zero indicates that the Information field is not as defined in this Specification. A Valid bit of one indicates that the Information field contains valid information as defined in this Specification.
Sense Key, Additional Sense Code, and Additional Sense Code Qualifier provide a hierarchy of error or command result information. The values returned in these fields by the UFI device are those set by the previous UFI command block. A summary of these values is given in section 5
Information: This field is command-specific; it is typically used by some commands to return a logical block address denoting where an error occurred. If this field has a value, the Valid bit shall be set to one.
Additional Sense Length: the UFI device sets the value of this field to ten, to indicate that ten more bytes of sense data follow this field.
Result Values
None.
16. Mode Sense
16.1 Command Transport
16.1.1 PING transaction
16.1.1.1 PING packet
Data sequence: B4 86 20 //B4: PING PID value. ADDR=6 and ENDPOINT=1.
16.1.1.2 ACK packet
Data: D2
16.1.2 OUT transaction
16.1.2.1 OUT packet
Data sequence: E1 86 20 //E1: OUT PID value. ADDR=6 and ENDPOINT=1.
16.1.2.2 DATA 0 packet
Data sequence: C3 55 53 42 43 15 00 00 00 C0 00 00 00 80 01 06 1A 20 3F 00 C0
00 00 00 00 00 00 00 00 00 00 00 18 EE
//C3: DATA0 PID value.
//Data payload: 55 53 42 43 15 00 00 00 C0 00 00 00 80 01 06 1A 20 3F //00 C0 00 00 00 00 00 00 00 00 00 00 00
//CRC16: 18 EE.
//For data format, refer to Figure 25.
//55 53 42 43: Signature. 15 00 00 00: Tag
//C0 00 00 00: CBW data transfer length = 192 bytes.
//80: Data in from the device to the host.
//01: LUN=1 and 06: CB length =6.
//Command Block: 1A 20 3F 00 C0 00.
//For decoding of command block, refer to Figure 31.
//1A: Mode sense. 20: LUN=1. 3F: Return all pages.
//C0: Parameter List Length (192 bytes).
16.1.2.3 NYET packet
Data: 96
16.2 Data Transport
16.2.1 IN transaction
16.2.1.1 IN packet
Data sequence: 69 86 20 //69: IN PID value. ADDR=6 and ENDPOINT=1.
16.2.1.2 STALL packet
Data: 1E
16.2.2 ClearFeature (Endpoint 1 IN, Halt)
16.2.2.1 SETUP transaction
16.2.2.1.1 SETUP packet
Data sequence: 2D 06 90 //2D: SETUP token PID value. ADDR=6 and ENDPOINT=0.
16.2.2.1.2 DATA0 packet
Data sequence: C3 02 01 00 00 81 00 00 00 06 D1
//C3: DATA0 PID value.
//Data payload: 02 01 00 00 81 00 00 00
//CRC16: 06 D1.
//For data decoding, refer to Figure 5, 6, 7 and 33.
//02: Recipient is Endpoint. 01: CLEAR_FEATURE.
//00 00: Feature selector =0 (ENDPOINT_HALT).
//81 00: bit 8 (1) means from device to host.
//Bit [3:0] =1 means endpoint 1.
16.2.2.1.3 ACK packet
Data: D2
16.2.2.2 IN transaction
16.2.2.2.1 IN packet
Data sequence: 69 06 90 //69: IN PID value. ADDR=6 and ENDPOINT=0.
16.2.2.2.2 DATA1 packet
Data sequence: 4B 00 00 //4B: DATA1 PID value. CRC16: 00 00.
16.2.2.2.3 ACK packet
Data: D2
16.3 Status Transport
16.3.1 IN transaction
16.3.1.1 IN packet
Data sequence: 69 86 20 //69: IN PID value. ADDR=6 and ENDPOINT=0.
16.3.1.2 DATA0 packet
Data sequence: C3 55 53 42 43 53 15 00 00 00 C0 00 00 00 01 6A F3
//C3: DATA0 PID value.
//Data payload: 55 53 42 43 53 15 00 00 00 C0 00 00 00 01
//CRC16: 6A F3.
//For data decoding, refer to Figure 28.
//55 53 42 43: Signature. 15 00 00 00: Tag
//C0 00 00 00: Data Residue is 192 bytes.
//00 00 00 01: Command Failed.
16.3.1.3 ACK packet
Data: D2
Figure 31. Mode Sense
DBD: The Disable Block Descriptor is set to zero.
PC: the Page Control field specifies the type of mode parameters to return.
Page Code: specifies which mode page(s) to return. Specifying 3Fh requests all mode pages. In this case, mode pages shall be returned in ascending Page Code order except for mode page 00h. See the appropriate section for a description of the mode pages. If an unsupported page code is specified, the UFI device returns an error: CHECK CONDITION status; the sense key shall be set to ILLEGAL REQUEST and the additional sense code shall be set to INVALID FIELD IN COMMAND PACKET.
Allocation Length: the number of bytes in the buffer the host has allocated to hold the returned mode parameter list.
The control byte is shown in Figure 32.
Figure 32. Control Byte
All SCSI transport protocol standards shall define as mandatory the functionality needed for a logical unit to implement the NACA bit and LINK bit. The NACA (Normal ACA) bit specifies whether an auto contingent allegiance (ACA) is established if the command returns with CHECK CONDITION status. An NACA bit set to one specifies that an ACA shall be established. An NACA bit set to zero specifies that an ACA shall not be established. The actions for ACA are specified in SCSI specification 5.9.2. Actions that may be required when an ACA is not established are described in 5.9.1. All logical units shall implement support for the NACA value of zero and may support the NACA value of one (i.e., ACA). The ability to support a NACA value of one is indicated with the NORMACA bit in the standard INQUIRY data (see SPC-3). If the NACA bit is set to one but the logical unit does not support ACA, the command shall be terminated with CHECK CONDITION status, with the sense key set to ILLEGAL REQUEST, and the additional sense code set to INVALID FIELD IN CDB.
The LINK bit is used to continue the task across multiple commands. Support for the LINK bit is optional. The application client sets the LINK bit to one to specify a request for continuation of the task across two or more commands. If the LINK bit is set to one and the command completes successfully, a logical unit that supports the LINK bit shall continue the task and return a status of INTERMEDIATE or INTERMEDIATE-CONDITION MET and a service response of LINKED COMMAND COMPLETE (see 5.3). If the LINK bit is set to one and the logical unit does not support linked commands, the command shall be terminated with CHECK CONDITION status, with the sense key set to ILLEGAL REQUEST, and the additional sense code set to INVALID FIELD IN CDB.
Figue 33. Standard Feature Selectors
17 Test Unit Ready
17.1 Command Transport
17.1.1 PING transaction
17.1.1.1 PING packet
Data sequence: B4 86 20 //B4: PING PID value. ADDR= 06 and ENDPOINT= 1.
17.1.1.2 ACK packet
Data: D2
17.1.2 OUT transaction
17.1.2.1 OUT packet
Data sequence: E1 86 20 //E1: PING PID value.
17.1.2.2 DATA0 packet
Data sequence: C3 55 53 42 43 13 00 00 00 00 00 00 00 00 01 06 00 20 00 00 00 00
00 00 00 00 00 00 00 00 00 00 DB BE.
//C3: DATA0 PID value.
//Data payload: 55 53 42 43 13 00 00 00 00 00 00 00 00 01 06 00 20 00 00 00 00
//00 00 00 00 00 00 00 00 00 00
//CRC16: DB BE.
//For decoding the data payload, refer to Figure 25.
//55 53 42 43: CBW signature. 13 00 00 00: CBW tag.
//00 00 00 00: CBW data transfer length.
//00: from host to device. 01: LUN=1.
//06: Command block length=6.
//Command block: 00 20 00 00 00 00
//For command block decoding, refer to Figure 34.
//00: Test Unit Ready.
//20: LUN=1.
17.1.2.3 NYET packet
Data: 96
17.2 Status Transport
17.2.1 IN transaction
17.2.1.1 IN transaction
17.2.1.1.1 IN packet
Data sequence: 69 86 20 //69: IN PID value. ADDR=6 and ENDPOINT=1.
17.2.1.1.2 DATA0 packet
Data sequence: C3 55 53 42 53 13 00 00 00 00 00 00 00 00 80 82
//C3: DATA0 PID value.
//Data payload: 55 53 42 53 13 00 00 00 00 00 00 00 00
//CRC16: 80 82.
//For data decoding, refer to Figure 28.
//55 53 42 53: CSW sinature.
//13 00 00 00: CSW tag. 00 00 00 00: Data residue.
//00: Command passed.
17.2.1.1.3 ACK packet
Data: D2.
Figure 34. TEST UNIT READY Command
18 Medium Removal (Prevent)
18.1 Command Transport
18.1.1 PING Transaction
18.1.1.1 PING packet
Data sequence: B4 86 20 //B4: PING PID value. ADDR=6 and ENDPOINT=1.
18.1.1.2 ACK packet
Data: D2.
18.1.2 OUT transaction
18.1.2.1 OUT packet
Data sequence: E1 86 20 //E1: OUT PID value.
18.1.2.2 DATA1 packet
Data sequence: 4B 55 53 42 43 18 00 00 00 00 00 00 00 00 01 06 1E 20 00 00 01 00
00 00 00 00 00 00 00 00 00 00 51 45
//4B: DATA1 PID value.
//Data payload: 55 53 42 43 18 00 00 00 00 00 00 00 00 01 06 1E 20 00 00 01 00
//00 00 00 00 00 00 00 00 00 00
//CRC16: 51 45
//For data decoding, refer to Figure 25.
//55 53 42 43: CBW signature. 18 00 00 00: tag.
//00 00 00 00: data trasfer length. 00: from host to device.
//01: LUN=1. 06: CBL=6bytes.
//Command block: 1E 20 00 00 01 00
//For command decoding, refer to Figure 35.
//1E: Operation code of Prevent-allow medium removal.
//20: LUN=1. 00 00: Reserved. 01: Disable the remove of the medium.
18.1.2.3 NYET packet
Data: 96
18.2 Status Transport
18.2.1 IN transaction
18.2.1.1 IN packet
Data sequence: 69 86 20 //69: IN PID value. ADDR=6 and ENDPOINT=1.
18.2.1.2 DATA0 packet
Data sequence: C3 55 53 42 53 18 00 00 00 00 00 00 00 00 F3 B2
//C3: DATA0 PID value.
//Data payload: 55 53 42 53 18 00 00 00 00 00 00 00 00
//CRC16: F3 B2.
//For data decoding, refer to Figure 28.
//55 53 42 53: CSW signature. 18 00 00 00: CSW tag.
//00 00 00 00: Data residue. 00: Command passed.
18.2.1.3 ACK packet
Data: D2
Figure 35. Prevent-Allow Medium Removal Command
19 Read Capacity (Lba 0)
19.1 Command Transport
19.1.1 PING transaction
19.1.1.1 PING packet
Data sequence: B4 86 20 //B4: PING PID value. ADDR=6 and ENDPOINT=1.
19.1.1.2 ACK packet
Data: D2.
19.1.2 OUT transaction
19.1.2.1 OUT packet
Data sequence: E1 86 20 //E1: OUT PID value.
19.1.2.2 DATA1 packet
Data sequence: 4B 55 53 42 43 1A 00 00 00 08 00 00 00 80 01 0A 25 20
00 00 00 00 00 00 00 00 00 00 00 00 00 00 8B 9B
//4B: DATA1 PID value.
//Data payload: 55 53 42 43 1A 00 00 00 08 00 00 00 80 01 0A 25 20
//00 00 00 00 00 00 00 00 00 00 00 00 00 00
//CRC16: 8B 9B
//For data decoding,refer to Figure 25.
//55 53 42 43: CBW signature. 1A 00 00 00: CBW tag.
//08 00 00 00: Data transfer length. 80:from device to host.
//01: LUN=1. 0A: Command block length.
//25 20 00 00 00 00 00 00 00 00: Command Block.
//For decoding the command block,refer to Figure 36.
//25: Readcapacity command operation code.
//20: LUN=1.
19.1.2.3 NYET packet
Data: 96
19.2 Data Transport
19.2.1 IN transaction
19.2.1.1 IN packet
Data sequence: 69 86 20 //69: IN PID value. ADDR=6 and ENDPOINT=1.
19.2.1.2 DATA0 packet
Data sequence: C3 00 0 0B 3F 00 00 02 00 AB EA
//C3: DATA0 PID value.
//Data payload: 00 0 0B 3F 00 00 02 00
//CRC16: AB EA.
//For data decoding, refer to Figure 37.
//00 0 0B 3F: last logical block address=2879.
//00 00 02 00: Block length=512 bytes.
19.2.1.3 ACK packet
Data: D2.
19.3 Status Transport
19.3.1 IN transaction
19.3.1.1 IN packet
Data sequence: 69 86 20 //69: IN PID value. ADDR=6 and ENDPOINT= 1.
19.3.1.2 DATA1 packet
Data sequence: 4B 55 53 42 43 1A 00 00 00 00 00 00 00 00 EA D2
//4B: DATA1 PID value.
//Data payload: 55 53 42 43 1A 00 00 00 00 00 00 00 00
//CRC16: EA D2
//For data decoding, refer to Figure 28.
//55 53 42 43: CSW signature. 1A 00 00 00: CSW tag.
//00 00 00 00: Data residue. 00: Commandpassed.
19.3.1.3 ACK packet
Data: D2
Figure 36. Read Capacity Command.
RelAdr: This bit should be set to zero.
Logical Block Address should be set to zero.
PMI: This bit should be set to zero.
If the UFI device recognizes the formatted medium, the UFI device returns a READ CAPACITY Data to the host on the Bulk In endpoint. The UFI device sets the sense key to NO SENSE. if the command block Passed. If the medium is unformatted, unknown, or not presented, the UFI device fails the command block and sets the sense key to an appropriate value as listed sense key.
Figure 37. Read Capacity Data
The Last Logical Block Address field holds the last valid LBA for use with media access commands.
The Block Length In Bytes field specifies the length in bytes of each logical block for the given capacity descriptor.
20 Read (Lba 0)
20.1 Command Transport
20.1.1 PING transaction
20.1.1.1 PING packet
Data sequence: B4 86 20 //B4: PING PID value. ADDR=6 and ENDPOINT=1.
20.1.1.2 ACK packet
Data: D2
20.1.2 OUT transaction
20.1.2.1 OUT packet
Data sequence: E1 86 20 //E1: OUT PID value.
20.1.2.2 DATA0 packet
Data sequence: C3 55 53 42 43 1D 00 00 00 00 10 00 00 80 01 0A 28 20 00 00 00
00 00 00 08 00 00 00 00 00 00 00 C7 4F
//C3: DATA0 PID value.
//Data payload: 55 53 42 43 1D 00 00 00 00 10 00 00 80 01 0A 28 20
//00 00 00 00 00 00 08 00 00 00 00 00 00 00
//CRC16: C7 4F
//For data decoding, refer to Figure 25.
//55 53 42 43: CBW signature. 1D 00 00 00: CBW signature.
//00 10 00 00: Data transfer length=4096bytes. 80: from device to host.
//01: LUN=1. 0A: command block length=10 bytes.
//Command block: 28 20 00 00 00 00 00 00 08 00
//For decoding the command block, refer to Figure 38.
//28: Read command operation code.
//20: LUN=1. 00 00 00 00: Logic block address.
//00: reserved. 08: transfer length=8blocks.
20.1.2.3 NYET packet
Data:96
20.2 Data Transaction
The host wants to read 4096 bytes. The maximum bytes for each IN transaction are 512 bytes. To transfer 4096 bytes, 8 IN transactions are needed.
20.2.1 IN transaction
20.2.1.1 IN packet
Data sequence: 69 86 20 //69: IN PID value. ADDR=6 and ENDPOINT=1.
20.2.1.2 DATA0 packet
Data sequence:
Notes: C3: DATA0 PID value and BE 44: CRC16.
20.2.1.3 ACK
Data: D2
20.2.2 IN transaction
20.2.2.1 IN packet
Data sequence: 69 86 20 //69: IN PID value. ADDR= 6 and ENDPOINT=1.
20.2..2 DATA0 packet
Data sequence:
Notes: C3: DATA0 PID value and BE 44: CRC16.
20.2.2.3 ACK
Data: D2
20.2.3 IN transaction
The following six IN transactions are similar to the above two IN transactions.
20.2.4 IN transaction
20.2.5 IN transaction
20.2.6 IN transaction
20.2.7 IN transaction
20.2.8 IN transaction
20.3 Status Transpot
20.3.1 IN transaction
20.3.1.1 IN packet
Data sequence: 69 86 20 //69: IN PID value. ADDR=6 and ENDPOINT=1.
20.3.1.2 DATA1 packet
Data sequence: 4B 55 53 42 53 1D 00 00 00 00 00 00 00 00 CC E2.
//4B: DATA1 PID value.
//Data payload: 55 53 42 53 1D 00 00 00 00 00 00 00 00
//CRC16: CC E2.
//For data decoding, refer to Figure 28.
//55 53 42 53: SBW signature. 1D 00 00 00: SBW tag.
//00 00 00 00: Data residue. 00: Command passed.
20.3.1.3 ACK packet
Data: D2.
Figure 38 Read Command
DPO: This bit should be set to zero.
FUA: This bit should be set zero.
RelAdr: This bit should be set to zero.
Conclusion
In this USB transferring example, we showed how a virtual USB floppy device is connected to USB host to the readers. It included the initializing, configuring the USB device and the communication between the host and device. There are many different USB devices. Although all the USB devices need to follow the USB specification, the transferring procedure may be different respectively. In this example, it did not show a “write” transaction and interrupt transaction. This will not affect the completeness of the transferring. After you read this example, you will get the idea how the USB device talks to the host. You will know how to use the USB specification. For professional USB firmware writer and driver writer, USB analyzers are commonly used to capture the USB transferring data. By reading the transferring data, they can figure out the problem in their firmware or driver.
A story related to virtual USB floppy detection
This virtual floppy and virtual CD are composite devices. They are implemented in AMI BMC firmware. When we install the redhat linux 4.8 from remote side with virtual floppy and virtual CD, the redhat 4.8 linux can not recognize the virtual floppy. Because the SAS2 hard drive’s driver is contained in the virtual floppy, we can not successfully install the redhat 4.8 linux operating system. We used the USB logic analyser to capture the transferring data between the virtual floppy and the host. We figured out that the host did not send device request for LUN 1. To enable the redhat 4.8 linux OS to send request for LUN 1, we have to follow the following steps:
1.Boot to Linux
2.Start both floppy and CD redirection with either media or image.
3. Boot to linux and open the /etc/modprobe.conf file.
4. Add line options scsi_mod max_luns=10.
options scsi_mod max_luns=10
5. Do uname -r for kernel revision. Mine is “2.6.9.89.EL”.
6. mkinitrd -f /boot/initrd-2.6.9-89.EL.img 2.6.9-89.EL
This will create image initrd-2.6.9-89.EL.img
7. Make sure your grub is pointing to correct image , Look at my attached screen shot
Followed the picture and pointed to the correct image.
8. Reboot Linux.
9. Floppy should be accessible via /dev/sxx. xx is based on your system.
James Zou's Blog 
