Universal Serial Bus Specification Revision 2.0
`
`Table 5-3 lists information about different-sized high-speed control transfers and the maximum number of
`transfers possible in a microframe. This table was generated assuming that there is one Data stage
`transaction and that the Data stage has a zero-length status stage. The table illustrates the possible power of
`two data payloads less than or equal to the allowable maximum data payload size. The table does not
`include the overhead associated with bit stuffing.
`
`Table 5-3. High-speed Control Transfer Limits
`
`Protocol Overhead
`(173 bytes)
`
`(Based on 480Mb/s and 8 bit interpacket gap, 88 bit min bus
`turnaround, 32 bit sync, 8 bit EOP: (9x4 SYNC bytes,
`9 PIO bytes, 6 EP/ADDR+CRC,6 CRC16, 8 Setup data,
`9x(1 +11) byte interpacket delay (EOP, etc.))
`
`Data
`Payload
`
`Max Bandwidth
`(bytes/second)
`
`Microframe
`Bandwidth
`per Transfer
`
`Max
`Transfers
`
`Bytes
`Remaining
`
`Bytes/
`Microframe
`Useful Data
`
`1
`
`2
`
`4
`
`8
`
`16
`
`32
`
`64
`
`344000
`
`672000
`
`1344000
`
`2624000
`
`4992000
`
`9216000
`
`15872000
`
`60000000
`
`2%
`
`2%
`
`2%
`
`2%
`
`3%
`
`3%
`
`3%
`
`I Max
`
`43
`
`42
`
`42
`
`41
`
`39
`
`36
`
`31
`
`18
`
`150
`
`66
`
`79
`
`129
`
`120
`
`153
`
`43
`
`84
`
`168
`
`328
`
`624
`
`1152
`
`1984
`
`7500
`
`5.5.5 Control Transfer Data Sequences
`Control transfers require that a Setup bus transaction be sent from the host to a device to describe the type of
`control access that the device should perform. The Setup transaction is followed by zero or more control
`Data transactions that carry the specific information for the requested access. Finally, a Status transaction
`completes the control transfer and allows the endpoint to return the status of the control transfer to the client
`software. After the Status transaction for a control transfer is completed, the host can advance to the next
`control transfer for the endpoint. As described in Section 5.5.4, each control transaction and the next
`control transfer will be moved over the bus at some Host Controller implementation-defined time.
`
`The endpoint can be busy for a device-specific time during the Data and Status transactions of the control
`transfer. During these times when the endpoint indicates it is busy (refer to Chapter 8 and Chapter 9 for
`details), the host will retry the transaction at a later time.
`
`If a Setup transaction is received by an endpoint before a previously initiated control transfer is completed,
`the device must abort the CUITent transfer/operation and handle the new control Setup transaction. A Setup
`transaction should not normally be sent before the completion of a previous control transfer. However, if a
`transfer is aborted, for example, due to errors on the bus, the host can send the next Setup transaction
`prematurely from the endpoint's perspective.
`
`43
`
`PA_0001253
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`After a halt condition is encountered or an error is detected by the host, a control endpoint is allowed to
`recover by accepting the next Setup PID; i.e., recovery actions via some other pipe are not required for
`control endpoints. For the Default Control Pipe, a device reset will ultimately be required to clear the halt
`or error condition if the next Setup PID is not accepted.
`
`The USB provides robust error detection and recovery/retransmission for errors that occur during control
`transfers. Transmitters and receivers can remain synchronized with regard to where they are in a control
`transfer and recover with minimum effort. Retransmission of Data and Status packets can be detected by a
`receiver via data retry indicators in the packet. A transmitter can reliably determine that its corresponding
`receiver has successfully accepted a transmitted packet by information returned in a handshake to the
`packet. The protocol allows for distinguishing a retransmitted packet from its original packet except for a
`control Setup packet. Setup packets may be retransmitted due to a transmission error; however, Setup
`packets cannot indicate that a packet is an original or a retried transmission.
`
`5.6 Isochronous Transfers
`In non-USB environments, isochronous transfers have the general implication of constant-rate, error(cid:173)
`tolerant transfers. In the USB environment, requesting an isochronous transfer type provides the requester
`with the following:
`
`• Guaranteed access to USB bandwidth with bounded latency
`
`• Guaranteed constant data rate through the pipe as long as data is provided to the pipe
`
`•
`
`In the case of a delivery failure due to error, no retrying of the attempt to deliver the data
`
`While the USB isochronous transfer type is designed to support isochronous sources and destinations, it is
`not required that software using this transfer type actually be isochronous in order to use the transfer type.
`Section 5 .12 presents more detail on special considerations for handling isochronous data on the USB .
`
`Isochronous Transfer Data Format
`5.6.1
`The USB imposes no data content structure on communication flows for isochronous pipes.
`
`5.6.2 Isochronous Transfer Direction
`An isochronous pipe is a stream pipe and is, therefore, always uni-directional. An endpoint description
`identifies whether a given isochronous pipe's communication flow is into or out of the host. If a device
`requires bi-directional isochronous communication flow, two isochronous pipes must be used, one in each
`direction.
`
`5.6.3 Isochronous Transfer Packet Size Constraints
`An endpoint in a given configuration for an isochronous pipe specifies the maximum size data payload that
`it can transmit or receive. The USB System Software uses this information during configuration to ensure
`that there is sufficient bus time to accommodate this maximum data payload in each (micro)frame. If there
`is sufficient bus time for the maximum data payload, the configuration is established; if not, the
`configuration is not established.
`
`The USB limits the maximum data payload size to 1,023 bytes for each full-speed isochronous endpoint.
`High-speed endpoints are allowed up to 1024-byte data payloads. A high speed, high bandwidth endpoint
`specifies whether it requires two or three transactions per microframe. Table 5-4 lists information about
`different-sized full-speed isochronous transactions and the maximum number of transactions possible in a
`frame . The table is shaded to indicate that a full-speed isochronous endpoint (with a non-zero wl'vfaxpacket
`size) must not be part of a default interface setting. The table does not include the overhead associated with
`bit stuffing.
`
`44
`
`PA_0001254
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Table 5-4. Full-speed Isochronous Transaction Limits
`
`Protocol Overhead (9 bytes)
`
`(2 SYNC bytes, 2 PIO bytes, 2 Endpoint + CRC bytes ,
`2 CRC bytes, and a 1-byte interpacket delay)
`
`Max
`Data
`Payload Bandwidth(bytes/
`second)
`
`Frame
`Bandwidth
`per Transfer
`
`Max
`Transfers
`
`Bytes
`Remaining
`
`Bytes/Frame
`Useful Data
`
`1
`
`2
`
`4
`
`8
`
`16
`
`32
`
`64
`
`128
`
`256
`
`512
`
`1023
`
`1%
`
`1%
`
`1%
`
`1%
`
`2%
`
`3%
`
`5%
`
`9%
`
`18%
`
`35%
`
`69%
`
`150000
`
`272000
`
`460000
`
`704000
`
`960000
`
`1152000
`
`1280000
`
`1280000
`
`1280000
`
`1024000
`
`1023000
`
`1500000
`
`150
`
`136
`
`115
`
`88
`
`60
`
`36
`
`20
`
`10
`
`5
`
`2
`
`1
`
`0
`
`4
`
`5
`
`4
`
`0
`
`24
`
`40
`
`130
`
`175
`
`458
`
`468
`
`I Max
`
`150
`
`272
`
`460
`
`704
`
`960
`
`1152
`
`1280
`
`1280
`
`1280
`
`1024
`
`1023
`
`1500
`
`45
`
`PA_0001255
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Table 5-5 lists information about different-sized high-speed isochronous transactions and the maximum
`number of transactions possible in a microframe. The table is shaded to indicate that a high-speed
`isochronous endpoint must not be part of a default interface setting. The table does not include the overhead
`associated with bit stuffing.
`
`Any given transaction for an isochronous pipe need not be exactly the maximum size specified for the
`endpoint. The size of a data payload is determined by the transmitter ( client software or function) and can
`vary as required from transaction to transaction. The USB ensures that whatever size is presented to the
`Host Controller is delivered on the bus. The actual size of a data payload is determined by the data
`transmitter and may be Less than the prenegotiated maximum size. Bus eITors can change the actual packet
`size seen by the receiver. However, these eITors can be detected by either CRC on the data or by knowledge
`the receiver has about the expected size for any transaction.
`
`Table 5-5. High-speed Isochronous Transaction Limits
`
`Protocol Overhead
`
`(Based on 480Mb/s and 8 bit interpacket gap, 88 bit min bus
`turnaround, 32 bit sync, 8 bit EOP: (2x4 SYNC bytes, 2 PIO
`bytes, 2 EP/ADDR+addr+CRC5, 2 CRC16, and a 2x(1 +11 ))
`byte interpacket delay (EOP, etc.))
`
`Data
`Payload
`
`Max
`Bandwidth
`(bytes/second)
`
`Microframe
`Bandwidth
`per Transfer
`
`Max
`Transfers
`
`Bytes
`Remaining
`
`Bytes/
`MicroFrame
`Useful Data
`
`1
`
`2
`
`4
`
`8
`
`16
`
`32
`
`64
`
`128
`
`256
`
`512
`
`1024
`
`2048
`
`3072
`
`1536000
`
`2992000
`
`5696000
`
`10432000
`
`17664000
`
`27392000
`
`37376000
`
`46080000
`
`51200000
`
`53248000
`
`57344000
`
`49152000
`
`49152000
`
`60000000
`
`1%
`
`1%
`
`1%
`
`1%
`
`1%
`
`1%
`
`1%
`
`2%
`
`4%
`
`7%
`
`14%
`
`28%
`
`41%
`
`192
`
`187
`
`178
`
`163
`
`138
`
`107
`
`73
`
`45
`
`25
`
`13
`
`7
`
`3
`
`2
`
`12
`
`20
`
`24
`
`2
`
`48
`
`10
`
`54
`
`30
`
`150
`
`350
`
`66
`
`1242
`
`1280
`
`192
`
`374
`
`712
`
`1304
`
`2208
`
`3424
`
`4672
`
`5760
`
`6400
`
`6656
`
`7168
`
`6144
`
`6144
`
`7500
`
`I Max
`
`46
`
`PA_0001256
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`All device default interface settings must not include any isochronous endpoints with non-zero data payload
`sizes (specified via wMaxPacketSize in the endpoint descriptor). Alternate interface settings may specify
`non-zero data payload sizes for isochronous endpoints. If the isochronous endpoints have a large data
`payload size, it is recommended that additional alternate configurations or interface settings be used to
`specify a range of data payload sizes. This increases the chance that the device can be used successfully in
`combination with other USB devices.
`
`5.6.4 Isochronous Transfer Bus Access Constraints
`Isochronous transfers can only be used by full-speed and high-speed devices.
`
`The USB requires that no more than 90% of any frame be allocated for periodic (isochronous and interrupt)
`transfers for full-speed endpoints. High-speed endpoints can allocate at most 80% of a microframe for
`periodic transfers.
`
`An isochronous endpoint must specify its required bus access period. Full-/high-speed endpoints must
`specify a desired period as (2 blntm,i-,) x F, where blnterval is in the range one to ( and including) l 6 and F is
`125 µs for high-speed and lms for full-speed. This allows full-/high-speed isochronous transfers to have
`rates slower than one transaction per (micro )frame. However, an isochronous endpoint must be prepared to
`handle poll rates faster than the one specified. A host must not issue more than 1 transaction in a
`(micro )frame for an isochronous endpoint unless the endpoint is high-speed, high-bandwidth (see below).
`An isochronous IN endpoint must return a zero-length packet whenever data is requested at a faster interval
`than the specified interval and data is not available.
`
`A high-speed endpoint can move up to 3072 bytes per micro frame ( or 192 Mb/s ). A high-speed
`isochronous endpoint that requires more than 1024 bytes per period is called a high-bandwidth endpoint. A
`high-bandwidth endpoint uses multiple transactions per microframe. A high-bandwidth endpoint must
`specify a period of lxl25 µs (i.e., a blnterval value of 1 ). See Section 5.9 for more information about the
`details of multiple transactions per microframe for high-bandwidth high-speed endpoints.
`
`Errors on the bus or delays in operating system scheduling of client software can result in no packet being
`transferred for a (micro )frame. An error indication should be returned as status to the client software in
`such a case. A device can also detect this situation by tracking SOF tokens and noticing a disturbance in the
`specified bus access period pattern.
`
`The bus frequency and (micro )frame timing limit the maximum number of successful isochronous
`transactions within a (micro)frame for any USB system to less than 151 full-speed one-byte data payloads
`and less than 193 high-speed one-byte data payloads. A Host Controller, for various implementation
`reasons, may not be able to provide the theoretical maximum number of isochronous transactions per
`(micro )frame.
`
`5.6.5 Isochronous Transfer Data Sequences
`Isochronous transfers do not support data retransmission in response to errors on the bus. A receiver can
`determine that a transmission error occurred. The low-level USB protocol does not allow handshakes to be
`returned to the transmitter of an isochronous pipe. Normally, handshakes would be returned to tell the
`transmitter whether a packet was successfully received or not. For isochronous transfers, timeliness is more
`important than correctness/retransmission, and, given the low error rates expected on the bus, the protocol is
`optimized by assuming transfers normally succeed. Isochronous receivers can determine whether they
`missed data during a (micro)frame. Also, a receiver can determine how much data was lost. Section 5.12
`describes these USB mechanisms in more detail.
`
`An endpoint for isochronous transfers never halts because there is no handshake to report a halt condition.
`Errors are reported as status associated with the IRP for an isochronous transfer, but the isochronous pipe is
`not halted in an error case. If an error is detected, the host continues to process the data associated with the
`next (micro)frame of the transfer. Only limited error detection is possible because the protocol for
`isochronous transactions does not allow per-transaction handshakes.
`
`47
`
`PA_0001257
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`5.7 Interrupt Transfers
`The interrupt transfer type is designed to support those devices that need to send or receive data infrequently
`but with bounded service periods. Requesting a pipe with an interrupt transfer type provides the requester
`with the following:
`
`• Guaranteed maximum service period for the pipe
`
`• Retry of transfer attempts at the next period, in the case of occasional delivery failure due to error on
`the bus
`
`Interrupt Transfer Data Format
`5.7.1
`The USB imposes no data content structure on communication flows for interrupt pipes.
`
`5.7.2 Interrupt Transfer Direction
`An interrupt pipe is a stream pipe and is therefore always uni-directional. An endpoint description identifies
`whether a given inte1rnpt pipe's communication flow is into or out of the host.
`
`5.7.3 Interrupt Transfer Packet Size Constraints
`An endpoint for an interrupt pipe specifies the maximum size data payload that it will transmit or receive.
`The maximum allowable interrupt data payload size is 64 bytes or less for full-speed. High-speed endpoints
`are allowed maximum data payload sizes up to 1024 bytes. A high speed, high bandwidth endpoint
`specifies whether it requires two or three transactions per microframe. Low-speed devices are limited to
`eight bytes or less maximum data payload size. This maximum applies to the data payloads of the data
`packets; i.e., the size specified is for the data field of the packet as defined in Chapter 8, not including other
`protocol-required information. The USB does not require that data packets be exactly the maximum size;
`i.e., if a data packet is less than the maximum, it does not need to be padded to the maximum size.
`
`All Host Controllers are required to support maximum data payload sizes from Oto 64 bytes for full-speed
`interrupt endpoints, from O to 8 bytes for low-speed interrupt endpoints, and from O to 1024 bytes for high(cid:173)
`speed interrupt endpoints. See Section 5 .9 for more infonnation about the details of multiple transactions
`per microframe for high bandwidth high-speed endpoints. No Host Controller is required to support larger
`maximum data payload sizes.
`
`The USB System Software determines the maximum data payload size that will be used for an inte1rnpt
`pipe during device configuration. This size remains constant for the lifetime of a device's configuration.
`The USB System Software uses the maximum data payload size determined during configuration to ensure
`that there is sufficient bus time to accommodate this maximum data payload in its assigned period. If there
`is sufficient bus time, the pipe is established; if not, the pipe is not established. However, the actual size of
`a data payload is still determined by the data transmitter and may be less than the maximum size.
`
`An endpoint must always transmit data payloads with a data field less than or equal to the endpoint's
`wMaxPacketSize value. A device can move data via an interrupt pipe that is larger than wMaxPacketSize.
`A software client can accept this data via an IRP for the interrupt transfer that requires multiple bus
`transactions without requiring an !RP-complete notification per transaction. This can be achieved by
`specifying a buffer that can hold the desired data size. The size of the buffer is a multiple of
`wMaxPacketSize with some remainder. The endpoint must transfer each transaction except the last as
`wMaxPacketSize and the last transaction is the remainder. The multiple data transactions are moved over
`the bus at the period established for the pipe.
`
`When an interrupt transfer involves more data than can fit in one data payload of the currently established
`maximum size, all data payloads are required to be maximum-sized except for the last data payload, which
`will contain the remaining data. An interrupt transfer is complete when the endpoint does one of the
`following:
`
`48
`
`PA_0001258
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`• Has transferred exactly the amount of data expected
`
`•
`
`Transfers a packet with a payload size less than wMaxPacketSize or transfers a zero-length packet
`
`When an interrupt transfer is complete, the Host Controller retires the current IRP and advances to the next
`IRP. If a data payload is received that is larger than expected, the interrupt IRP will be aborted/retired and
`the pipe will stall future IRPs until the condition is corrected and acknowledged.
`
`All high-speed device default interface settings must not include any inte1rnpt endpoints witlt a data payload
`size (specified via wMaxPacketSize in the endpoint descriptor) greater than 64 bytes. Alternate interface
`settings may specify larger data payload sizes for interrupt endpoints. If the interrupt endpoints have a large
`data payload size, it is recommended that additional configurations or alternate interface settings be used to
`specify a range of data payload sizes. This increases the chances that the device can be used successfully in
`combination with other USB devices.
`
`5.7.4 Interrupt Transfer Bus Access Constraints
`Interrupt transfers can be used by low-speed, full-speed, and high-speed devices. High-speed endpoints can
`be allocated at most 80% of a microframe for periodic transfers. The USB requires that no more than 90%
`of any frame be allocated for periodic (isochronous and interrupt) full-/low-speed transfers.
`
`The bus frequency and (micro )frame timing limit the maximum number of successful interrupt transactions
`within a (micro )frame for any USB system to less than 108 full-speed one-byte data payloads, or less than
`l O low-speed one-byte data payloads, or to less than 134 high-speed one-byte data payloads. A Host
`Controller, for various implementation reasons, may not be able to provide the above maximum number of
`interrupt transactions per (micro )frame.
`
`Table 5-6 lists information about different low-speed interrupt transactions and the maximum number of
`transactions possible in a frame. Table 5-7 lists similar information for full-speed interrupt transactions.
`Table 5-8 lists similar info1mation for high-speed interrupt transactions. The shaded portion of Table 5-8
`indicates the data payload sizes of a high-speed interrupt endpoint that must not be part of a default interface
`setting. The tables do not include the overhead associated with bit stuffing.
`
`Table 5-6. Low-speed Interrupt Transaction Limits
`
`Protocol Overhead
`(19 bytes)
`
`(5 SYNC bytes, 5 PIO bytes, 2 Endpoint + CRC bytes,
`2 CRC bytes, and a 5-byte interpacket delay)
`
`Data
`Payload
`
`Max Bandwidth
`(bytes/second)
`
`Frame
`Bandwidth
`per Transfer
`
`Max
`Transfers
`
`Bytes
`Remaining
`
`Bytes/Frame
`Useful Data
`
`1
`
`2
`
`4
`
`8
`
`11%
`
`11%
`
`12%
`
`14%
`
`9000
`
`16000
`
`32000
`
`48000
`
`187500
`
`I Max
`
`9
`
`8
`
`8
`
`6
`
`7
`
`19
`
`3
`
`25
`
`9
`
`16
`
`32
`
`48
`
`187
`
`49
`
`PA_0001259
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Table 5-7. Full-speed Interrupt Transaction Limits
`
`Protocol Overhead (13 bytes)
`
`(3 SYNC bytes, 3 PIO bytes, 2 Endpoint + CRC bytes,
`2 CRC bytes, and a 3-byte interpacket delay)
`
`Data
`Payload
`
`Max
`Bandwidth
`(bytes/second)
`
`Frame
`Bandwidth
`per Transfer
`
`Bytes
`Max
`Transfers Remaining
`
`Bytes/Frame
`Useful Data
`
`1
`
`2
`
`4
`
`8
`
`16
`
`32
`
`64
`
`1%
`
`1%
`
`1%
`
`1%
`
`2%
`
`3%
`
`5%
`
`107000
`
`200000
`
`352000
`
`568000
`
`816000
`
`1056000
`
`1216000
`
`1500000
`
`107
`
`100
`
`88
`
`71
`
`51
`
`33
`
`19
`
`2
`
`0
`
`4
`
`9
`
`21
`
`15
`
`37
`
`107
`
`200
`
`352
`
`568
`
`816
`
`1056
`
`1216
`
`1500
`
`I Max
`
`50
`
`PA_0001260
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Table 5-8. High-speed Interrupt Transaction Limits
`
`Protocol Overhead
`
`(Based on 480Mb/s and 8 bit interpacket gap, 88 bit min
`bus turnaround, 32 bit sync, 8 bit EOP: (3x4 SYNC bytes,
`3 PIO bytes, 2 EP/ADDR+CRC bytes, 2 CRC16 and a
`3x(1 +11) byte interpacket delay(EOP, etc.))
`
`Data
`Payload
`
`Max
`Bandwidth
`(bytes/second)
`
`Microframe
`Bandwidth
`per Transfer
`
`Bytes
`Max
`Transfers Remaining
`
`Bytes/
`Microframe
`Useful Data
`
`1
`
`2
`
`4
`
`8
`
`16
`
`32
`
`64
`
`128
`
`256
`
`512
`
`1024
`
`2048
`
`3072
`
`1%
`
`1%
`
`1%
`
`1%
`
`1%
`
`1%
`
`2%
`
`2%
`
`4%
`
`8%
`
`14%
`
`28%
`
`42%
`
`1064000
`
`2096000
`
`4064000
`
`7616000
`
`13440000
`
`22016000
`
`32256000
`
`40960000
`
`49152000
`
`53248000
`
`49152000
`
`49152000
`
`49152000
`
`60000000
`
`133
`
`131
`
`127
`
`119
`
`105
`
`86
`
`63
`
`40
`
`24
`
`13
`
`6
`
`3
`
`2
`
`52
`
`33
`
`7
`
`3
`
`45
`
`18
`
`3
`
`180
`
`36
`
`129
`
`1026
`
`1191
`
`1246
`
`I Max
`
`133
`
`262
`
`508
`
`952
`
`1680
`
`2752
`
`4032
`
`5120
`
`6144
`
`6656
`
`6144
`
`6144
`
`6144
`
`7500
`
`An endpoint for an interrupt pipe specifies its desired bus access period. A full-speed endpoint can specify
`a desired period from 1 ms to 255 ms. Low-speed endpoints are Limited to specifying only 10 ms to 255 ms.
`High-speed endpoints can specify a desired period (2bimcc,,i.i)xl25 µs , where blnterval is in the range 1 to
`(including) 16. The USB System Software will use this information during configuration to determine a
`period that can be sustained. The period provided by the system may be sh01ier than that desired by the
`device up to the sh01iest period defined by the USB (125 µs microframe or 1 ms frame). The client
`software and device can depend only on the fact that the host will ensure that the time duration between two
`transaction attempts with the endpoint will be no Longer than the desired period. Note that errors on the bus
`can prevent an interrupt transaction from being successfully delivered over the bus and consequently exceed
`the desired period. Also, the endpoint is only polled when the software client has an IRP for an interrupt
`transfer pending. If the bus time for performing an inte1rnpt transfer arrives and there is no IRP pending,
`the endpoint will not be given an opportunity to transfer data at that time. Once an IRP is available, its data
`will be transferred at the next allocated period.
`
`51
`
`PA_0001261
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`A high-speed endpoint can move up to 3072 bytes per micro frame ( or 192 Mb/s ). A high-speed interrupt
`endpoint that requires more than 1024 bytes per period is called a high-bandwidth endpoint. A high(cid:173)
`bandwidth endpoint uses multiple transactions per microframe. A high-bandwidth endpoint must specify a
`period of lxl25 µs (i.e., a blnterval value of 1). See Section 5.9 for more infonnation about the details of
`multiple transactions per microframe for high-bandwidth high-speed endpoints.
`
`Interrupt transfers are moved over the USB by accessing an interrupt endpoint every specified period. For
`input interrupt endpoints, the host has no way to determine whether an endpoint will source an interrupt
`without accessing the endpoint and requesting an interrupt transfer. If the endpoint has no interrupt data to
`transmit when accessed by the host, it responds with NAK. An endpoint should only provide interrupt data
`when it has an interrupt pending to avoid having a software client erroneously notified ofIRP complete. A
`zero-length data payload is a valid transfer and may be useful for some implementations.
`
`5.7.5 Interrupt Transfer Data Sequences
`Interrupt transactions may use either alternating data toggle bits, such that the bits are toggled only upon
`successful transfer completion or a continuously toggling of data toggle bits. The host in any case must
`assume that the device is obeying full handshake/retry rules as defined in Chapter 8. A device may choose
`to always toggle DATAO/DATAI PIDs so that it can ignore handshakes from the host. However, in this
`case, the client software can miss some data packets when an error occurs, because the Host Controller
`interprets the next packet as a retry of a missed packet.
`
`If a halt condition is detected on an interrupt pipe due to transmission errors or a ST ALL handshake being
`returned from the endpoint, all pending IRPs are retired. Removal of the halt condition is achieved via
`software intervention through a separate control pipe. This recovery will reset the data toggle bit to DA TAO
`for the endpoint on both the host and the device. Interrupt transactions are retried due to errors detected on
`the bus that affect a given transfer.
`
`5.8 Bulk Transfers
`The bulk transfer type is designed to support devices that need to communicate relatively large amounts of
`data at highly variable times where the transfer can use any available bandwidth. Requesting a pipe with a
`bulk transfer type provides the requester with the following:
`
`• Access to the USB on a bandwidth-available basis
`
`• Retry of transfers, in the case of occasional delivery failure due to errors on the bus
`
`• Guaranteed delivery of data but no guarantee of bandwidth or latency
`
`Bulk transfers occur only on a bandwidth-available basis. For a USB with large amounts of free bandwidth,
`bulk transfers may happen relatively quickly; for a USB with little bandwidth available, bulk transfers may
`trickle out over a relatively Long period of time.
`
`5.8.1 Bulk Transfer Data Format
`The USB imposes no data content structure on communication flows for bulk pipes.
`
`5.8.2 Bulk Transfer Direction
`A bulk pipe is a stream pipe and, therefore, always has communication flowing either into or out of the host
`for a given pipe. If a device requires bi-directional bulk communication flow, two bulk pipes must be used,
`one in each direction.
`
`52
`
`PA_0001262
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`5.8.3 Bulk Transfer Packet Size Constraints
`An endpoint for bulk transfers specifies the maximum data payload size that the endpoint can accept from
`or transmit to the bus. The USB defines the allowable maximum bulk data payload sizes to be only 8, 16,
`32, or 64 bytes for full-speed endpoints and 512 bytes for high-speed endpoints. A low-speed device must
`not have bulk endpoints. This maximum applies to the data payloads of the data packets; i.e., the size
`specified is for the data field of the packet as defined in Chapter 8, not including other protocol-required
`information.
`
`A bulk endpoint is designed to support a maximum data payload size. A bulk endpoint reports in its
`configuration information the value for its maximum data payload size. The USB does not require that data
`payloads transmitted be exactly the maximum size; i.e., if a data payload is less than the maximum, it does
`not need to be padded to the maximum size.
`
`All Host Controllers are required to have support for 8-, 16-, 32-, and 64-byte maximum packet sizes for
`full-speed bulk endpoints and 512 bytes for high-speed bulk endpoints. No Host Controller is required to
`support larger or smaller maximum packet sizes.
`
`During configuration, the USB System Software reads the endpoint's maximum data payload size and
`ensures that no data payload will be sent to the endpoint that is larger than the supported size.
`
`An endpoint must always transmit data payloads with a data field less than or equal to the endpoint's
`reported wMaxPacketSize value. When a bulk IRP involves more data than can fit in one maximum-sized
`data payload, all data payloads are required to be maximum size except for the last data payload, which will
`contain the remaining data. A bulk transfer is complete when the endpoint does one of the following:
`
`• Has transferred exactly the amount of data expected
`
`•
`
`Transfers a packet with a payload size less than wMaxPacketSize or transfers a zero-length packet
`
`When a bulk transfer is complete, the Host Controller retires the current IRP and advances to the next IRP.
`If a data payload is received that is larger than expected, all pending bulk IRPs for that endpoint will be
`aborted/retired.
`
`5.8.4 Bulk Transfer Bus Access Constraints
`Only full-speed and high-speed devices can use bulk transfers.
`
`An endpoint has no way to indicate a desired bus access frequency for a bulk pipe. The USB balances the
`bus access requirements of all bulk pipes and the specific IRPs that are pending to provide "good effort"
`delivery of data between client software and functions. Moving control transfers over the bus has priority
`over moving bulk transfers.
`
`There is no time guaranteed to be available for bulk transfers as there is for control transfers. Bulk transfers
`are moved over the bus only on a bandwidth-available basis. If there is bus time that is not being used for
`other purposes, bulk transfers will be moved over the bus. If there are bulk transfers pending for multiple
`endpoints, bulk transfers for the different endpoints are selected according to a fair access policy that is Host
`Controller implementation-dependent.
`
`All bulk transfers pending in a system contend for the same available bus time. Because of this, the USB
`System Software at its discretion can vary the bus time made available for bulk transfers to a particular
`endpoint. An endpoint and its client software cannot assume a specific rate of service for bulk transfers.
`Bus time made available to a software client and its endpoint can be changed as other devices are inserted
`into and removed from the system or also as bulk transfers are requested for other device endpoints. Client
`software cannot assume ordering between bulk and control transfers; i.e., in some situations, bulk transfers
`can be delivered ahead of control transfers.
`
`High-speed bulk OUT endpoints must support the PING flow control protocol. The details of this protocol
`are described in Section 8.5.1.
`
`53
`
`PA_0001263
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`The bus frequency and (micro)frame timing limit the maximum number of successful bulk transactions
`within a (micro )frame for any USB system to less than 72 full-speed eight-byte data payloads or less than
`14 high-speed 512-byte data payloads. Table 5-9 lists inf01mation about different-sized full-speed bulk
`transactions and the maximum number of transactions possible in a frame. The table does not include the
`overhead associated with bit stuffing. Table 5-10 lists similar information for high-speed bulk transactions.
`
`Table 5-9. Full-speed Bulk Transaction Limits
`
`Protocol Overhead (13 bytes)
`
`(3 SYNC bytes, 3 PIO bytes, 2 Endpoint+ CRC bytes,
`2 CRC bytes, and a 3-byte interpacket delay)
`
`Data
`Payload
`
`Max Bandwidth
`(bytes/second)
`
`Frame
`Bandwidth
`per Transfer
`
`Bytes
`Max
`Transfers Remaining
`
`Bytes/Frame
`Useful Data
`
`1
`
`2
`
`4
`
`8
`
`16
`
`32
`
`64
`
`1%
`
`1%
`
`1%
`
`1%
`
`2%
`
`3%
`
`5%
`
`107000
`
`200000
`
`352000
`
`568000
`
`816000
`
`1056000
`
`1216000
`
`1500000
`
`107
`
`100
`
`88
`
`71
`
`51
`
`33
`
`19
`
`2
`
`0
`
`4
`
`9
`
`21
`
`15
`
`37
`
`107
`
`200
`
`352
`
`568
`
`816
`
`1056
`
`1216
`
`1500
`
`I Max
`
`54
`
`PA_0001264
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Table 5-10. High-s