The Data Toggle
The data toggle is a data-sequencing value that guards against lost or duplicated data. If you’re debugging a device where it appears that the proper data is transmitting on the bus but the receiver is discarding the data, chances are good that the device isn’t sending or expecting the correct data toggle.
Each endpoint maintains its own data-toggle value, which alternates between DATA0 and DATA1. Devices typically store the value in a register bit. When the host configures a device on power up or attachment, the host and device each set their data toggles to DATA0. On detecting an incoming data packet, the host or device compares the state of its data toggle with the data toggle in the received data packet. If the values match, the data packet’s receiver toggles its value for the next transaction and returns an ACK. On receiving the ACK, the data packet’s sender toggles its value for the next transaction.
The next received packet should contain a data toggle of DATA1, and again the receiver toggles its bit and returns an ACK. In additional transactions,
the data toggle continues to alternate between DATA0 and DATA1. An exception is control transfers, where the Status stage always uses DATA1.
If the receiver is busy and returns a NAK, or if the receiver detects corrupted data and returns no response, the sender doesn’t toggle its bit and tries again with the same data and data toggle.
Control transfers always use DATA0 in the Setup stage, use DATA1 in the first transaction of the Data stage, toggle the value in any additional Data-stage transactions, and use DATA1 in the Status stage. Bulk endpoints toggle the value in every transaction, resetting the data toggle only after a bus reset or completing a Set Configuration, Set Interface, or Clear Feature( ENDPOINT HALT) request.
During enumeration, the host computer uses control transfers to request the device’s descriptors, which are data structures that contain information about a device’s capabilities and requirements. The descriptors enable the host computer to select an appropriate driver for the device. The descriptors also provide information the driver needs to communicate with the device. Table 2-1 shows a set of descriptors for a mass-storage device. Every USB device must have descriptors and the ability to send the descriptors to the host on request. The USB specifications define the descriptors.
A device that can operate at both full and high speeds must support two sets of descriptors. For a mass-storage device, the values in each set can be identical except that the bulk endpoints in the high-speed descriptors have a wMaxPacketSize of 512 instead of 64. Chapter 3 has more about descriptors.
Mass Storage Requirements
In addition to what’s required for any USB device, a USB mass-storage device must have all of the following:
• An interface descriptor with the class code = 08h (mass storage).
• A bulk IN endpoint and a bulk OUT endpoint that belong to the mass-storage interface.
• A serial number stored in a string descriptor.
• Storage media.
• The ability to access the storage media’s contents using logical block addressing.
Table 2-1: Example descriptors for a full-speed mass-storage device (Sheet 1 of 2).
Table 2-1: Example descriptors for a full-speed mass-storage device (Sheet 2 of 2).
• The ability to detect and respond to the class-specific Bulk Only Mass Storage Reset and Get Max LUN requests. (A device with a single logical unit can stall the Get Max LUN request.)
• Support for the USB mass-storage class’s protocol for receiving and responding to commands required for the mass-storage interface’s subclass and peripheral device type.
The device firmware doesn’t have to support a file system. The USB transfers just read and write blocks of data at logical block addresses in the storage media. The device doesn’t have to know or care about the contents of the data blocks. The host software translates requests to read and write files and directories into requests to read and write to blocks at specific LBAs.