USB For TM4C1294 0.07

Software design Consideration: Ethernet on TM4C129NCZAD
Doc No: Task-0002
Date: May 25,2015 Pg. 1 of 34
Software Design Consideration

USB for TM4C1294

Doc No: Task-0002
Date: May 25,2015 Pg. 2 of 34
Table of Contents
1. Scope............................................................................................................................................ 3
2. USB theory of operation ............................................................................................................ 4
3. Hardware overview .................................................................................................................. 20
4. Software requirements.............................................................................................................. 26

Doc No: Task-0002
1.
Date: May 25,2015 Pg. 3 of 34
Scope
This document provides detailed software design consideration for the Universal Serial Bus (USB) for
TM4C1294 Controller with the capabilities of operating as a Full speed device which runs at 12
Mbits/sec.
1.1
Document Overview
This document is divided into following major sections:

a. USB theory of operation
b. General requirements
c. HW overview
d. Functional Description

Doc No: Task-0002
USB theory of operation
2.1
Introduction to Universal Serial Bus

I.
Date: May 25,2015 Pg. 4 of 34
USB network supports three communication speeds.

1. Low speed which runs at 1.5 Mbits/sec (version 1.1 )
2. Full speed which runs at 12 Mbits/sec (version 1.1 )
3. High speed which runs at 480 Mbits/sec(version 2.0)
II.
The Universal Serial Bus is host controlled, there can only be one host per bus. The USB
host is responsible for undertaking all transactions and scheduling bandwidth. Data can be
sent by various transaction methods using a token-based protocol.
III.
Up to 127 devices can be connected to any one USB bus at any one given time.
IV.
USB uses 4 shielded wires of which two are power (+5v & GND). The remaining two are
twisted pair differential data signals. It uses a NRZI (Non Return to Zero Invert) encoding
scheme to send data with a sync field to synchronise the host and receiver clocks.
V.
VI.
USB supports plugnplug with dynamically loadable and unloadable drivers.

USB supports Control, Interrupt, Bulk and Isochronous transfers.
VII.
USB uses a NRZI (Non Return to Zero Invert) encoding scheme to send data with sync field
to synchronise the host and receiver clocks.
VIII.
USB supports plugnplug with dynamically loadable and unloadable drivers. The user
simply plugs the device into the bus. The host will detect this addition, interrogate the
newly inserted device and load the appropriate driver all in the time it takes the hourglass
to blink on your screen provided a driver is installed for your device.
IX.
The loading of the appropriate driver is done using a PID/VID (Product ID/Vendor ID)
combination. The VID is supplied by the USB Implementor's forum at a cost and this is seen
as another sticking point for USB.
X.
Once the user is finished, they can simply lug the cable out, the host will detect its absence
and automatically unload the driver.
XI.
USB uses a differential transmission pair for data. This is encoded using NRZI and is bit
stuffed to ensure adequate transitions in the data stream. On low and full speed devices, a
differential 1 is transmitted by pulling D+ over 2.8V with a 15K ohm resistor pulled to
ground and D- under 0.3V with a 1.5K ohm resistor pulled to 3.6V. A differential 0 on the
other hand is a D- greater than 2.8V and a D+ less than 0.3V with the same appropriate pull

Doc No: Task-0002
Date: May 25,2015 Pg. 5 of 34
down/up resistors. The receiver defines a differential 1 as D+ 200mV greater than D- and a
differential 0 as D+ 200mV less than D-.
XII.
A USB device will enter suspend when there is no activity on the bus for greater than
3.0ms. It then has a further 7ms to shutdown the device and draw no more than the
designated suspend current and thus must be only drawing the rated suspend current from
the bus 10mS after bus activity stopped.
XIII.
Standard internal wire colours are used in USB cables, making it easier to identify wires
from manufacturer to manufacturer.
Pin number
1
2
3
4
2.2
Cable color
Red
White
Green
Black
Function
Vbus (5 volt)
DD+
Ground
USB Protocols
Each USB transaction consists of a

1. Token Packet (Header defining what it expects to follow).
2. Optional Data Packet, (Containing the payload).
3. Status or handshaking Packet (Used to acknowledge transactions and to provide a means of
error correction).
Since host initiates all transactions, the first packet, also called a token is generated by the host to
describe what is to follow and whether the data transaction will be a read or write and what the devices
address and designated endpoint is.
The next packet is generally a data packet carrying the payload and is followed by an handshaking
packet, reporting if the data or token was received successfully, or if the endpoint is stalled or not
available to accept data.
2.4
Common USB Packet Fields
Data on the USBus is transmitted LSBit first. USB packets consist of the following fields,
a) Sync
All packets must start with a sync field. The sync field is 8 bits long at low and full speed or 32
bits long for high speed and is used to synchronize the clock of the receiver with that of the
transmitter. The last two bits indicate where the PID fields starts.

