USB for TM4C1294 0.07.doc

47
Software design Consideration: Ethernet on TM4C129NCZAD Doc No: Task-0002 Date: May Pg. 1 of 47 Software Design Consideration USB for TM4C1294

Transcript of USB for TM4C1294 0.07.doc

Software design Consideration: Ethernet on TM4C129NCZAD

Doc No: Task-0002

Date: May 25,2015

Pg. 30 of 34

Software Design Consideration

USB for TM4C1294

Table of Contents

1. Scope............................................................................................................................................ 3

2. USB theory of operation ............................................................................................................ 4

3. Hardware overview .................................................................................................................. 20

4. Software requirements.............................................................................................................. 26

1.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.1Document Overview

This document is divided into following major sections:

a. USB theory of operation

b. General requirements

c. HW overview

d. Functional Description

2USB theory of operation2.1Introduction to Universal Serial Bus

I. 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. USB supports plugnplug with dynamically loadable and unloadable drivers.

VI. 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 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

Cable color

Function

1

Red

Vbus (5 volt)

2

White

D-

3

Green

D+

4

Black

Ground

2.2USB 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.4Common 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.

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.3USB Packet Types

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

EOP

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

The SOF packet consisting of an 11-bit frame number is sent by the host every 1ms500ns on a full speed bus or every 125 s0.0625 s on a high speed bus.

Sync

PID

Frame Number

CRC5

EOP

2.5USB 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.6Endpoints

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.7Transfer 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 Transfers2.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.

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.

CStatus 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.

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 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.

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 transactions do not have a handshaking stage and cannot report errors or STALL/HALT conditions.

2.7USB 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.

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.

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.

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.

II. The following figure shows the hierarchy of descriptors which are transferred to the PC during the device enumeration procedure.

3HW overview3.1Universal 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.225.1 Block Diagram

Figure 3.1 TM4C129XNCZAD USB Module Block Diagram

Figure 3.1 Shows the USB Module Block Diagram for TM4C129XNCZAD microcontroller.3.3Signal Description

The table 3.2 lists the external signals of the USB controller and describes the function of each.

Table 3.2 USB Signals

3.4Functional Description

3.4.1Operation 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 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

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.2Operation 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.2ULPI Interface

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.3USB 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.4DMA 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.

4SW Requirements

4.1Flow chart for USB initialization

If

we have atleast one

IN Endpoint?

Call USBDHIDCompositeInit(ptr1)

PTR1 is a pointer to device descriptors.

USBDHIDCompositenit();

Get the pointer ptrn, Initialize

the device information structure

based on the i/p from caller.

Yes

End

If

Initialized

successfully?

Call USBDHIDCompositeInit(ptr2) with a

PTR2 is a pointer to configuration descriptor,

interface descriptor and endpoint descriptor.

Yes

End

USB Initialization

Configure the main system

clocking for the device to

run from PLL at 120MHz

SysCtlClockFreqSet();

Configure the device pins

PL6 as D+ and PL7 as D-

PinoutSet();

Initialize the USB stack for

device mode

USBStackModeSet();

Reset the USB controller.

MAP_SysCtlPeripheralReset();

Enable Clocking to the USB

controller by setting

SYSCTL_PERIPH_USB0 = 1 in

MAP_SysCtlPeripheralEnable();

Disable LPM functionality

USBDevLPMDisable();

Initialize the USB DMA interface

USBLibDMAInit(0);

Attach the device using the soft connect

MAP_USBDevConnect();

Enable the USB interrupt.

OS_INT_ENABLE();

Get the first and second endpoint

descriptor on interface 0. and determine IN

and OUT endpoint.

USBDCDConfigGetInterfaceEndpoint();

Save the USB interrupt number,

Disable LPM and Disable remote

wake up by calling

USBDCDDeviceInfoInit();

No

No

return NULL to

indicate an error

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.

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.

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.

4.2Interrupt service routine

Read the device

interrupt status register

USBIS

If

reset signal

detected?

1. Disable remote wake up signaling

2. Reset the default configuration identifier

3. Reset the alternate function selections.

If

Resume was

signaled on the

bus?

Yes

No

exit SUSPEND

mode

Yes

If

Start of Frame

was received?

No

Increment the

global SOF

counter

yes

Handle resume signaling if

required by function

USBDeviceResumeTickHandler()

Read the LPM interrupt

status register

USBLPMRIS and

Attributes

USBLPMATTR

If device LPM is

in sleep mode?

If

host initates

resume request,

USBLPMRIS_RES

==1?

Yes

Acknowledge host

USBLPMRIS_ACK=1

Enable Rx of LPM packet

USBDevLPMEnable(USB0_

BASE)

yes

If

host initiates sleep

request,

USBLPMRIS_RES

==0?

No

No

If

