USB Device Controller
1597
SPNU503C – March 2018
Copyright © 2018, Texas Instruments Incorporated
Universal Serial Bus (USB)
29.3.4 Non-Isochronous IN (CPU
→
USB HOST) Transactions
Non-isochronous IN transactions refer to USB transactions in which data is moved from the CPU to the
USB host, where the USB handshaking protocols are in effect, and data transmission is ensured. These
transactions are the IN transactions that occur on control, bulk, and interrupt endpoints. These
transactions do not ensure USB bandwidth.
To provide data for an endpoint IN transaction, the CPU code writes the transmit data into the endpoint
transmit FIFO. CPU code must first wait until the USB is done with any previous TX data for the endpoint
(if data had previously been written to the TX FIFO). This must be done by proper response to endpoint-
specific transmit interrupts. When an IN transaction to the endpoint occurs, if the endpoint
STAT_FLG.FIFO_EN bit is set, the USB module sends any data that is in the endpoint TX FIFO during
the data phase. If the TX FIFO is empty and STAT_FLG.FIFO_EN is set when an IN transaction to the
endpoint occurs, a 0-byte data packet is sent.
Once the endpoint previous transmit activity is taken care of, the CPU code gains access to endpoint
FIFO and status by setting the EP_NUM.EP_SEL bit. Then the CPU can write the new transmit data to
the endpoint TX FIFO via the DATA register (being careful not to overflow the FIFO). Once all of the
transmit data has been written to the endpoint FIFO, CPU code sets the CTRL.SET_FIFO_EN bit to allow
the USB to use the endpoint TX FIFO, and then clears the EP_NUM.EP_SEL bit. The data in the endpoint
TX FIFO is sent to the USB host the next time an IN transaction to the endpoint occurs.
shows the various USB protocol conditions that can occur during non-isochronous IN
transactions. It diagrams the three phases of the IN transaction, the direction of information flow for each
phase, when endpoint-specific interrupts are generated, and the resulting STAT_FLG bits for the endpoint.
The top three cases show the normal USB handshaking: acknowledge (data sent by USB module and
received properly by the USB host), NAK (device not ready to send data to USB host), and STALL (device
in a condition where the endpoint cannot handle IN transactions). The last case shows an abnormal case
in which there is an error either in the token packet received by the core or in the data packet received by
the USB host.
29.3.4.1 Non-Isochronous IN Endpoint Handshaking
Per USB specifications for IN transactions, the USB host can provide only one of two handshakes to the
USB function during the handshake phase: ACK or no handshake at all. The first indicates successful
transfer (first case shown in
), and the second indicates that the host received a garbled data
packet (last case shown in
).
29.3.4.1.1 Acknowledged Transactions (ACK)
When the endpoint IN transaction completes on the USB bus with an ACK handshake, the endpoint
generates an endpoint-specific interrupt to the CPU (see first case in
). In response to the
endpoint interrupt, the CPU must read the EPN_STAT register to identify the endpoint causing the
interrupt, and then write a 1 to the interrupt bit to clear it. The CPU must then set EP_NUM.EP_NUM to
the endpoint number, EP_NUM.EP_DIR to 1 (to signal an IN endpoint), and EP_NUM.EP_SEL to 1, and
then read the endpoint status from STAT_FLG. STAT_FLG.ACK is set to indicate that the endpoint
received an ACK handshake from the USB host, and the TX FIFO is empty (because any data that was in
the TX FIFO was transmitted during the IN transaction).
If the CPU has more data to transmit to the USB host, it must fill the TX FIFO following the process
indicated above. It must then clear EP_NUM.EP_SEL bit. This clears the STAT_FLG.ACK bit for this
endpoint to allow next transaction status to be written into the STAT_FLG register.