Doc No: Task-0002
Date: May 25,2015 Pg. 6 of 34
b) PID
PID stands for Packet ID. This field is used to identify the type of packet that is being sent. The
following table shows the possible values.
c) ADDR
The address field specifies which device the packet is designated for. Being 7 bits in length
allows for 127 devices to be supported. Address 0 is not valid, as any device which is not yet
assigned an address must respond to packets sent to address zero.
d) ENDP
The endpoint field is made up of 4 bits, allowing 16 possible endpoints. Low speed devices,
however can only have 2 additional endpoints on top of the default pipe. (4 endpoints max).
e) CRC
Cyclic Redundancy Checks are performed on the data within the packet payload. All token
packets have a 5 bit CRC while data packets have a 16 bit CRC.
f) EOP
End of packet. Signalled by a Single Ended Zero (SE0) for approximately 2 bit times followed
by a J for 1 bit time.
2.3
USB Packet Types

Doc No: Task-0002
Date: May 25,2015 Pg. 7 of 34
USB has four different packet types.,

1. Token Packets : indicate the type of transaction to follow.
There are three types of token packets,
a) In - Informs the USB device that the host wishes to read information.
b) Out - Informs the USB device that the host wishes to send information.
c) Setup - Used to begin control transfers.
Token Packets must conform to the following format,
Sync
PID
ADDR
ENDP
CRC5
EOP
2. Data Packets: data packets contain the payload

There are two types of data packets each capable of transmitting up to 1024 bytes of data.
a) Data0
b) Data1
High Speed mode defines another two data PIDs, DATA2 and MDATA.
Data packets have the following format,
Sync
PID
Data
CRC16
EOP
a)
Maximum data payload size for full-speed devices is 1023 bytes.
b)
Data must be sent in multiples of bytes.
3. Handshake Packets: are used for acknowledging data or reporting errors

There are three types of handshake packets which consist simply of the PID
a)
ACK - Acknowledgment that the packet has been successfully received.
b)
NAK - Reports that the device temporary cannot send or received data. Also
used during interrupt transactions to inform the host there is no data to send.
c)
STALL - The device finds its in a state that it requires intervention from the
host.
Handshake Packets have the following format,

Sync
PID
4. Start of Frame Packets: indicate the start of a new frame.
EOP

Doc No: Task-0002
Date: May 25,2015 Pg. 8 of 34
The SOF packet consisting of an 11-bit frame number is sent by the host every 1ms 500ns on
a full speed bus or every 125 s 0.0625 s on a high speed bus.
Sync
2.5
PID
Frame Number
CRC5
EOP
USB Functions
As shown in the figure most functions will have a series of buffers, typically 8 bytes long. Each buffer
will belong to an endpoint - EP0 IN, EP0 OUT etc. for example, the host sends a device descriptor
request. The function hardware will read the setup packet and determine from the address field whether
the packet is for itself, and if so will copy the payload of the following data packet to the appropriate
endpoint buffer dictated by the value in the endpoint field of the setup token. It will then send a
handshake packet to acknowledge the reception of the byte and generate an internal interrupt within the
semiconductor/micro-controller for the appropriate endpoint signifying it has received a packet. This is
typically all done in hardware.
The software now gets an interrupt, and should read the contents of the endpoint buffer and parse the
device descriptor request.
2.6
Endpoints

Doc No: Task-0002
Date: May 25,2015 Pg. 9 of 34
Endpoints can be described as sources or sinks of data. As the bus is host centric, endpoints occur at the
end of the communications channel at the USB function. At the software layer, your device driver may
send a packet to your devices EP1 for example. As the data is flowing out from the host, it will end up
in the EP1 OUT buffer. Your firmware will then at its leisure read this data. If it wants to return data,
the function cannot simply write to the bus as the bus is controlled by the host. Therefore it writes data
to EP1 IN which sits in the buffer until such time when the host sends a IN packet to that endpoint
requesting the data. Endpoints can also be seen as the interface between the hardware of the function
device and the firmware running on the function device.
All devices must support endpoint zero. This is the endpoint which receives all of the devices control
and status requests during enumeration and throughout the duration while the device is operational on
the bus.
2.7
Transfer Types
Each USB transfer consists of one or more transactions that carry data to or from an endpoint. There
are 4 types of transfers defined for the endpoints.
1. Control Transfers
2. Interrupt Transfers
3. Isochronous Transfers
4. Bulk Transfers
Control Transfers
I.
Control transfers are typically used for command and status operations. They are essential to set
up a USB device with all enumeration functions being performed using control transfers.
II.
The packet length of control transfers in high speed devices allow a packet size of 16, 32 or 64
bytes and full speed devices must have a packet size of 64 bytes.
III.
A control transfer can have up to three stages.