Tx FIFO is not

empty,

USBLPMATTR!=0 ?

Yes

Send error flag,

USBLPMRIS_NY=1

Yes

Get the controller

interrupt status

from USBTXIS

and USBRXIS

No

No

If

endpoint 0

interrupt bit is is

USBTXIS_EP0=1

?

enumerate and handle

all USB standard

requests by function

USBDeviceEnumHand

ler(&g_psDCDInst[0]);

Yes

If

Endpoint n Transmit

interrupt bit is set,

USBTXIS_EPn=1?

No

Set

TX_Packetn_Ready

bit

Yes

If

Endpoint n Transmit

interrupt bit is set,

USBRXIS_EP1=1?

Set

RX_Packetn_Ready

bit

Yes

No

Return ()

No

No

4.3Data 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.

RX Mode

RxPktRdy

Set?

Read Count

register(n)

Unload n Bytes

from FIFO

Last Packet

Set ServicedRxPktRdy

& DataEnd

State -> IDLE

Return

Set

ServicedRxPktRdy

Return

Yes

Yes

No

No

4.3Data 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

TX Mode

Write IDLE

Return

Set TxPktRdy

Yes

No

4.4Registers 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

Offset 0x062

Type RW,

Reset value: 0x00

Initialization value: 0x03

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

Initialization value: 0x08

DMA mode and DMA interrupt mode is enabled.

_1494314233.vsd

Read the device interrupt status register USBIS

If reset signal detected?

1. Disable remote wake up signaling2. Reset the default configuration identifier 3. Reset the alternate function selections.

Yes

No

IfResume was signaled on the bus?

exit SUSPEND mode

Yes

IfStart of Frame was received?

No

Increment the global SOF counter

yes

Handle resume signaling if required by function USBDeviceResumeTickHandler()

Read the LPM interrupt status register USBLPMRIS and Attributes USBLPMATTR

If Tx FIFO is not empty, USBLPMATTR !=0 ?

If device LPM is in sleep mode?

Yes

Send error flag, USBLPMRIS_NY=1

No

Return ()

If host initates resume request, USBLPMRIS_RES==1?

Yes

Acknowledge host USBLPMRIS_ACK=1Enable Rx of LPM packetUSBDevLPMEnable(USB0_BASE)

yes

If host initiates sleep request, USBLPMRIS_RES==0?

No

No

Yes

Get the controller interrupt status from USBTXIS and USBRXIS

No

No

Ifendpoint 0 interrupt bit is is USBTXIS_EP0=1?

enumerate and handle all USB standard requests by functionUSBDeviceEnumHandler(&g_psDCDInst[0]);

Yes

If Endpoint n Transmit interrupt bit is set, USBTXIS_EPn=1?

No

Set TX_Packetn_Ready bit

Yes

If Endpoint n Transmit interrupt bit is set, USBRXIS_EP1=1?

Set RX_Packetn_Ready bit

Yes

No

No

_1495354927.vsd

Reset the USB controller.MAP_SysCtlPeripheralReset();

return NULL to indicate an error

Enable Clocking to the USB controller by setting SYSCTL_PERIPH_USB0 = 1 in MAP_SysCtlPeripheralEnable();

Disable LPM functionality USBDevLPMDisable();

Save the USB interrupt number, Disable LPM and Disable remote wake up by calling USBDCDDeviceInfoInit();

If we have atleast one IN Endpoint?

Initialize the USB DMA interface USBLibDMAInit(0);

Get the first and second endpoint descriptor on interface 0. and determine IN and OUT endpoint.USBDCDConfigGetInterfaceEndpoint();

No

No

Call USBDHIDCompositeInit(ptr1) PTR1 is a pointer to device descriptors.

USBDHIDCompositenit();

Get the pointer ptrn, Initialize the device information structure based on the i/p from caller.

Yes

End

IfInitialized successfully?

Yes

Call USBDHIDCompositeInit(ptr2) with a PTR2 is a pointer to configuration descriptor, interface descriptor and endpoint descriptor.

Attach the device using the soft connectMAP_USBDevConnect();

End

USB Initialization

Enable the USB interrupt. OS_INT_ENABLE();

Configure the main system clocking for the device to run from PLL at 120MHz SysCtlClockFreqSet();

Configure the device pinsPL6 as D+ and PL7 as D-PinoutSet();

Initialize the USB stack for device modeUSBStackModeSet();

_1494070929.vsd

TX Mode

Write IDLE

Return

Set TxPktRdy

Yes

No

_1494078178.vsd

RX Mode

RxPktRdySet?

Read Count register(n)

Unload n Bytes from FIFO

Last Packet

Set ServicedRxPktRdy& DataEndState -> IDLE

Return

Set ServicedRxPktRdy

Return

Yes

Yes

No

No