Universal Serial Bus Specification Revision 2.0
`
`11.21.2 Isochronous Split Transaction State Machines
`
`HC_cmd.datapart = alldata
`lssue_packet(HSD1, SSPLIT); -- all
`
`st1
`
`HC_cmd.datapart = enddata
`lssue_packet(HSD1, SSPLIT); -- end
`
`st3
`
`HC_cmd.datapart = begindata
`lssue_packet(HSD1, SSPLIT); -- begin
`
`HC_cmd.datapart = middata
`lssue_packet(HSD1, SSPLIT); -- middata
`
`lssue_packet(HSD1 , tokenOUT);
`
`lssue_packet(HSD1, DATAx);
`
`RespondHC(Do_next_cmd);
`
`HC_Do_ lsochOSS
`
`Figure 11-86. Isochronous OUT Start-split Transaction Host State Machine
`
`398
`
`PA_0001608
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`HSD2.PID = DATAx and HSD2.CRC16 = ok and
`split.datapart = enddata and SS_Buff.isochO and
`(SS_Buff.lastdata = middata or
`SS_Buff.lastdata = begindata)
`
`HSD2.PID = DATAx and HSD2.CRC16 = ok and
`split.datapart = middata and SS_Buff.isochO and
`(SS_Buff.lastdata = begindata or
`SS_Buff.lastdata = middata)
`
`st3
`
`st4
`
`HSD2.PID = DATAx and
`HSD2.CRC16 = ok and
`split.datapart = begindata and
`(not SS_Buff.isochO)
`
`SS_Buff.lastdata <= middata;
`SS_Buff.saw_split <= true;
`Data_into_SS_pipe;
`
`SS_Buff.isochO <= true;
`SS_Buff.lastdata <= begindata;
`SS_Buff.saw_split <= true;
`Data_into_SS_pipe;
`
`HSD2.PID = DAT Ax and HSD2.CRC16 = ok and
`
`st1
`
`se1 /se2
`
`§
`
`cket_ready(HS?2TJ
`
`HSD2.PID /= DAT Ax or
`HSD2.timeout or
`HSD2.CRC16 = bad or
`Bad_lsochOut(SS_Buff, split)
`
`Data_into_SS_pipe;
`
`TT _lsochOSS_wait
`
`["not SS_Buff.isochn ]
`/ ,- - -~
`SS_Buff.isochO
`SS_Buff.isochO <= false;
`Down_ error;
`
`I TT _Do_lsochOSS
`
`Figure 11-87. Isochronous OUT Start-split Transaction TT State Machine
`
`There is a condition in Figure 11-87 on transition se 1/se2 labeled "Bad _IsochOut". This condition is true
`when none of the conditions on transitions stl through st4 are trne. The action labeled "Down_ error"
`records an error to be indicated on the downstream facing full-speed bus for the transaction corresponding
`to this start-split.
`
`399
`
`PA_0001609
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`st1
`
`G;ue_packet;~D1, tokenlN);:J
`
`RespondHC(Do_complete);
`
`HC_Do_lsochlSS
`
`Figure 11-88. Isochronous IN Start-split Transaction Host State Machine
`
`400
`
`PA_0001610
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`HSU2.P1D = DATAx and
`HSU2.CRC16 = ok
`
`HC_Accept_data;
`
`/
`
`cd1
`
`HSU2.P1D = MDATA and
`HSU2.CRC16 = ok
`
`HC_Accept_data;
`
`ch2 ~
`
`ch3
`
`ce6/ce8
`
`- - - -~\
`
`not HC_cmd.last
`
`RespondHC(Do_next_complete);
`
`HSU2.P1D = NYET
`
`HC_cmd.last
`
`HC_lsochlCS_wait
`
`HSU2.P1D = ERR
`
`HC_lsochlCS_error
`Record_ error;
`
`(HSU2.P1D = MDATAor
`HSU2.P1D = DATAx) and
`HSU2.CRC16 = bad
`
`ErrorCount < 3
`RespondHC(Do_comp_immed_now);
`
`ErrorCount >= 3
`
`ce4
`
`ce3
`
`\ ~ - - - -~
`(HSU2.P1D /= NYET and
`HSU2.P1D /= DATAx andj
`HSU2.P1D /= MDATA and
`HSU2.P1D /= ERR) or
`HSU2.timeout
`
`HC_lsochlCS_err2
`
`ct1
`
`lssue_packet(HSD1, CSPLIT);
`
`HC_Do_lsochl CS
`
`Figure 11-89. Isochronous IN Complete-split Transaction Host State Machine
`
`In Figure 11-89, the transition "ce8" occurs when the high-speed handler responds with an MDATA to
`indicate there is more data for the full-speed transaction, but the host controller knows that this is the last
`scheduled complete-split for this endpoint for this frame. If a DATAO response from the high-speed
`handler is not received before the Last scheduled complete-split, the host controller records an error and
`proceeds to the next transaction for this endpoint (in the next frame) .
`
`401
`
`PA_0001611
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`... ~-- -----,] Oata_into_SS_pipe;
`
`I TT_Oo_lsoch lSS
`
`Figure 11-90. Isochronous IN Start-split Transaction TT State Machine
`
`ce1
`
`token.PIO/= token IN or
`token.timeout ~
`~-~ ~
`
`cd2
`
`~~~1
`CS_Buff.match.state = old J \
`
`ce2
`
`CS_B"ff.match.down_,esolt = ,_mo,eda~
`
`lssue_packet(HSU1, MOATA); ~ \
`
`CS_Buff.match.down_result = r_lastdata
`lssue_packet(HSU1, OATAx); -- OataO
`
`TT _lsochlCS_ 1
`
`CS_ B"ff.match.dowa_,esolt = ,_ traas_e~ \
`lssue_packet(HSU1, ERR);
`
`token.PIO= token IN
`
`~
`
`4
`
`h
`
`~
`
`e7
`
`CS_Buff.match.state = no_match
`~ lss"e_p~:et(HSU1, NYET);
`
`~ ~
`
`-
`
`/
`
`[ CS_Buff.match.state = match_busy
`
`~ ...
`
`,
`
`.
`
`Figure 11-91. Isochronous IN Complete-split Transaction TT State Machine
`
`TT_lsochlCS
`
`402
`
`PA_0001612
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`11.21.3 Isochronous OUT Sequencing
`The host controller and TT must ensure that errors that can occur in split transactions of an isochronous full(cid:173)
`speed transaction translate into a detectable error. For isochronous OUT split transactions, once the high(cid:173)
`speed handler has received an "SSPLIT-begin" start-split transaction token packet, the high-speed handler
`must track start-split transactions that are received for this endpoint. The high-speed handler must track that
`a start-split transaction is received each and every microframe until an "SSPLIT-end" split transaction token
`packet is received for this endpoint. If a microframe passes without the high-speed handler receiving a
`start-split for this full-speed endpoint, it must ensure that the full-speed handler forces a bitstuff error on the
`full-speed transaction. Any subsequent "SPLIT-middle" or "SPLIT-end" start-splits for the same endpoint
`must be ignored until the next non "SPLIT-middle" and non "SPLIT-end" is received (for any endpoint
`supp01ted by this TT).
`
`The start-split transaction for an isochronous OUT transaction must not include the CRCl 6 field for the full(cid:173)
`speed data packet. For a full-speed transaction, the host would compute the CRC16 of the data packet for
`the full data packet (e.g., a 1023 byte data packet uses a single CRC16 field that is computed once by the
`host controller). For a split transaction, any isochronous OUT full-speed transaction is subdivided into
`multiple stait-splits, each with a data payload of 188 bytes or less. For each of these start-splits, the host
`computes a high-speed CRC16 field for each start-split data packet. The TT high-speed handler must check
`each high-speed CRCl 6 value on each start-split. The TT full-speed handler must locally generate the
`CRC16 value for the complete full-speed data packet. Figure 11-92 shows an example of a full-speed
`isochronous OUT packet and the high-speed start-splits with their CRCI 6 fields.
`
`If there is a CRC check failure on the high-speed start-split, the high-speed handler must indicate to the full(cid:173)
`speed handler that there was an error in the stait-split for the full-speed transaction. If the transaction has
`been indicated as having a CRC failure ( or if there is a missed start-split), the full-speed handler uses the
`defined mechanism for forcing a downstream corrupted packet. If the first start-split has a CRC check
`failure, the full-speed transaction must not be started on the downstream bus.
`
`Additional high-speed start-split transactions for the same endpoint must be ignored after a CRC check fails,
`Lllltil the high-speed handler receives either an "SSPLIT-end" start-split transaction token packet for that
`endpoint or a start-split for a different endpoint.
`
`High
`Speed
`Bus
`
`'
`
`Em
`
`I ss l!I
`
`'
`'
`
`'
`'
`'
`'
`'
`
`' 2 bytes w/
`! 188 byte w
`' HS CRC16
`! HS CRC16
`!J25us microframe ~;
`
`Full
`Speed
`Bus
`
`Isoch. OUT
`data packet
`
`C
`R
`C
`1
`6
`
`y
`188 bytes 2 bytes
`Figure 11-92. Example of CRC16 Isochronous OUT Data Packet Handling
`
`403
`
`PA_0001613
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`11.21.4 Isochronous IN Sequencing
`The complete-split trnnsaction for an isochronous IN transaction must not include the CRCl 6 field for the
`full-speed data packet ( e.g., only a high-speed CRCl 6 field is used in split transactions). The TT must not
`pass the full-speed value received from the device and instead only use high-speed CRCl 6 values for
`complete-split transactions. If the full-speed handler detects a failed CRC check at the end of the data
`packet (e.g., after potentially several complete-split transactions on high-speed), the handler must use an
`ERR handshake response to reflect that e1rnr to the high-speed host controller. The host controller must
`check the CRC16 on each returned high-speed complete-split. A CRC failure (or ERR handshake) on any
`(partial) complete-split is reflected by the host controller as a CRC failure on the total full-speed transaction.
`Figure 11-93 shows an example of the relationships of the full-speed data packet and the high-speed
`complete-splits and their CRCl 6 fields.
`
`EIB
`/ :
`
`1 byte w/
`HS CRC16
`
`I
`
`High
`Speed
`Bus
`
`!I25us microframe
`
`Full
`Speed
`Bus
`
`Isoch.IN
`data packet
`~
`188 bytes
`3 bytes
`
`I cs Ill
`r+ 186 bytes w/
`
`HS CRC16
`
`EIB
`
`1 byte w/
`HS CRC16
`
`C
`R
`C
`
`6
`
`Figure 11-93. Example of CRC16 Isochronous IN Data Packet Handling
`
`11.22 TT Error Handling
`The TT has the same requirements for handling errors as a host controller or hub. In particular:
`
`•
`
`•
`
`•
`
`If the TT is receiving a packet at EOF2 of the downstream facing bus, it must disable the downstream
`facing port that is currently transmitting.
`
`If the TT is transmitting a packet near EOFl of the downstream facing bus, it must force an abnormal
`termination sequence as defined in Section 11.3.3 and stop transmitting.
`
`If the TT is going to transmit a non-periodic full-/low-speed transaction, it must determine that there is
`sufficient time remaining before EOFl to complete the transaction. This determination is based on
`normal sequencing of the packets in the transaction. Since the TT has no information about data
`payload size for INs, it must use the maximum allowed size allowed for the transfer type in its
`determination. Periodic transactions do not need to be included in this test since the microframe
`pipeline is maintained separately.
`
`11.22.1 Loss of TT Synchronization With HS SOFs
`The hub has a timer it uses for (micro)frame maintenance. It has a 1 ms frame timer when operating at full(cid:173)
`/low-speed for enforcing EOF with downstream connected devices. It has a 125 µs microframe timer when
`operating at high-speed for enforcing EOF with high-speed devices. It also uses the 125 µs microframe
`timer to create a 1 ms frame timer for enforcing EOF with downstream full-/low-speed devices when
`operating at high-speed. The hub ( micro )frame timer must always stay synchronized with host generated
`SOFs to keep the bus operating correctly
`
`404
`
`PA_0001614
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`In normal hub repeater (full- or high-speed) operation ( e.g., not involving a TT), the (micro )frame timer
`loses synchronization whenever it has missed SOFs for three consecutive microframes. While timer
`synchronization is lost, the hub does not establish upstream connectivity. Downstream connectivity is
`established normally, even when timer synchronization is lost. When the timer is synchronized, the hub
`allows upstream connectivity to be established when required. The hub is responsible for ensuring that
`there is no signaling being repeated/transmitted upstream from a device after the EOF2 point in any
`(micro)frame. The hub must not establish upstream connectivity ifit has lost (micro)frame timer
`synchronization since it no longer knows accurately where the EOF2 point is.
`
`11.22.2 TT Frame and Microframe Timer Synchronization Requirements
`When the hub is operating at high-speed and has full-/low-speed devices connected on its downstream
`facing ports ( e.g., a TT is active), the hub has additional responsibilities beyond enforcement of the (high(cid:173)
`speed) EOF2 point on its upstream facing port in every microframe. The TT must also generate full-speed
`SOFs downstream and ensure that the TT operates correctly (in bridging high-speed and full-/low-speed
`operation).
`
`A high-speed operating hub synchronizes its microframe timer to 125 µs SOFs. However, in order to
`generate full-speed downstream SOFs, it must also have a 1 ms frame timer. It generates this 1 ms frame
`timer by recognizing zeroth microframe SOPs, e.g., a high-speed SOF when the frame number value
`changes compared to SOF of the immediately previous microframe.
`
`In order to create the 1 ms frame timer, the hub must successfully receive a zeroth microframe SOF after its
`microframe timer is synchronized. In order to recognize a zeroth microframe SOF, the hub must
`successfully receive SOFs for two consecutive microframes where the frame number increments by 1 (mod
`2/\ 11 ). When the hub has done this, it knows that the second SOP is a zeroth microframe SOF and thereby
`establishes a 1 ms frame timer starting time. Note that a hub can synchronize both timers with as few as
`two SOFs if the SOFs are for microframe 7 and microframe 0, i.e., if the second SOF is a zeroth
`microframe SOP.
`
`Once the hub has synchronized its 1 ms frame timer, it can keep that timer synchronized as long as it keeps
`its 125 µs microframe timer synchronized (since it knows that every 8 microframes from the zeroth
`micro frame SOF is a 1 ms frame). In particular, the hub can keep its frame timer synchronized even if it
`misses zeroth microframe SOFs (as long as the microframe timer stays synchronized).
`
`So in summary, the hub can synchronize its 125 µs microframe timer after receiving SOFs of two
`consecutive microframes. It synchronizes its 1 ms frame timer when it receives a zeroth microframe SOF
`(and the microframe timer is synchronized). The 125 µs microframe timer loses synchronization after three
`SOPs for consecutive microframes have been missed. This also causes the 1 ms frame timer to lose
`synchronization at the same time.
`
`The TT must only generate full-speed SOFs downstream when its 1 ms frame timer is synchronized.
`
`Correct internal operation of the TT is dependent on both timers. The TT must accurately know when
`microframes occur to enforce its microframe pipeline abort/free rules. It knows this based on a
`synchronized microframe timer (for generally incrementing the microframe number) and a synchronized
`frame timer (to know when the zeroth microframe occurs).
`
`Since loss of micro frame timer synchronization immediately causes loss of frame timer synchronization, the
`TT stops normal operation once the microframe timer loses synchronization. In an error free environment,
`micro frame timer synchronization can be restored after receiving the two SOFs for the next two consecutive
`microframes (e.g., synchronization is restored at least 250 µs after synchronization loss). As long as SOFs
`are not missed, frame timer synchronization will be restored in less than 1 ms after microframe
`synchronization. Note that frame timer synchronization can be restored in a high-speed operating case in
`much less time (0.250-1.250 ms) than the 2-3 ms required in full-speed operation. Once the frame timer is
`synchronized, SOFs can be issued on downstream facing full-speed ports for the beginning of the next
`frame.
`
`405
`
`PA_0001615
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Once the hub detects loss ofmicroframe timer synchronization, its TT(s):
`
`1. Must respond to periodic complete-splits with any responses buffered in the periodic pipeline ( only
`good for at most 1 microframe of complete-splits).
`
`2. Must ab01i any buffered periodic start-split transactions in the periodic pipeline.
`
`3. Must ignore any high-speed periodic start-splits.
`
`4. Must stop issuing full-speed SOFs on downstream facing full-speed ports (and low-speed keep-alives
`on low-speed ports).
`
`5. Must not start issuing subsequent periodic full-/low-speed transactions on downstream facing full-/low-
`speed ports.
`
`6. Must respond to high-speed start-split bulk/control transactions.
`
`7. Buffered bulk/control results must respond to high-speed complete-split transactions.
`
`8. Pending bulk/control transactions must not be issued to full-/low-speed downstream facing ports. The
`TT buffers used to hold bulk/control transactions must be preserved until the microframe timer is re(cid:173)
`synchronized. (Or until a Clear_ TT_ Buffer request is received for the transaction).
`
`Note that in any case a TT must not issue transactions of any speed on downstream facing ports when its
`upstream facing port is suspended.
`
`A TT only restores normal operation on downstream facing full-/low-speed ports after both microframe and
`frame timers are synchronized. Figure Figure 11-94 summarizes the relationship between high-speed SOFs
`and the TT frame and microframe timer synchronization requirements on start-splits.
`
`For suspend sequencing of a hub, a hub will first lose microframe/frame timer synchronization at the same
`time. This will cause its TT(s) to stop issuing SOFs (which should be the only transactions keeping the
`downstream facing full-/low-speed ports out of suspend). Then the hub (along with any downstream
`devices) will enter suspend.
`
`Upon a resume, the hub will first restore its microframe timer synchronization (after high-speed transactions
`continue). Then in less than I ms (assuming no errors), the frame timer will be synchronized and the TT
`can start normal operation (including SOFs/keep-alives on downstream facing full-/low-speed ports).
`
`Microframes
`
`v,
`
`Ys
`
`(Y+ 1)0
`
`SOF
`
`No
`SOF
`
`I
`No
`SOF
`
`Lose Microframe & Frame
`Timer Synchronization,
`Ignore start-splits
`
`I
`No
`SOF
`
`•
`
`SOF
`
`SOF
`
`SOF
`
`SOF
`
`SOF
`
`SOF
`
`•
`
`Microframe Timer
`Re-synchronized;
`Frame timer unsynchronized,
`Ignore start-splits
`
`•
`
`Microframe & Frame
`Timer Synchronized,
`Accept start-splits
`
`Figure 11-94. Example Frame/Microframe Synchronization Events
`
`406
`
`PA_0001616
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`11.23 Descriptors
`Hub descriptors are derived from the general USB device framework. Hub descriptors define a hub device
`and the ports on that hub. The host accesses hub descriptors through the hub's default pipe.
`
`The USB specification (refer to Chapter 9) defines the following descriptors:
`• Device
`• Configuration
`•
`Interface
`• Endpoint
`• String ( optional)
`The hub class defines additional descriptors (refer to Section 11.23.2). In addition, vendor-specific
`descriptors are allowed in the USB device framework. Hubs support standard USB device commands as
`defined in Chapter 9.
`
`11.23.1 Standard Descriptors for Hub Class
`The hub class pre-defines certain fields in standard USB descriptors. Other fields are either
`implementation-dependent or not applicable to this class.
`
`A hub returns different descriptors based on whether it is operating at high-speed or full-/low-speed. A hub
`can report three different sets of the descriptors: one descriptor set for full-flow-speed operation and two
`sets for high-speed operation.
`
`A hub operating at full-flow-speed has a device descriptor with a bDeviceProtocol field set to zero(O) and an
`interface descriptor with a blnterfaceProtocol field set to zero(O). The rest of the descriptors are the same
`for all speeds.
`
`A hub operating at high-speed can have one of two TT organizations: single TT or multiple TT. All hubs
`must support the single TT organization. A multiple TT hub has an additional interface descriptor (with a
`corresponding endpoint descriptor). The first set of descriptors shown below must be provided by all hubs.
`A hub that has a single TT must set the bDeviceProtocol field of the device descriptor to one( 1) and the
`interface descriptor binterfaceProtocol field set to 0.
`
`A multiple TT hub must set the bDeviceProtocol field of the device descriptor to two (2). The first interface
`descriptor has the binterfaceProtocol field set to one(l). Such a hub also has a second interface descriptor
`where the binterfaceProtocol is set to two(2). When the hub is configured with an interface protocol of
`one( 1 ), it will operate as a single TT organized hub. When the hub is configured with an interface protocol
`oftwo(2), it will operate as a multiple TT organized hub. The TT organization must not be changed while
`the hub has full-flow-speed transactions in progress.
`
`407
`
`PA_0001617
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Note: For the descriptors and fields shown below, the bits in a field are organized in a little-endian fashion;
`that is, bit location O is the least significant bit and bit location 7 is the most significant bit of a byte value.
`
`Full-/Low-speed Operating Hub
`
`Device Descriptor (full-speed information):
`
`bLength
`
`bDescriptorType
`
`bcdUSB
`
`12H
`
`1
`
`0200H
`
`bDeviceClass
`
`HUB_ CLASSCODE (09H)
`
`bDeviceSubClass
`
`bDeviceProtocol
`
`bMaxPacketSizeO
`
`bNumConjigurations
`
`0
`
`0
`
`64
`
`1
`
`Device_ Qualifier Descriptor (high-speed information) :
`
`bLength
`
`bDescriptorType
`
`bcdUSB
`
`OAH
`
`6
`
`200H
`
`bDeviceClass
`
`HUB_ CLASSCODE (09H)
`
`bDeviceSubClass
`
`0
`
`bDeviceProtocol
`
`1 (for single TT) or 2 (for
`multiple TT)
`
`bMaxPacketSizeO
`
`bNumConjigurations
`
`64
`
`1
`
`Configuration Descriptor (full-speed information):
`
`bLength
`
`bDescriptorType
`
`wTotalLength
`
`bNumlnterfaces
`
`bConfiguration Value
`iConfi~uration
`bmAttributes
`bMaxPower
`
`09H
`
`2
`
`N
`
`1
`
`X
`y
`z
`The maximum amount of bus
`power the hub will consume in
`full-flow-speed configuration
`
`408
`
`PA_0001618
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Interface Descriptor:
`
`bLength
`
`09H
`
`bDescriptorType
`
`blnterfaceNumber
`
`bAlternateSetting
`
`bNumEndpoints
`
`4
`
`0
`
`0
`
`1
`
`blnterfaceClass
`
`HUB_ CLASSCODE (09H)
`
`blnterfaceSubClass
`
`blnte,jaceProtocol
`
`ilnterface
`
`0
`
`0
`
`i
`
`Endpoint Descriptor (for Status Change Endpoint):
`
`bLength
`
`bDescriptorType
`
`bEndpointAddress
`
`bmAttributes
`
`07H
`
`5
`
`Implementation-dependent;
`Bit 7: Direction = In( 1)
`
`Transfer Type = Interrupt
`(0000001 IB)
`
`wMaxPacketSize
`
`Implementation-dependent
`
`blnterval
`
`FFH (Maximum allowable
`interval)
`
`Other_ Speed_ Configuration Descriptor (High-speed information):
`
`bLength
`
`bDescriptorType
`
`wTota!Length
`
`bNumlnte1jaces
`
`bConfiguration Value
`iConfiguration
`bmAttributes
`bMaxPower
`
`09H
`
`7
`
`N
`
`l (for single TT) or 2 (for
`multiple TT)
`
`X
`y
`z
`The maximum amount of bus
`power the hub will consume in
`high-speed configuration
`
`409
`
`PA_0001619
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Interface Descriptor:
`
`bLength
`
`09H
`
`bJJescriptorType
`
`bJnterfaceNum ber
`
`bAlternateSetting
`
`bNumEndpoints
`
`4
`
`0
`
`0
`
`1
`
`bJnterfaceClass
`
`HUB_ CLASSCODE (09H)
`
`bJnterfaceSubClass
`
`0
`
`bJnterfaceProtocol
`
`0 (for single TT)
`1 (for multiple TT)
`
`ilnterface
`
`i
`
`Endpoint Descriptor (for Status Change Endpoint):
`
`bLength
`
`bJJescriptorType
`
`bEndpointAddress
`
`bmAttributes
`
`07H
`
`5
`
`Implementation-dependent;
`Bit 7: Direction= In(l)
`
`Transfer Type = Interrupt
`(0000001 lB)
`
`wMaxPacketSize
`
`Implementation-dependent
`
`blnterval
`
`FFH (Maximum allowable
`interval)
`
`Interface Descriptor (present if multiple TT hub):
`
`bLength
`
`09H
`
`bJJescriptorType
`
`bJnterfaceNumber
`
`bAlternateSetting
`
`bNumEndpoints
`
`4
`
`0
`
`0
`
`1
`
`bJnterfaceClass
`
`HUB_ CLASSCODE (09H)
`
`bJnterfaceSubClass
`
`bJnterfaceProtocol
`
`ilnterface
`
`0
`
`2
`
`i
`
`410
`
`PA_0001620
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Endpoint Descriptor (present if multiple TT hub):
`
`bLength
`
`bDescriptorType
`
`bEndpointAddress
`
`bmAttributes
`
`07H
`
`5
`
`Implementation-dependent;
`Bit 7: Direction = In( 1)
`
`Transfer Type = Interrupt
`(0000001 IB)
`
`wMaxPacketSize
`
`Implementation-dependent
`
`blnterval
`
`FFH (Maximum allowable
`interval)
`
`High-speed Operating Hub with Single TT
`
`Device Descriptor (High-speed infonnation):
`
`bLength
`
`bDescriptorType
`
`bcdVSB
`
`12H
`
`1
`
`200H
`
`bDeviceC!ass
`
`HUB_ CLASSCODE (09H)
`
`bDeviceSubClass
`
`bDeviceProtocol
`
`bMaxPacketSizeO
`
`bNumConjigurations
`
`0
`
`1
`
`64
`
`1
`
`Device_ Qualifier Descriptor (full-speed information):
`
`bLength
`
`bDescriptorType
`
`bcdVSB
`
`OAH
`
`6
`
`200H
`
`bDeviceClass
`
`HUB_ CLASSCODE (09H)
`
`bDeviceSubC!ass
`
`bDeviceProtocol
`
`bMaxPacketSizeO
`
`bNumConjigurations
`
`0
`
`0
`
`64
`
`1
`
`411
`
`PA_0001621
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Configuration Descriptor (high-speed information):
`
`bLength
`
`bJJescriptorType
`
`wTota!Length
`
`bNumlnterfaces
`
`bConfifzuration Value
`iConfifzuration
`bmAttributes
`bMaxPower
`
`09H
`
`2
`
`N
`
`I
`
`X
`y
`z
`The maximum amount of bus
`power the hub will consume in
`this configuration
`
`Interface Descriptor:
`
`bLength
`
`09H
`
`bJJescriptorType
`
`blnterfaceNumber
`
`bA!ternateSetting
`
`bNumEndpoints
`
`4
`
`0
`
`0
`
`I
`
`blnterfaceClass
`
`HUB_ CLASSCODE (09H)
`
`blnterfaceSubClass
`
`0
`
`blnterfaceProtocol
`
`0 (single TT)
`
`ilnterface
`
`i
`
`Endpoint Descriptor (for Status Change Endpoint):
`
`bLength
`
`bJJescriptorType
`
`bEndpointAddress
`
`bmAttributes
`
`07H
`
`5
`
`Implementation-dependent;
`Bit 7: Direction= In(l)
`
`Transfer Type = Interrupt
`(0000001 IB)
`
`wMaxPacketSize
`
`Implementation-dependent
`
`blnterval
`
`FFH (Maximum allowable
`interval)
`
`412
`
`PA_0001622
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Other _Speed_ Configuration Descriptor (full-speed information):
`
`bLength
`
`bDescriptorType
`
`wTota!Length
`
`bNumlnterfaces
`
`bConfi~uration Value
`iConfi~uration
`bmAttributes
`bMaxPower
`
`09H
`
`7
`
`N
`
`1
`
`X
`y
`z
`The maximum amount of bus
`power the hub will consume in
`high-speed configuration
`
`Interface Descriptor:
`
`bLength
`
`09H
`
`bDescriptorType
`
`blnterjaceNumber
`
`bA!ternateSetting
`
`bNumEndpoints
`
`4
`
`0
`
`0
`
`1
`
`blnterjaceC!ass
`
`HUB_ CLASSCODE (09H)
`
`blnterjaceSubC!ass
`
`blnterjaceProtocol
`
`ilnterface
`
`0
`
`0
`
`i
`
`Endpoint Descriptor (for Status Change Endpoint):
`
`bLength
`
`bDescriptorType
`
`bEndpointAddress
`
`bmAttributes
`
`07H
`
`5
`
`Implementation-dependent;
`Bit 7: Direction = In( 1)
`
`Transfer Type = Interrupt
`(0000001 IB)
`
`wMaxPacketSize
`
`Implementation-dependent
`
`blnterval
`
`FFH (Maximum allowable
`interval)
`
`413
`
`PA_0001623
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`High-speed Operating Hub with Multiple TTs
`
`Device Descriptor (High-speed information):
`
`bLength
`
`bDescriptorType
`
`bcdUSB
`
`12H
`
`1
`
`200H
`
`bDeviceClass
`
`HUB_ CLASSCODE (09H)
`
`bDeviceSubClass
`
`0
`
`bDeviceProtocol
`
`2 (multiple TTs)
`
`bMaxPacketSizeO
`
`bNumConjigurations
`
`64
`
`1
`
`Device_ Qualifier Descriptor (full-speed information):
`
`bLength
`
`bDescriptorType
`
`bcdUSB
`
`OAH
`
`6
`
`200H
`
`bDeviceClass
`
`HUB_ CLASSCODE (09H)
`
`bDeviceSubClass
`
`bDeviceProtocol
`
`bMaxPacketSizeO
`
`bNumConjigurations
`
`0
`
`0
`
`64
`
`1
`
`Configuration Descriptor (high-speed information):
`
`bLength
`
`bDescriptorType
`
`wTotalLength
`
`bNumlnterfaces
`
`bConffrrnration Value
`iConjif{uration
`bmAttributes
`bMaxPower
`
`09H
`
`2
`
`N
`
`1
`
`X
`y
`z
`The maximum amount of bus
`power the hub will consume in
`this configuration
`
`414
`
`PA_0001624
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Interface Descriptor:
`
`bLength
`
`09H
`
`bDescriptorType
`
`blnterfaceNumber
`
`bAlternateSetting
`
`bNumEndpoints
`
`4
`
`0
`
`0
`
`1
`
`blnterfaceClass
`
`HUB_ CLASSCODE (09H)
`
`blnterfaceSubClass
`
`0
`
`blnte,jaceProtocol
`
`1 (single TT)
`
`ilnterface
`
`i
`
`Endpoint Descriptor (for Status Change Endpoint):
`
`bLength
`
`bDescriptorType
`
`bEndpointAddress
`
`bmAttributes
`
`07H
`
`5
`
`Implementation-dependent;
`Bit 7: Direction = In( 1)
`
`Transfer Type = Interrupt
`(0000001 IB)
`
`wMaxPacketSize
`
`Implementation-dependent
`
`blnterval
`
`FFH (Maximum allowable
`interval)
`
`Interface Descriptor:
`
`bLength
`
`09H
`
`bDescriptorType
`
`blnte,jaceNun1ber
`
`bAlternateSetting
`
`bNumEndpoints
`
`4
`
`0
`
`l
`
`1
`
`blnterfaceClass
`
`HUB_ CLASSCODE (09H)
`
`blnte,jaceSubClass
`
`0
`
`blnte,jaceProtocol
`
`2 (multiple TTs)
`
`ilnterface
`
`i
`
`415
`
`PA_0001625
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Endpoint Descriptor:
`
`bLength
`
`bJJescriptorType
`
`bEndpointAddress
`
`bmAttributes
`
`07H
`
`5
`
`Implementation-dependent;
`Bit 7: Direction= In(l)
`
`Transfer Type = Interrupt
`(0000001 lB)
`
`wMaxPacketSize
`
`Implementation-dependent
`
`blnterval
`
`FFH (Maximum allowable
`interval)
`
`Other_ Speed_ Configuration Descriptor ( full-speed information) :
`
`bLength
`
`bJJescriptorType
`
`wTota!Length
`
`bJ\lumlnterfaces
`
`bConfi~uration Value
`iConfi~uration
`bmAttributes
`bMaxPower
`
`09H
`
`7
`
`N
`
`1
`
`X
`y
`z
`The maximum amount of bus
`power the hub will consume in
`high-speed configuration
`
`Interface Descriptor:
`
`bLength
`
`09H
`
`bJJescriptorType
`
`bJnterfaceJ\lumber
`
`bAlternateSetting
`
`bJ\lumEndpoints
`
`4
`
`0
`
`0
`
`l
`
`bJnterfaceClass
`
`HUB_ CLASSCODE (09H)
`
`bJnterfaceSubClass
`
`bJnterfaceProtocol
`
`ilnterface
`
`0
`
`0
`
`i
`
`416
`
`PA_0001626
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Endpoint Descriptor (for Status Change Endpoint):
`
`bLength
`
`bDescriptorType
`
`bEndpointAddress
`
`bmAttributes
`
`07H
`
`5
`
`Implementation-dependent;
`Bit 7: Direction = In( 1)
`
`Transfer Type = Interrupt
`(0000001 IB)
`
`wMaxPacketSize
`
`Implementation-dependent
`
`blnterval
`
`FFH (Maximum allowable
`interval)
`
`The hub class driver retrieves a device configuration from the USB System Software using the
`GetDescriptor() device request. The only endpoint descriptor that is returned by the GetDescriptor() request
`is the Status Change endpoint descriptor.
`
`11.23.2 Class-specific Descriptors
`
`11.23.2.1 Hub Descriptor
`Table 11-13 outlines the various fields contained by the hub descriptor.
`
`Offset
`
`Field
`
`Size
`
`Description
`
`Table 11-13. Hub Descriptor
`
`0
`
`1
`
`2
`
`3
`
`bDescLength
`
`bDescriptor Type
`
`bNbrPorts
`
`wHubCharacteristics
`
`1
`
`1
`
`1
`
`2
`
`Number of bytes in this descriptor, including this byte
`
`Descriptor Type, value: 29H for hub descriptor
`
`Number of downstream facing ports that this hub
`supports
`
`D1 ... DO: Logical Power Switching Mode
`00: Ganged power switching (all ports' power at
`once)
`Individual port power switching
`01:
`1X: Reserved. Used only on 1.0 compliant hubs
`that implement no power switching
`
`D2:
`0:
`1:
`
`Identifies a Compound Device
`Hub is not part of a compound device.
`Hub is part of a compound device.
`
`D4 ... D3: Over-current Protection Mode
`00: Global Over-current Protection. The hub
`reports over-current as a summation of all
`ports' current draw, without a breakdown of
`individual port over-current status.
`Individual Port Over-current Protection. The
`hub reports over-current on a per-port basis.
`Each port has an over-current status.
`1X: No Over-current Protection. This option is
`allowed only for bus-powered hubs that do not
`implement over-current protection.
`
`01:
`
`417
`
`PA_0001627
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Offset
`
`Field
`
`Size
`
`Description
`
`D6 ... D5: TT Think Time
`00:
`TT requires at most 8 FS bit times of inter
`transaction gap on a full-flow-speed
`downstream bus.
`TT requires at most 16 FS bit times.
`TT requires at most 24 FS bit times.
`TT requires at most 32 FS bit times.
`
`01:
`10:
`11:
`
`D7: Port Indicators Supported
`0:
`Port Indicators are not supported on its
`downstream facing ports and the
`PORT_INDICATOR request has no effect.
`Port Indicators are supported on its
`downstream facing ports and the
`PORT_INDICATOR request controls the
`indicators. See Section 11. 5. 3.
`
`1:
`
`D15 .. D8: Reserved
`
`1
`
`1
`
`Time (in 2 ms intervals) from the time the power-on
`sequence begins on a port until power is good on that
`port. The USB System Software uses this value to
`determine how long to wait before accessing a
`powered-on port.
`
`Maximum current requirements of the Hub Controller
`electronics in mA.
`
`Indicates if a port has a removable device attached.
`Variable,
`depending This field is reported on byte-granularity. Within a
`on
`byte , if no port exists for a given location, the field
`number of
`representing the port characteristics returns 0.
`ports on
`hub
`
`Bit value definition:
`OB - Device is removable.
`1 B - Device is non-removable
`
`This is a bitmap corresponding to the individual ports
`on the hub:
`Bit 0: Reserved for future use.
`Bit 1: Port 1
`Bit 2: Port 2
`
`Bitn: Port n (implementation-dependent, up to a
`maximum of 255 ports).
`This field exists for reasons of compatibility with
`software written for 1.0 compliant devices. All bits in
`this field should be set to 1B. This field has one bit for
`each port on the hub with additional pad bits, if
`necessary, to make the number of bits in the field an
`integer multiple of 8.
`
`Variable,
`depending
`on
`number of
`ports on
`hub
`
`5
`
`bPwrOn2PwrGood
`
`6
`
`7
`
`bHubContrCurrent
`
`DeviceRemovable
`
`Variable PortPwrCtr!Mask
`
`418
`
`PA_0001628
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`11.24 Requests
`
`11.24.1 Standard Requests
`Hubs have tighter constraints on request processing timing than specified in Section 9.2.6 for standard
`device