A. The Setup Stage is where the request is sent. This consists of three packets. The setup token
is sent first which contains the address and endpoint number. The data packet is sent next
and always has a PID type of data0 and includes a setup packet which details the type of
request. The last packet is a handshake used for acknowledging successful receipt or to
indicate an error.

Doc No: Task-0002
Date: May 25,2015 Pg. 10 of 34
B. The optional Data Stage consists of one or multiple IN or OUT transfers. The setup request
indicates the amount of data to be transmitted in this stage. The data stage has two different
scenarios depending upon the direction of data transfer.
1. IN: When the host is ready to receive control data it issues an IN Token. If the function
receives the IN token with an error, then it ignores the packet. If the token was received
correctly, the device can either reply with a DATA packet containing the control data to
be sent, a stall packet indicating the endpoint has had a error or a NAK packet indicating
to the host that the endpoint is working, but temporarily has no data to send.
2. OUT: When the host needs to send the device a control data packet, it issues an OUT
token followed by a data packet containing the control data as the payload. If any part of
the OUT token or data packet is corrupt then the function ignores the packet. If the
function's endpoint buffer was empty and it has clocked the data into the endpoint buffer
it issues an ACK informing the host it has successfully received the data. If the endpoint
buffer is not empty due to processing of the previous packet, then the function returns a
NAK. However if the endpoint has had a error and its halt bit has been set, it returns a
STALL.

Doc No: Task-0002
Date: May 25,2015 Pg. 11 of 34
C Status Stage reports the status of the overall request and this once again varies due to
direction of transfer. Status reporting is always performed by the function.
1. IN: If the host sent IN token(s) during the data stage to receive data, then the host must
acknowledge the successful receipt of this data. This is done by the host sending an OUT
token followed by a zero length data packet. The function can now report its status in the
handshaking stage. An ACK indicates the function has completed the command is now
ready to accept another command. If an error occurred during the processing of this
command, then the function will issue a STALL. However if the function is still processing,
it returns a NAK indicating to the host to repeat the status stage later.
2. OUT: If the host sent OUT token(s) during the data stage to transmit data, the function
will acknowledge the successful receipt of data by sending a zero length packet in response
to an IN token. However if an error occurred, it should issue a STALL or if it is still busy
processing data, it should issue a NAK asking the host to retry the status phase later.

Doc No: Task-0002
Date: May 25,2015 Pg. 12 of 34
Interrupt Transfers
I. Interrupt transfers are useful when data has to transfer without delay. Typical applications include
keyboards, pointing devices, game controllers and hub status reports.
II. The maximum data payload size for low-speed devices is 8 bytes, full speed devices can have
maximum payload size of 64 bytes and maximum payload size of high speed devices is 1024 bytes.
III. Under Interrupt transfers if a device requires the attention of the host, it must wait until the host
polls it before it can report that it needs urgent attention.
A. IN: The host will periodically poll the interrupt endpoint. This rate of polling is specified in
the endpoint descriptor. Each poll will involve the host sending an IN Token. If the IN token is
corrupt, the function ignores the packet and continues monitoring the bus for new tokens. If an
interrupt has been queued by the device, the function will send a data packet containing data
relevant to the interrupt when it receives the IN Token. Upon successful receipt at the host, the
host will return an ACK. However if the data is corrupted, the host will return no status. If an
error has occurred on this endpoint, a STALL is sent in reply to the IN token instead.
B. OUT: When the host wants to send the device interrupt data, it issues an OUT token
followed by a data packet containing the interrupt data. If any part of the OUT token or data
packet is corrupt then the function ignores the packet. If the function's endpoint buffer was

Doc No: Task-0002
Date: May 25,2015 Pg. 13 of 34
empty and it has clocked the data into the endpoint buffer it issues an ACK informing the host it
has successfully received the data. If the endpoint buffer is not empty due to processing of a
previous packet, then the function returns a NAK. However if an error occurred with the
endpoint consequently and its halt bit has been set, it returns a STALL.
Bulk Transfers
I. Bulk transfers are useful for transferring data when time isnt critical. Uses for bulk transfers
include sending data to a printer or an image generated from a scanner. Bulk transfers provide error
correction which ensures data is transmitted and received without error.
II. A Bulk transfer can send large amounts of data without clogging the bus because the transfers defer
to the other transfer types, waiting until time is available.
III. For full speed endpoints, the maximum bulk packet size is 16, 32 or 64 bytes long. For high speed
endpoints, the maximum packet size can be up to 512 bytes long.
A. IN: When the host is ready to receive bulk data it issues an IN Token. If the function
receives the IN token with an error, it ignores the packet. If the token was received correctly, the
function can either reply with a DATA packet containing the bulk data to be sent, or a stall
packet indicating the endpoint has had a error or a NAK packet indicating to the host that the
endpoint is working, but temporary has no data to send.

