USB System Architecture

Sync Frame

This request is used by isochronous endpoints that use implicit pattern synchronization. Isochronous endpoints may need to track frame numbers in order to maintain synchronization. Isochronous endpoint transactions may vary in size according to a specific pattern that repeats. The host and endpoint must agree on which frame the repeating pattern begins. The host uses the “Sync Frame” request to specify the exact frame in which the repeating pattern begins. The data stage of the “Sync Frame” request contains the frame number in which the pattern begins. Having received the frame number, the device can start monitoring each frame number sent during the SOF.

Device Tests

High-speed Driver/Receiver Compliance Testing

The USB 2.0 specification defines a series of test modes that all high-speed devices (including the host controller and high-speed hubs) must support for compliance testing. These test modes are entered via control transfer requests that place port transceivers into the following test modes:

•Test_SE0_NAK — this mode causes the selected port (either upstream or downstream) to enter its high-speed receive state. This enables testing of output impedance, low level output voltage, and loading characteristics.

•Test_J — this mode causes the transceiver to transmit a “J” by switching current to the D+ line. This allows the D+ drive level to be tested.

•Test_K — this mode causes the transceiver to transmit a “K” by switching current to the D- line. This allows the D- drive level to be tested.

•Test_Packet — this mode causes the device to transmit a repeating string of characters. This pattern is used to perform the eye pattern checks to verify proper transmit characteristics and receiver sensitivity.

Activating Test Mode

Test mode may be activated when a device is in its default, addressed, or configured states. A control transfer is used to place the device in one of the test modes. The “Set Feature” request is delivered to the device during the setup stage of the control transfer, and the device must enter test mode no later than 3ms after the status stage of the transfer completes. Table A-8 shows the format

444

Appendix A: Standard Device Requests

of the 8 bytes of data sent to the device during the setup transaction. Note that the feature is set to “Port_Test” and the index field contains the “Test_Selector” that defines the test to be performed. To exit test mode, the device’s power must be cycled.

Table A-8: Device Request Format for Placing Device into Test Mode

The test selector values are defined in Table A-9.

Table A-9: Test Selector Values

445

USB System Architecture

446

Appendix B:

Hub Requests

Overview

Hubs must respond to a variety of USB device requests or commands. Standard requests are used for configuring the hub, for controlling the state of its USB interface, and other miscellaneous features. Hubs must also support class-spe- cific requests that are used to control specific hub and port features. All requests are issued by the host using the control transfer mechanism. Prior to configuration, a device responds to its default address of zero. This permits configuration software to request the contents of any device’s descriptors (from endpoint zero) using device address zero during configuration.

Control transfers, used to transmit device requests, consist minimally of a setup stage and a status stage, but may also include a data stage, depending on the type of request being performed. The setup stage consists of setup transactions as illustrated in Figure B-1. The eight byte data payload of a setup transaction defines the type of request being issued by the host.

Figure B-1: Format of Setup Transaction That Specifies the Device Request Being Performed

447