Doc No: Task-0002
Date: May 25,2015 Pg. 14 of 34
B. When the host wants to send the function a bulk data packet, it issues an OUT token
followed by a data packet containing the bulk data. If any part of the OUT token or data packet
is corrupt then the function ignores the packet. If the function's endpoint buffer was empty and
it has clocked the data into the endpoint buffer it issues an ACK informing the host it has
successfully received the data. If the endpoint buffer is not empty due to processing a previous
packet, then the function returns an NAK. However if the endpoint has had an error and its halt
bit has been set, it returns a STALL.
Isochronous Transfers
I. Isochronous transfers are streaming, real-time transfers that are useful when data must arrive at a
constant rate or within a specific time limit and occasional errors are tolerable. Examples of uses for
isochronous transfers include encoded voice and music to be played in real time.
II. This can be up to a maximum of 1023 bytes for a full speed device and 1024 bytes for a high speed
device.
III. The following diagram shows the format of an Isochronous IN and OUT transaction. Isochronous

Doc No: Task-0002
Date: May 25,2015 Pg. 15 of 34
transactions do not have a handshaking stage and cannot report errors or STALL/HALT conditions.
2.7
USB Descriptors
All USB devices have a hierarchy of descriptors which describe to the host information such as what
the device is, who makes it, what version of USB it supports, how many ways it can be configured, the
number of endpoints and their types etc
The more common USB descriptors are:
1. Device Descriptors
2. Configuration Descriptors
3. Interface Descriptors
4. Endpoint Descriptors
5. String Descriptors
USB devices can only have one device descriptor. The device descriptor includes information such as
what USB revision the device complies to, the Product and Vendor IDs used to load the appropriate
drivers and the number of possible configurations the device can have. The number of configurations
indicate how many configuration descriptors branches are to follow.
The configuration descriptor specifies values such as the amount of power this particular configuration
uses, if the device is self or bus powered and the number of interfaces it has. When a device is
enumerated, the host reads the device descriptors and can make a decision of which configuration to
enable. It can only enable one configuration at a time.
The configuration settings are not limited to power differences. Each configuration could be powered
in the same way and draw the same current, yet have different interface or endpoint combinations.
However it should be noted that changing the configuration requires all activity on each endpoint to
stop. While USB offers this flexibility, very few devices have more than 1 configuration.

Doc No: Task-0002
Date: May 25,2015 Pg. 16 of 34
The more common USB descriptors are

A. Device descriptor
1. The device descriptor is the first descriptor the host reads on device attachment. The
descriptor contains information about the host needs to retrieve additional information
from the device.
2. It specifies some basic, yet important information about the device such as the
supported USB version, maximum packet size, vendor and product IDs and the number
of possible configurations the device can have.
3. A host retrieves a device descriptor by sending a Get Descriptor request.

Doc No: Task-0002
Date: May 25,2015 Pg. 17 of 34
B. Configuration descriptor
1. The configuration descriptor contains information about the devices power
requirements and the number of interfaces it supports.
2. Each configuration descriptor has subordinate descriptors, including one or more
interface descriptors and optional endpoint descriptors.
C. Interface descriptor
1. The interface descriptor provides information about a function or feature that a
device implements. The descriptor contains class, subclass, and protocol information
and the number of endpoints the interface uses.
2. A configuration can have multiple interfaces that are active at the same time. Each
interface has its own interface descriptor and subordinate descriptors.

Doc No: Task-0002
Date: May 25,2015 Pg. 18 of 34
D. Endpoint descriptor
1. The endpoint descriptor transfers the configuration details of each endpoint
supported in a given interface. The descriptor carries details of the transfer type
supported, the maximum packet size, the endpoint number and the polling rate if it is an
interrupt pipe.
2. Endpoint zero never has a descriptor because every device must support endpoint
zero.
E. String descriptor
1. String descriptors provide human readable information and are optional. If they are
not used, any string index fields of descriptors must be set to zero indicating there is no
string descriptor available.

Doc No: Task-0002
Date: May 25,2015 Pg. 19 of 34
II. The following figure shows the hierarchy of descriptors which are transferred to the PC during the
device enumeration procedure.

Doc No: Task-0002
3
3.1
Date: May 25,2015 Pg. 20 of 34
HW overview
Universal Serial Bus (USB) Controller
The TM4C1294NCZAD USB module has the following features:

a. USB 2.0 high-speed (480 Mbps) operation with the integrated ULPI interface communicating
with an external PHY.
b. Four transfer types: Control, Interrupt, Bulk, and Isochronous
c. 16 endpoints
1.
1 dedicated control IN endpoint and 1 dedicated control OUT endpoint
2. 7 configurable IN endpoints and 7 configurable OUT endpoints.

d. It has 4 KB dedicated endpoint memory: one endpoint may be defined for double-buffered
1023-byte isochronous packet size.
e. Integrated USB DMA with bus master capability.
3.2
25.1 Block Diagram
Figure 3.1 TM4C129XNCZAD USB Module Block Diagram

Doc No: Task-0002
Date: May 25,2015 Pg. 21 of 34
Figure 3.1 Shows the USB Module Block Diagram for TM4C129XNCZAD microcontroller.
3.3
Signal Description
The table 3.2 lists the external signals of the USB controller and describes the function of each.
Table 3.2 USB Signals

Doc No: Task-0002
3.4
Date: May 25,2015 Pg. 22 of 34
Functional Description
3.4.1 Operation as a Device

When operating in Device mode, IN transactions are controlled by an endpoint's transmit interface and
use the transmit endpoint registers for the given endpoint. OUT transactions are handled with an
endpoint's receive interface and use the receive endpoint registers for the given endpoint.
When configuring the size of the FIFOs for endpoints, we must take into account the maximum packet
size for an endpoint.
1. Bulk. Bulk endpoints should be the size of the maximum packet (up to 64 bytes) or twice the
maximum packet size if double buffering is used.
2. Interrupt. Interrupt endpoints should be the size of the maximum packet (up to 64 bytes) or
twice the maximum packet size if double buffering is used.
3. Isochronous. Isochronous endpoints are more flexible and can be up to 1023 bytes.
4. Control. It is also possible to specify a separate control endpoint for a USB Device. However,
in most cases the USB Device should use the dedicated control endpoint on the USB
controller's endpoint 0.
3.4.1.1 Endpoints
operating as a Device, the USB controller provides:
1. two dedicated control endpoints (IN and OUT) and
2. 14 configurable endpoints (7 IN and 7 OUT).
Can be used for communications with a Host controller. The endpoint number and direction associated
with an endpoint is directly related to its register designation.
Endpoint 0 uses the first 64 bytes of the USB controller's FIFO RAM as a shared memory for both IN
and OUT transactions. The remaining 14 endpoints can be configured as control, bulk, interrupt, or
isochronous endpoints. They should be treated as 7 configurable IN and 7 configurable OUT endpoints.
The endpoint pairs are not required to have the same type for their IN and OUT endpoint configuration.
3.4.1.2 IN Transactions as a Device
When operating as a USB Device, data for IN transactions is handled through the FIFOs attached to the
transmit endpoints. The sizes of the FIFOs for the 7 configurable IN endpoints are determined by the
USB Transmit FIFO Start Address register. The maximum size of a data packet that may be placed in a
transmit endpoint's FIFO for transmission is programmable and is determined by the value written to
the USB Maximum Transmit Data Endpoint register for that endpoint. The endpoint's FIFO can also be

Doc No: Task-0002
Date: May 25,2015 Pg. 23 of 34
configured to use double-packet or single-packet buffering.

Single-Packet Buffering
If the size of the transmit endpoint's FIFO is less than twice the maximum packet size for this endpoint,
only one packet can be buffered in the FIFO and single-packet buffering is required.
Double-Packet Buffering
If the size of the transmit endpoint's FIFO is at least twice the maximum packet size for this endpoint,
two packets can be buffered in the FIFO and double-packet buffering is allowed.
3.4.1.3 OUT Transactions as a Device
When in Device mode, OUT transactions are handled through the USB controller receive FIFOs. The
sizes of the receive FIFOs for the 7 configurable OUT endpoints are determined by the USB Receive
FIFO Start Address register. The maximum amount of data received by an endpoint in any packet is
determined by the value written to the USB Maximum Receive Data Endpoint n register for that
endpoint.
The out transactions as a device also supports single-packet and double packet buffering the
functionality is same as in transactions as a device.
3.4.1.4 Zero Length OUT Data Packets
A zero-length OUT data packet is used to indicate the end of a control transfer. In normal operation,
such packets should only be received after the entire length of the Device request has been transferred.
3.4.1.5 Setting the Device Address
When a Host is attempting to enumerate the USB Device, it requests that the Device change its address
from zero to some other value. The address is changed by writing the value that the Host requested to
the USB Device Functional Address (USBFADDR) register.
This register should only be set after the SET_ADDRESS command is complete.
3.4.1.6 Device Mode SUSPEND
When no activity has occurred on the USB bus for 3 ms, the USB controller automatically enters
SUSPEND mode. If the SUSPEND interrupt has been enabled in the USB Interrupt Enable (USBIE)
register, an interrupt is generated at this time. When in SUSPEND mode, the PHY also goes into
SUSPEND mode. When RESUME signaling is detected, the USB controller exits SUSPEND mode
and takes the PHY out of SUSPEND. If the RESUME interrupt is enabled, an interrupt is generated.
3.4.1.7 Start-of-Frame
When the USB controller is operating in Device mode, it receives a Start-Of-Frame (SOF) packet

Doc No: Task-0002
Date: May 25,2015 Pg. 24 of 34
from the Host once every millisecond. When the SOF packet is received, the 11-bit frame number
contained in the packet is written into the USB Frame Value (USBFRAME) register, and an SOF
interrupt is also signaled and can be handled by the application.
3.4.1.7 USB RESET
When the USB controller is in Device mode and a RESET condition is detected on the USB bus, the
USB controller automatically performs the following actions:
1. Clears the USBFADDR register.
2. Clears the USB Endpoint Index (USBEPIDX) register.
3. Flushes all endpoint FIFOs.
4. Clears all control/status registers.
5. Enables all endpoint interrupts.
6. Generates a RESET interrupt.
3.4.2 Operation as a Host
When the TM4C1294NCZAD USB controller is operating in Host mode, it can either be used for
point-to-point communications with another USB device or, when attached to a hub, for
communication with multiple devices.
Note: the functionality of the Host in Device mode, endpoint, IN and OUT Transactions is similar to
that of Device.
3.4.2.1 Transaction Scheduling
Scheduling of transactions is handled automatically by the USB Host controller. The Host controller
allows configuration of the endpoint communication scheduling based on the type of endpoint
transaction. Interrupt transactions can be scheduled to occur in the range of every frame to every 255
frames in 1 frame increments.
3.4.2.2 Babble
The USB Host controller does not start a transaction until the bus has been inactive for at least the
minimum inter-packet delay. The controller also does not start a transaction unless it can be finished
before the end of the frame. If the bus is still active at the end of a frame, then the USB Host controller
assumes that the target Device to which it is connected has malfunctioned, and the USB controller
suspends all transactions and generates a babble interrupt.
3.4.2 ULPI Interface

Doc No: Task-0002
Date: May 25,2015 Pg. 25 of 34
The ULPI PHY interface is a reduced pin-count interface conforms to the UTMI+ specification. The
reduction in pin count is achieved by allowing the relatively static UTMI+ signals to be accessed
through registers and by providing a bi-directional data bus both for the USB data and for accessing
register data on the ULPI transceiver.
3.4.3 USB DMA Controller
The USB includes an integrated eight-channel USB DMA controller for efficient loading/unloading of
the endpoint FIFOs. Any Tx Endpoints 1 through 7 and Rx Endpoints 1 through 7 can be assigned to
DMA channels 0 through 7. The DMA can operate in two modes and can handle packet sizes up to 8K.
In addition, the DMA controller can be programmed to conduct transfers using burst of four, eight and
sixteen or bursts of unspecified length.
3.4.4 DMA Operation
The DMA transfer is particularly useful when large blocks of data are to be transferred through a Bulk
endpoint. The USB protocol requires that large data blocks are transferred by sending a series of
packets of the maximum packet size for endpoint (512 bytes for high speed, 64 bytes for full speed).
The last packet in the series may be less than the maximum packet size. The receiver may use the
reception of this short packet to signal the end of the transfer. The DMA may be used in either Device
mode or Host mode to avoid the overhead of having to interrupt the processor after each individual
packet, and instead, only interrupting the processor after the transfer has completed.

Doc No: Task-0002
SW Requirements
4.1
Flow chart for USB initialization
Date: May 25,2015 Pg. 26 of 34

Doc No: Task-0002
Date: May 25,2015 Pg. 27 of 34
SysCtlClockFreqSet();
uint32_t SysCtlClockFreqSet(uint32_t ui32Config, uint32_t ui32SysClock);
This function configures the system clocking to 120 MHz with a 480 MHz PLL.
param ui32Config = 480MHz
param ui32SysClock = 120MHz
Return: The actual configured system clock frequency in Hz or zero if the value could not be changed
due to a parameter error or PLL lock failure.
PinoutSet();
Void PinoutSet(void)
This function enables the GPIO modules and configures the device pins for USB operation.
Used to configures PL6 as DP and PL7 as DM.
USBStackModeSet ( );
Void USBStackModeSet(uint32_t ui32Index, tUSBMode iUSBMode, tUSBModeCallback
pfnCallback)
Allows dual mode application to switch to device modes.
Param ui32Index = 0, specifies the USB controller whose mode of operation is to be set.
Param iUSBMode = 0, indicates the mode that the application wishes to operate = 0, for device mode
Param pfnCallback is a pointer to a function which the USB library will call each time the mode is
changed to indicate the new operating mode.
USBDHIDCompositeInit( );
void * USBDHIDCompositeInit(uint32_t ui32Index, tUSBDHIDDevice
*psHIDKbDevice, tCompositeEntry *psCompEntry)
Initializes HID device operation.
Param ui32Index = 0, is the index of the USB controller which is to be initialized for HID device
operation.
Param psHIDKbDevice = descriptors, points to a structure containing device, configuration, interface
and endpoint descriptors customizing the operation of the HID device.

Doc No: Task-0002
Date: May 25,2015 Pg. 28 of 34
Param psCompEntry=0, is the composite device entry to initialize when creating a composite device.
Returns zero on failure or a non-zero instance value that should be used with the remaining USB HID
APIs.
USBDCDConfigGetInterfaceEndpoint( );
tEndpointDescriptor *USBDCDConfigGetInterfaceEndpoint(const tConfigHeader *psConfig, uint32_t
ui32InterfaceNumber, uint32_t ui32Index)
Return a pointer to the n-th endpoint descriptor in a particular interface within a configuration
descriptor.
Param psConfig= pointer to descriptor, points to the header structure for the configuration descriptor
that is to be searched.
Param ui32InterfaceNumber = ptr to device information, is the interface number whose endpoint is to
be found.
Param ui32Index = 0 for device descriptor and 1 for other descriptor, is the zero based index of the
endpoint that is to be found within the appropriate alternate setting for the interface.
Returns a pointer to the requested endpoint descriptor if found or NULL otherwise.
USBDCDDeviceInfoInit( );
Void USBDCDDeviceInfoInit(uint32_t ui32Index, tDeviceInfo *psDeviceInfo)
Initialize an instance of the tDeviceInfo structure.
Param ui32Index = 0, is the index of the USB controller which is to be initialized.
Param psDeviceInfo = pointer to descriptors.
MAP_SysCtlPeripheralReset();
Void SysCtlPeripheralReset(uint32_t ui32Peripheral).
Performs a software reset of a peripheral.
Param ui32Peripheral = 0xf0002800 for USB 0, is the peripheral to reset.
USBDevLPMDisable( );
Void USBDevLPMDisable(uint32_t ui32Base)
Disables the USB controller from responding to LPM suspend requests.

Doc No: Task-0002
Date: May 25,2015 Pg. 29 of 34
Param ui32Base = 0x40050000 for USB 0, specifies the USB module base address.
USBLibDMAInit( );
tUSBDMAInstance *USBLibDMAInit(uint32_t ui32Index)
This function is used to initialize the DMA interface for a USB instance.
param ui32Index = 0, is the index of the USB controller for this instance.
Returns a pointer to use with USBLibDMA APIs.
USBDevConnect( );
Void USBDevConnect(uint32_t ui32Base)
Connects the USB controller to the bus in device mode.
Param ui32Base = 0x40050000 for USB 0, specifies the USB module base address.
IntEnable( );
IntEnable(uint32_t ui32Interrupt)
The specified interrupt is enabled in the interrupt controller.
Param ui32Interrupt = MemManage, bus fault, usage fault, or general interrupt to be enabled.

Doc No: Task-0002
4.2
Interrupt service routine
Date: May 25,2015 Pg. 30 of 34

Doc No: Task-0002
4.3
Date: May 25,2015 Pg. 31 of 34
Data reception from host to device
When data arrives from the host, the device will receive an interrupt from the host. The
interrupt handler must perform the following steps on reception:
1. Read the USB Receive Interrupt Status register USBRXIS.
2. Identify the interrupt.
3. Call the appropriate handler (i.e. Read Data handler).
4. Read handler checks whether the RX Packet Ready bit is set.
5. Check the number of byte available in the buffer.
6. Read the data to buffer USB FIFO endpoint.
7. Clear the RX Packet Ready bit.
8. Give the read data to the application.

Doc No: Task-0002
4.3
Date: May 25,2015 Pg. 32 of 34
Data transmission from device to host
When the device side application needs to send data to the host, the device must follow the below steps.
1. Application calls the write data API and passes the data buffer to the CDC (communication
device class) layer.
2. Write data API checks the amount of data to be sent
3. Copy data to the TX buffer
4. Set the TX Packet Ready bit
5. After the transmit operation completes, the host sends a TX completion interrupt
6. TX Packet Ready bit will be cleared automatically
7. After receiving the TX Complete Interrupt, the ISR sends an event to the application indicating
the completion of data transfer

Doc No: Task-0002
4.4
Date: May 25,2015 Pg. 33 of 34
Registers configuration
The set of registers that are to be configured for the correct operation of the system is as described
below:
Note: only registers that need change are indicated below. All other registers that do not need any
change from default values are not described. The detailed bit allocation of each register can be known
from the user manual of the controller and are not described.
Register 1: USBFADDR
USB Device Functional Address contains the 7-bit address of the Device part of the transaction.
Base 0x4005.0000
Offset 0x000
Type RW
Reset value: 0x00
Initialization value: Function Address of Device as received through SET_ADDRESS.
When the USB controller is being used in Device mode, this register must be written with the address
received through a SET_ADDRESS command, which is then used for decoding the function address in
subsequent token packets.
Register 2: USBPOWER
USBPOWER is an 8-bit register used for controlling SUSPEND and RESUME signaling.
Base 0x4005.0000
Offset 0x001
Type RW,
Reset value: 0x20
Initialization value: 0x00
Full speed mode is enabled by disabling high speed mode.
Register 22: USBTXFIFOSZ
USB Transmit Dynamic FIFO Sizing is an 8-bit registers that allow the selected TX/RX endpoint
FIFOs to be dynamically sized.
Base 0x4005.0000

Doc No: Task-0002
Date: May 25,2015 Pg. 34 of 34
Offset 0x062
Type RW,
Reset value: 0x00
Max Packet Size selected as 64 bytes.
Note: USBRXFIFOSZ configuration is same as above.
Register 82 to 88: USBTXMAXP1 to USBTXMAXP7
The USB Maximum Transmit Data Endpoint is a 16-bit register that defines the maximum amount of
data that can be transferred through the transmit endpoint in a single operation.
Base 0x4005.0000
Offset 0x110
Type RW,
Reset 0x0000
Initialization value: Maximum Payload in bytes per transaction.
Register 165: USBDMACTL0 to USBDMACTL7
USB DMA Control register provides the DMA transfer control for each channel. The enabling, transfer
direction, transfer mode, the DMA burst modes are all controlled by this register.
Reset value: 0x00
DMA mode and DMA interrupt mode is enabled.

USB For TM4C1294 0.07

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

USB For TM4C1294 0.07

Uploaded by

Copyright:

Available Formats

Software design Consideration: Ethernet on TM4C129NCZAD

Doc No: Task-0002

Date: May 25,2015 Pg. 1 of 34

Software Design Consideration

Software design Consideration: Ethernet on TM4C129NCZAD

Date: May 25,2015 Pg. 2 of 34

Software design Consideration: Ethernet on TM4C129NCZAD

Date: May 25,2015 Pg. 3 of 34

This document is divided into following major sections:

Software design Consideration: Ethernet on TM4C129NCZAD

USB theory of operation

Introduction to Universal Serial Bus

Date: May 25,2015 Pg. 4 of 34

USB network supports three communication speeds.

USB supports plugnplug with dynamically loadable and unloadable drivers.

Software design Consideration: Ethernet on TM4C129NCZAD

Date: May 25,2015 Pg. 5 of 34

Each USB transaction consists of a

Common USB Packet Fields

Software design Consideration: Ethernet on TM4C129NCZAD

Date: May 25,2015 Pg. 6 of 34

USB Packet Types

Software design Consideration: Ethernet on TM4C129NCZAD

Date: May 25,2015 Pg. 7 of 34

USB has four different packet types.,

2. Data Packets: data packets contain the payload

Maximum data payload size for full-speed devices is 1023 bytes.

Data must be sent in multiples of bytes.

3. Handshake Packets: are used for acknowledging data or reporting errors

ACK - Acknowledgment that the packet has been successfully received.

Handshake Packets have the following format,

4. Start of Frame Packets: indicate the start of a new frame.

Software design Consideration: Ethernet on TM4C129NCZAD

Date: May 25,2015 Pg. 8 of 34

Software design Consideration: Ethernet on TM4C129NCZAD

Date: May 25,2015 Pg. 9 of 34

A control transfer can have up to three stages.

Software design Consideration: Ethernet on TM4C129NCZAD

Date: May 25,2015 Pg. 10 of 34

Software design Consideration: Ethernet on TM4C129NCZAD

Date: May 25,2015 Pg. 11 of 34

Software design Consideration: Ethernet on TM4C129NCZAD

Date: May 25,2015 Pg. 12 of 34

Software design Consideration: Ethernet on TM4C129NCZAD

Date: May 25,2015 Pg. 13 of 34

Software design Consideration: Ethernet on TM4C129NCZAD

Date: May 25,2015 Pg. 14 of 34

Software design Consideration: Ethernet on TM4C129NCZAD

Date: May 25,2015 Pg. 15 of 34

Software design Consideration: Ethernet on TM4C129NCZAD

Date: May 25,2015 Pg. 16 of 34

The more common USB descriptors are

Software design Consideration: Ethernet on TM4C129NCZAD

Date: May 25,2015 Pg. 17 of 34

Software design Consideration: Ethernet on TM4C129NCZAD

Date: May 25,2015 Pg. 18 of 34

Software design Consideration: Ethernet on TM4C129NCZAD

Date: May 25,2015 Pg. 19 of 34

Software design Consideration: Ethernet on TM4C129NCZAD

Date: May 25,2015 Pg. 20 of 34

The TM4C1294NCZAD USB module has the following features:

1 dedicated control IN endpoint and 1 dedicated control OUT endpoint