AN56377 PSoC 3 and PSoC 5LP Introduction to Implementing USB Data Transfers.pdf

AN56377
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
Author: Robert Murphy
Associated Project: Yes
Associated Part Family: All PSoC® 3 and PSoC 5LP Parts
®
Software Version: PSoC Creator™ 3.3
Associated Application Notes: See Related Resources
AN56377 describes the four USB transfer types: Interrupt, Bulk, Isochronous, and Control. It then shows how to
®
configure PSoC 3 and PSoC 5LP to perform each of these transfers. Code examples are also included for specific
considerations, including vendor commands for custom USB functionality, and to use DMA for faster data throughput.
This application note assumes a basic-level knowledge of USB and is intended as an initial hands-on introduction to
USB on PSoC 3 and PSoC 5LP. For a general introduction to USB, see AN57294.
Contents
1
Introduction ...............................................................2
1.1
Disclaimer Regarding USB 3.0 ........................2
2
Application Note Requirements ................................2
3
USB Transfers ..........................................................3
3.1
USB Transfer Structure....................................3
3.2
Transfer Composition ......................................4
4
USB Transfer Types .................................................7
4.1
Interrupt Transfers ...........................................8
5
Bulk Transfers ........................................................ 10
5.1
Isochronous Transfers ................................... 12
5.2
Synchronization of Isochronous Transfers: .... 15
5.3
Feedback and Feedforward ........................... 16
6
Control Transfers .................................................... 17
7
USB Requests ........................................................ 19
8
Bus Bandwidth Management .................................. 23
9
USB Error Correction and Detection....................... 24
9.1
CRC Check .................................................... 24
9.2
PID Check...................................................... 25
9.3
Data Toggle ................................................... 25
10 Handshake ............................................................. 27
11 Error Detection in PSoC 3 and PSoC 5LP.............. 28
12 PSoC Logical Transfer Modes ................................ 29
13 Example Project Files ............................................. 30
13.1
Important Note on CyUSB Drivers ................. 30
14 Project 1: Implementing Multiple Transfer Types.... 31
14.1
Configuring the Project .................................. 31
14.2
Testing the Project ......................................... 46
www.cypress.com
14.3
Taking Project 1’s Concepts Further.............. 48
Project 2: Implementing Vendor Commands .......... 50
15.1
Configuring the Project .................................. 50
15.2
Testing the Project ......................................... 56
16 Project 3: Increasing USB Throughput with DMA ... 58
16.1
Configuring the Project .................................. 58
16.2
Testing the Project ......................................... 63
17 Summary ................................................................ 65
18 Related Resources ................................................. 65
18.1
Application Notes ........................................... 65
18.2
Knowledge Base Articles ............................... 65
18.3
Additional Information .................................... 65
A
Appendix A: Disable Driver Signature
Verification on 64-Bit Windows 8.1 or 10 ................ 66
B
Appendix B: INF for AN56377 ................................ 67
C
Appendix C: Project 1 Firmware – Main.c .............. 69
D
Appendix D: Project 2 Firmware – USBFS_vnd.c .. 71
E
Appendix E: Project 2 Firmware – Main.c............... 73
F
Appendix F: Project 3 Firmware – Main.c ............... 74
Document History............................................................ 75
Worldwide Sales and Design Support ............................. 76
Products .......................................................................... 76
®
PSoC Solutions ............................................................. 76
Cypress Developer Community....................................... 76
Technical Support ........................................................... 76
15
Document No. 001-56377 Rev. *L
1
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
1
Introduction
Most people think of USB communication simply as the transfer of data between a device and a PC. This may be
accurate from a high level perspective; however, when you design and debug a USB application, you must think
about USB communication in more detail.
USB communication occurs through a series of transfers. The USB specification defines four different transfer types:
Control, Interrupt, Bulk, and Isochronous. Depending on what the end application/device is, one transfer type may be
a better option than others.
Along with transfer types, the USB specification also defines certain commands that a USB device needs to
understand and respond to. However, you can define your own USB commands that can be used to simply turn
on/off a LED indicator or change the entire configuration of an application. These custom commands are called
vendor commands and are useful in providing direct control of the device, independent of the general ‘bit hose’ used
when streaming data.
Additionally, when you select the proper transfer type for your application, you must ensure that the data arrived at its
destination is intact and that the information is valid. There are multiple error checks and error corrections
implemented in a USB system. There are also handshakes, which provide a closed loop feedback between the
device and host with regard to the result of the transfer, the result being whether the transfer was complete or
incomplete. Knowing about the different handshakes, error corrections, and error checks is important to help
understand how USB works and to aid in debugging a USB design.
The purpose of this application note is to build upon your USB knowledge by teaching you how to choose and
implement the proper transfer type in an application. USB bandwidth is limited and each transfer has advantages and
disadvantages. Choosing the proper transfer type can increase the performance of your application and conserve
valuable bus bandwidth. This application note also shows you how to leverage the powerful DMA in PSoC to move
data around the PSoC to obtain greater throughput than using the CPU alone. Finally, this application note shows
you how to implement vendor commands in your application to provide direct control of various peripherals in a PSoC
design. As an added benefit, it discusses the composition of a USB transaction, including the packets and error
checking, which are very useful if you need to debug a USB design.
This application note includes three code examples that cover the following topics:
1.
Project 1: How to implement small Interrupt, bulk, and isochronous transfers using PSoC 3 and PSoC 5LP.
2.
Project 2: How to implement control transfers and vendor commands using PSoC 3 and PSoC 5LP.
3.
Project 3: How to increase the data throughput using DMA with USB 3 and PSoC 5LP.
At the end of the application note, you will find a Related Resources section that will point you to other USB
application notes/examples that take advantage of these transfer types even further.
1.1
Disclaimer Regarding USB 3.0
PSoC 3 and PSoC 5LP are Full Speed devices, which fall under the USB 2.0 specification. As a result, this
application note will focus solely on the concepts and capabilities outlined under Chapter 9 of the USB 2.0
specification. The USB 3.0 specification will not be discussed. If you do not have any prior experience with USB,
Cypress recommends that you read the application note AN57294 - USB 101: Introduction to Universal Serial Bus.
This application note is intended to be a follow-up to where AN57294 left off. For additional USB topics and
examples, see the Related Resources section.
2
Application Note Requirements
This application note is intended for use with the following hardware/software and is required to fully evaluate the
example projects associated with this application note:



PSoC Creator 3.0 SP1 or Newer
Cypress SuiteUSB 3.4.7 or Newer
PSoC 3 or PSoC 5LP Development Kit (choose one)



www.cypress.com
CY8CKIT-050 (Recommended Kit)
CY8CKIT-030
CY8CKIT-001
Document No. 001-56377 Rev. *L
2
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
PSoC Creator is required to build/compile the USB projects and program the PSoC device. However, Cypress
SuiteUSB is essential to test the example projects. The SuiteUSB software package provides multiple host
applications that can be used to initiate communication between the device and host. SuiteUSB also provides a
vendor specific driver, CYUSB.sys, that is used to test the various transfer types and vendor commands.
3
USB Transfers
Transfers are essential to exchange information between a USB device and a USB host. They enable communication
between the device and the host. While most users only think of transfers as a high level aspect, there are many back
and forth communications occurring continuously behind the scenes. The device and the host are constantly in
communication with each other.
3.1
USB Transfer Structure
During the enumeration process of a USB device, one of the first things that the host does is request the device
descriptor. The entire process of making the request for the device descriptor, receiving the device descriptor
information, and host acknowledging successful reception of the data is the transfer. The transfer, however, is
comprised of multiple stages called ’transactions’. Each transfer consists of one or more transactions and in the case
of the device descriptor request, there are three. The first transaction is the Setup transaction, which is where the
actual request is made to the device. The second transaction is the Data transaction, where the descriptor
information is sent to the host. Finally, the third transaction is the Handshake transaction where the host
acknowledges receiving the packet. Then, you must go a level further. Each transaction is made up of multiple
packets. Each transaction contains a token packet at minimum. Inclusion of a data packet and handshake packet can
vary depending on the transfer type. From a high level, there are two key points to understanding USB transfers,
which are also shown in Figure 1.


Each transfer contains one or more transactions.
Each transaction always contains a token packet. A data packet and handshake packet may be included
depending on the transaction type.
Figure 1. Structure of a USB Transfer
Transfer
Transaction
Transaction
Transaction
Token Packet
Data Packet
Handshake Packet
PID ADDRESS ENDPOINT CRC
PID
DATA
CRC
PID
Interrupt, bulk, and control transfers always include a token, data, and handshake packet with each transaction.
Control transfers take this a step further. Remember that control transfers have three stages - Setup, Data, and
Status. Each one of these stages contains a token, data, and handshake packet. Therefore, while an Interrupt and
Bulk transfer have a minimum of three packets, a control transfer has nine or more with a data stage and six or more
without a data stage.
www.cypress.com
Document No. 001-56377 Rev. *L
3
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
3.2
Transfer Composition
A USB packet has a general template structure. A total of five possible fields can be populated. Four of these fields
are optional, while one is required. To get an idea of which fields are used in a packet, refer to Figure 2. For a
detailed explanation of the composition of a packet, refer to the Communication Protocol section of AN57294.
Figure 2. USB Packet Contents
Packet ID (PID) – (8 bits: 4 type bits and 4 check
bits)
S
Y
N
C
A E
P
D N PAYLOAD
I
D D
DATA
D
R P
C
R
C
E
O
P
Optional Device Address – (7 bits: Max of 127
devices)
Optional Endpoint Address – (4 bits: Max of 16
endpoints)
Optional Payload Data – (0 to 1023 bytes)
PACKET
Optional CRC (5 or 16 bits)
The Packet ID is the only required field in a packet. The Device Address, Endpoint Address, Payload Data, and CRC
are filled depending on which packet type is sent. Packet IDs (PID) are the heart of a USB packet. As the name
implies, it identifies the packet. There are different PIDs depending on which packet is sent (see Table 1).
Table 1. Packet ID Information
Packet Type
PID Name
PID [3..0]
Description
OUT
0001b
Address + endpoint number in host-to-function transaction.
IN
1001b
Address + endpoint number in function-to-host transaction.
SOF
0101b
Start-of-Frame marker and frame number.
SETUP
1101b
Address + endpoint number in host-to-function transaction for SETUP to a control
pipe.
DATA0
0011b
Data packet PID even. Data Toggle
DATA1
1011b
Data packet PID odd. Data Toggle
DATA2
0111b
Data packet PID high-speed, high bandwidth isochronous
Token
Data
Transaction in a microframe. High Speed Only
MDATA
1111b
Data packet PID high-speed for split and high bandwidth isochronous transactions.
High Speed Only
ACK
0010b
Receiver accepts error-free data packet.
NAK
1010b
Receiving device cannot accept data or transmitting device cannot send data.
STALL
1110b
Endpoint is halted or a control pipe request is not supported.
NYET
0110b
No response yet from receiver. High Speed Only
PRE
1100b
(Token) Host-issued preamble. Enables downstream bus traffic to low-speed
devices.
ERR
1100b
(Handshake) Split Transaction Error Handshake (reuses PRE value).
High Speed Only
SPLIT
1000b
(Token) High-speed Split Transaction Token. High Speed Only
PING
0100b
High-speed flow control probe for a bulk/control endpoint. High Speed Only
Reserved
0000b
Reserved PID.
Handshake
Special
www.cypress.com
Document No. 001-56377 Rev. *L
4
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
A packet transfer also includes a SYNC field and an End of Packet (EOP). The SYNC field is used for
synchronization purposes and is included at the beginning of all packets. Because the receiver and sender of a
packet do not share a clock, there must be a method to synchronize the incoming data with the local clock of the
recipient of the packet. The SYNC field does this by allowing the recipient of the packet to adjust its clock before the
packet arrives. Because the SYNC field is only used for synchronization purposes, it is not included or mentioned in
most packet diagrams. On a full speed device, such as PSoC, the SYNC field is eight bits long, consisting of a
sequence of KJKJKJKK states. Figure 3 shows an example. The SYNC field works in conjunction with bit stuffing to
maintain clock accuracy.
Figure 3. Full Speed SYNC Field
K J K J K J K K
An End of Packet (EOP) signal is the conclusion of all packets. It returns the bus back to an idle state where it
remains until the next SYNC occurs, followed by a packet. The EOP signal, similar to J and K states, differs on low,
full, and high speed devices. On a full speed device, an EOP occurs when the data lines go into a SE0 state for 2-bit
times, followed by a J state for 1-bit time.
An additional term you occasionally hear in relation to USB transactions is inter-packet delay. Inter-packet delay is
the measured time (in bit times) between the EOP and the SYNC field. On a full speed device, the USB specification
requires this to be a minimum of 2-bit times. This time enables a break in transmission for the device that sent the
EOP to disable its output drivers.
Figure 4. Bus Analyzer Showing Inter-Packet Delay
Packet #
300
F
S
Sync
00000001
IN
0x96
Packet #
301
F
S
Sync
00000001
DATA1
0xD2
Packet #
302
F
S
Sync
00000001
ACK
0x4B
ADDR
3
ENDP
0
CRC5
0x0A
DATA
12 01 00 02 00 00 00 08
EOP
3.00
Idle
11793
EOP
3.00
Idle
2
CRC16
0xEAE7
Inter Packet
Delay
EOP
3.00
Idle
7
Inter Packet
Delay
Inter Packet
Delay
To gain better understanding regarding transfer composition, let’s refer back to the bus analyzer capture of an
enumeration sequence, shown in the Appendix of AN57294. Additionally, in order to help explain things more clearly,
let’s limit the focus of the analysis to the GET_DESCRIPTOR request, which occurs at the very beginning of the
enumeration process. This request is described in AN57294, specifically in Step 8 of the USB Enumeration and
Configuration, as follows:
“The host will now begin its process of learning more information about the device starting with learning the
maximum packet size of the default pipe (i.e. Endpoint 0). The host will start by issuing a GET_DESCRIPTOR
request to the device. The device will begin to send the descriptors that were discussed in the USB Descriptor section
th
of the application note. In the Device Descriptor, the 8 byte (bMaxPacketSize0) contains information regarding the
max packet size for EP0. A Windows host will request 64-bytes, but after only receiving 8 bytes of the device
descriptor, it will begin the status stage of the transfer and request the hub to reset the device again.”
The bus analyzer capture of the GET_DESCRIPTOR request is shown in Figure 5, which is comprised of three
transactions that are part of a transfer.
www.cypress.com
Document No. 001-56377 Rev. *L
5
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
Figure 5. GET_DESCRIPTOR Request during Enumeration
Transaction
0
F
S
Setup
0xB4
ADDR
0
ENDP
0
D
D->H
Transaction
1
F
S
IN
0x96
ADDR
0
ENDP
0
T
1
Transaction
2
F
S
OUT
0x96
ADDR
2
ENDP
1
T
S
T R
S D
bRequest
GET_DESCRIPTOR
wValue
DEVICE type
DATA
12 01 00 02 00 00 00 08
DATA
wIndex
0x0000
wLength
64
ACK
0x4B
ACK
0x4B
ACK
0x4B
The total depth of the GET_DECRIPTOR transfer does not end there. It goes even deeper where each transaction
has multiple packets associated with it, as shown in Figure 6.
Figure 6. GET_DESCRIPTOR Request during Enumeration
Transfer
0
F
S
Control
GET
Transaction
0
F
S
ADDR
0
Setup
0xB4
ENDP
0
ADDR
0
bRequest
GET_DESCRIPTOR
ENDP
0
Packet #
50
F
S
Sync
00000001
Setup
0xB4
Packet #
51
F
S
Sync
00000001
DATA0
0xC3
Packet #
52
F
S
Sync
00000001
ACK
0x4B
Transaction
1
F
S
IN
0x96
ADDR
0
F
S
Sync
00000001
IN
0x96
Packet #
55
F
S
Sync
00000001
DATA1
0xD2
Packet #
56
F
S
Sync
00000001
ACK
0x4B
F
S
OUT
0x96
ADDR
2
ADDR
0
F
S
Sync
00000001
OUT
0x87
Packet #
60
F
S
Sync
00000001
DATA1
0xD2
Packet #
61
F
S
Sync
00000001
ACK
0x4B
ENDP
0
bRequest
GET_DESCRIPTOR
CRC5
0x08
EOP
3.00
Descriptors
DEVICE descriptor
wValue
DEVICE type
wIndex
0x0000
Time
0ns
wLength
64
ACK
0x4B
Idle
2
EOP
2.75
CRC16
0xBB29
Idle
5
Idle
11798
EOP
3.00
T
1
DATA
12 01 00 02 00 00 00 08
ADDR
0
ENDP
0
CRC5
0x08
DATA
12 01 00 02 00 00 00 08
ACK
0x4B
Idle
5
EOP
3.00
CRC16
0xEAE7
EOP
3.00
Idle
7
Idle
11793
EOP
3.00
ENDP
1
Packet #
59
T R
S D
DATA
80 06 00 01 00 00 40 00
ENDP
0
Packet #
54
Transaction
2
D
D->H
wIndex
0x0000
wValue
DEVICE type
T
S
DATA
ADDR
0
ENDP
0
DATA
ACK
0x4B
CRC5
0x08
EOP
3.00
CRC16
0x0000
Idle
2
EOP
3.00
Idle
5
Idle
11862
EOP
3.00
This is where everything fits together. If one refers back to the data structure shown in Figure 1 and combines it with
the transactions and packets of Figure 6, one will see the result shown in the Figure 7 structure.
Figure 7. Structure of USB Transfer in Figure 7
Transfer 0
Transaction 0
Transaction 1
Transaction 2
Token Packet 54
Data Packet 55
Handshake Packet 56
PID ADDRESS ENDPOINT CRC
www.cypress.com
PID
DATA
CRC
Document No. 001-56377 Rev. *L
PID
6
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
Transaction 0 is the Setup stage, Transaction 1 is the Data stage, and Transaction 2 is the Status stage. Note that a
total of nine packets are needed to complete this transfer. Focusing on transaction 0, you can see that the token
packet (Packet 50) contains the PID for a SETUP, the address of the device, the endpoint number, and the CRC. The
data packet (Packet 51) has the PID for the Data Toggle, the data payload, and a CRC. Finally, the handshake
packet (Packet 52) has a PID for a handshake for that transaction. Analyzing a USB transfer at a packet level is the
lowest level one can look at USB communication with the exception of the actual D+ and D- logic levels as shown in
Figure 8. One thing to note, the GET_DESCRIPTOR example is known as a control transfer with a data stage. There
is such a thing as a control transfer with no data stage, which will be discussed at a later point.
Figure 8. Composition of a USB Packet
Packet #
50
4
F
S
Sync
00000001
Setup
0xB4
ADDR
0
ENDP
0
CRC5
0x08
EOP
3.00
Idle
2
USB Transfer Types
As mentioned earlier, packets can be transferred in one of several different transfer types. Each has its own
advantages and disadvantages. Table 2 shows an overview of the features and capabilities of each of the transfer
types. The following sections describe these transfer types in greater detail.
Table 2. Endpoint Transfer Type Features
Transfer Type
Control
Interrupt
Bulk
Isochronous
Typical Use
Device Initialization
and Management
Mouse and Keyboard
Printer and Mass
Storage
Streaming Audio and
Video
Low Speed Support
Yes
Yes
No
No
Error Correction
Yes
Yes
Yes
No
Guaranteed Delivery Rate
No
No
No
Yes
No
Yes (90%/80%)[1]
[1]
Guaranteed Bandwidth
Yes (10%)
Yes (90%/80%)
Guaranteed Latency
No
Yes
No
Yes
Maximum Transfer Size
64 Bytes
64 Bytes
64 Bytes
1023 Bytes
Maximum Transfer Speed
832 KB/s
1.216 MB/s
1.216 MB/s
1.023 MB/s
[1]
Shared bandwidth between Isochronous and Interrupt.
www.cypress.com
Document No. 001-56377 Rev. *L
7
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
4.1
Interrupt Transfers
When you initially think of an interrupt transfer, you may think that whenever data is ready to be sent or received, the
host or device stops what it is doing to address the transaction. This is not what happens with an interrupt transfer.
Interrupt transfers are regularly scheduled IN and OUT transactions that occur at an interval that is defined in the
Endpoint Descriptor for a particular endpoint. At that defined interval, the host guarantees to perform the transaction
at least that often. However, the transaction may occur more frequently than specified. Interrupt transfers are useful
for applications where you want to send periodic status updates.
These transfers are also useful for sending small quantities of data within a specific amount of time, such as mice,
keyboards, game controllers, and hub status reports. This transfer type is used in these devices because when you
input something into a PC or a game console, you want to feel that the stimulus occurs instantly and that you do not
experience any noticeable delay. Interrupt transfers provide this with their guaranteed latency.
The disadvantage of an interrupt transfer is the lack of a guaranteed delivery rate. If requests are being NAKed, the
device retries at the next polling interval. If a design has a 10 ms interval, this can add significant delay. Therefore,
the time it takes to deliver data is highly dependent on any issues that occur with the handshake.
The frequency of data delivery depends on the interval rate in the endpoint descriptor. This interval can vary from 1 to
255 ms on a full speed device like PSoC (low and high speed devices have other ranges). This value can be adjusted
in 1 ms intervals.
Interrupt transfers are supported by all USB speeds. USB device support of Interrupt transfers, in a specific
application, is optional. Although the USB specification does not require this transfer type to be supported, some USB
classes do. An example of a USB class that has a requirement for interrupt support is the Human Interface Device
(HID) class. The packets in an interrupt transfer can vary in size depending on the bus speed. While the data payload
of a low speed Interrupt transfer can vary from 1 to 8 bytes, the data payload of a full speed transfer can vary from 1
to 64 bytes, and the data payload of a high speed transfer can vary from 1 to 1024 bytes.
Table 3. Capabilities of a Full Speed Interrupt Transfer
Data Payload
(Bytes)
Frame
Bandwidth per
Transfer
Max Transfer
per Frame
Max Transfer Speed
1
1%
107
107 KB/s
2
1%
100
200 KB/s
4
1%
88
352 KB/s
8
1%
71
568 KB/s
16
2%
51
816 KB/s
32
3%
33
1.056 MB/s
64
5%
19
1.216 MB/s
Protocol Overhead (13 Bytes)
3 SYNC bytes + 3 PID bytes + 2 Endpoint bytes + 2 CRC
bytes + 3 byte inter-packet delay
Figure 9 shows the flowchart with the various actions that can occur in an IN interrupt transaction. As mentioned
earlier, the host periodically polls the interrupt endpoint. The endpoint is polled because the host has to initiate the
transaction and it needs to check if data is ready to be transmitted. After the host sends the IN token, the device
responds with a data packet if the device has data ready, a NAK if it does not have data ready and queued up, a Stall
if there is an issue with the endpoint, or no response at all if there is something wrong with the request (such as the
request becoming corrupt). Upon receiving the packet, the host will either ACK, letting the device know that it
successfully received the data, or not send any response, indicating that the packet became corrupted during
transmission. In that case, the device tries to resend the data upon the next polling interval. Figure 10 shows the
transaction structure of an interrupt (and bulk) IN transaction.
www.cypress.com
Document No. 001-56377 Rev. *L
8
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
Figure 9. Flowchart of an IN Interrupt Transaction
Idle
IN
DATA0 or
DATA1
Figure 10. Structure of an IN Interrupt/Bulk
Transaction
ACK
Idle
Data Error
Idle
NAK
Idle
STALL
Idle
Error
Idle
From Host
From Device
On the other side of things, when a host wants to send interrupt data to a device, it issues an OUT token followed by
a data packet. If either of these packets becomes corrupted, then there is no response (no handshake) and the bus
returns to an idle state. If the device endpoint buffer is empty and able to receive the data, then the device issues an
ACK handshake indicating that it successfully received the data. If the endpoint buffer is full because of the endpoint
buffer being full from a previous transaction, then an NAK handshake is returned. Similar to an IN transaction, if an
error occurs at the endpoint, then a STALL handshake is issued. This is illustrated in the Figure 11. Additionally, the
structure of an OUT interrupt/bulk transaction is shown in Figure 12.
Figure 11. Flow of an OUT Interrupt Transaction
Error
Idle
OUT
DATA0 or
DATA1
Idle
ACK
Idle
NAK
Idle
STALL
Idle
Data Error
Idle
Figure 12. Structure of an OUT Interrupt/Bulk
Transaction
From Host
From Device
Table 4 provides a template to help understand endpoint descriptors and how they are structured. Each bit has some
kind of significance. Using Table 4 as a reference, Figure 13 and Figure 14 show an example of both an Interrupt IN
and Interrupt OUT endpoint descriptor. Both these example descriptors are configured for a maximum packet size of
64 bytes (40h) and for an interval of 10 ms, denoted by 0Ah.
Table 4. Endpoint Descriptor Template
Offset
Field
Size(Bytes)
Description
0
bLength
1
Length of this descriptor = 7 bytes
1
bDescriptorType
1
Descriptor type = ENDPOINT (05h)
2
bEndpointAddress
1
Bit 3...0: The endpoint number
Bit 6...4: Reserved, reset to zero
Bit 7: Direction. Ignored for Control
0 = OUT endpoint
1 = IN endpoint
3
bmAttributes
1
Bits 1..0: Transfer Type
00 = Control
www.cypress.com
Document No. 001-56377 Rev. *L
9
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
Offset
Field
Size(Bytes)
Description
01 = Isochronous
10 = Bulk
11 = Interrupt
If not an isochronous endpoint, bits 5..2 are reserved and must be set to zero. If
isochronous, they are defined as follows:
Bits 3..2: Synchronization Type
00 = No Synchronization
01 = Asynchronous
10 = Adaptive
11 = Synchronous
Bits 5..4: Usage Type
00 = Data endpoint
01 = Feedback endpoint
10 = Implicit feedback Data endpoint
11 = Reserved
4
wMaxPacketSize
2
Maximum packet size for this endpoint
6
bInterval
1
Polling interval in milliseconds for interrupt endpoints (1 for isoch endpoints, ignored
for control or bulk)
Figure 13. Example Endpoint Descriptor for IN Interrupt Endpoint
/*********************************************** Endpoint Descriptor
***********************************************/
/* Endpoint Descriptor Length */ 0x07u,
/* DescriptorType: ENDPOINT
*/ 0x05u,
/* bEndpointAddress
*/ 0x81u,
/* bmAttributes
*/ 0x03u,
/* wMaxPacketSize
*/ 0x40u, 0x00u,
/* bInterval
*/ 0x0Au,
Figure 14. Example Endpoint Descriptor for OUT Interrupt Endpoint
/*********************************************** Endpoint Descriptor
***********************************************/
/* Endpoint Descriptor Length */ 0x07u,
/* DescriptorType: ENDPOINT
*/ 0x05u,
/* bEndpointAddress
*/ 0x02u,
/* bmAttributes
*/ 0x03u,
/* wMaxPacketSize
*/ 0x40u, 0x00u,
/* bInterval
*/ 0x0Au,
5
Bulk Transfers
The primary use of Bulk transfers is to transfer large amounts of non-periodic burst data, such as writing a file to a
USB flash drive, or sending a file to a printer. These transfers use any spare time (idle time) on the bus that is not
used by Interrupt and Isochronous transfers. The more available the bus is, the faster the data is transferred until
being limited by the bus speed. If the bus is tied up with a video stream from a webcam (which typically uses
Isochronous), then the process of transmitting data with a bulk transfer can be much slower.
Bulk transfers are supported on full speed and high speed devices, but not on low speed devices. Similar to an
Interrupt transfer, a device is not required to support bulk transfers. A specific device class may, however, require the
support of bulk transfers. An example of a class that requires Bulk endpoint support is a Mass Storage Class device.
With interrupt transfers, you can declare a maximum packet size in the Endpoint Descriptor of up to certain values.
For example, with a full speed device, you have a maximum packet size of anywhere between 1 and 64 bytes. With
Bulk endpoints, the maximum packet size also depends on speed, but there is not as much flexibility in maximum
packet size selection. On a full speed device, the maximum packet size must be 8, 16, 32, or 64 bytes long. On a
high speed device, the maximum packet size can be 512 bytes long. Even with these limited required packet sizes, it
is acceptable if the actual data payload falls short of the maximum packet size. The data payload does not need to be
padded with zeros.
www.cypress.com
Document No. 001-56377 Rev. *L
10
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
Because bulk transfers do not have priority on the bus, it should not be used in any application that has time sensitive
data to transmit. This is due to the inability to accurately predict when the data is actually delivered. Similar to
interrupt transfers, errors are detected and the transmission of the packet is attempted again. However, unlike
interrupt transfers, which wait until the next interval, bulk transfers instantly retry assuming there is available
bandwidth.
Table 5. Capabilities of a Full Speed Bulk Transfer
Data Payload
(Bytes)
Frame Bandwidth per
Transfer
Max Transfers per
Frame
Max Bandwidth
1
1%
107
107 KB/s
2
1%
100
200 KB/s
4
1%
88
352 KB/s
8
1%
71
568 KB/s
16
2%
51
816 KB/s
32
3%
33
1.056 MB/s
64
5%
19
1.216 MB/s
Protocol Overhead (13 Bytes)
3 SYNC bytes + 3 PID bytes + 2 Endpoint
bytes + 2 CRC bytes + 3 byte inter-packet
delay
The packet structure of an IN and OUT Bulk transaction is identical to an Interrupt transaction (see Figure 10 and
Figure 12). The same applies to the flow of a bulk transaction (see Figure 9 and Figure 11) with the exception of an
additional handshake packet on high speed devices (NYET).
Figure 15 shows an example of a Bulk IN endpoint descriptor and Figure 16 shows a Bulk OUT endpoint. The
maximum packet size in the endpoint descriptor is also configured for 64 bytes. The Interval field lists a value of 0.
Remember that bulk transfers do not use the interval field because they lack a guaranteed latency and use any
available bus bandwidth. Values listed in the bInterval field represent nothing.
Figure 15. Example Endpoint Descriptor for IN Bulk Endpoint
/***********************************************
Endpoint Descriptor
***********************************************/
/* Endpoint Descriptor Length */ 0x07u,
/* DescriptorType: ENDPOINT
*/ 0x05u,
/* bEndpointAddress
*/ 0x83u,
/* bmAttributes
*/ 0x02u,
/* wMaxPacketSize
*/ 0x40u, 0x00u,
/* bInterval
*/ 0x00u,
Figure 16. Example Endpoint Descriptor for Out Bulk Endpoint
/***********************************************
Endpoint Descriptor
***********************************************/
/* Endpoint Descriptor Length */ 0x07u,
/* DescriptorType: ENDPOINT
*/ 0x05u,
/* bEndpointAddress
*/ 0x04u,
/* bmAttributes
*/ 0x02u,
/* wMaxPacketSize
*/ 0x40u, 0x00u,
/* bInterval
*/ 0x00u,
www.cypress.com
Document No. 001-56377 Rev. *L
11
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
5.1
Isochronous Transfers
Isochronous transfers are intended for streaming data to a host through a constant and real time stream of
information using pre-negotiated bandwidth on the bus. This continuous stream guarantees on-time delivery of data.
There are no bottlenecks besides the overall bus speed to impede the data transfer. With this benefit of guaranteed
delivery comes a single disadvantage − there are no handshake packets or retrials to send corrupted data. Errors in
the data are detected through the CRC in the data packet, but that is where it ends. Errors are only detected and not
corrected. After an error is detected, the recipient throws away the corrupted data and waits for the next transfer.
Because of this, when designing an application that uses isochronous transfers, you must ensure that the application
can accept occasional losses of data.
Isochronous transfers are not ideal for transferring data files, such as in mass storage devices, because missing/lost
data is unacceptable. Rather, isochronous transfers are ideal for audio and video transfers where an occasional loss
of data is acceptable and in many cases, unnoticeable. Depending on the application, isochronous transfers can also
be used for basic data streaming.
Isochronous transfers are only supported by full and high speed devices. Low speed devices are unable to implement
isochronous transfers. Just as with Interrupt and Bulk transfers, devices are not required to support them by default,
but a specific device class may require device support. Examples of device classes that do require isochronous
transfers are audio and video.
The maximum packet size of an isochronous transfer varies from full speed and high speed devices, but only slightly.
On a full speed device, an isochronous transfer is limited to 1023 bytes of data and the maximum packet size
reported in the endpoint descriptor can range from 0 to 1023 bytes. A high speed device, however, increases the
maximum packet size to 1024 bytes with a maximum packet size reported in the endpoint descriptor ranging from 0
to 1024 bytes. Additionally, the data is unable to transmit in a single packet, the host may complete the data transfer
across multiple transactions as needed.
Table 6. Capabilities of a Full Speed Isochronous Transfer
Data Payload
(Bytes)
Frame Bandwidth per
Transfer
Max Transfers per
Frame
Max Bandwidth
1
1%
150
150 KB/s
2
1%
136
272 KB/s
4
1%
115
460 KB/s
8
1%
88
704 KB/s
16
2%
60
960 KB/s
32
3%
36
1.152 MB/s
64
5%
20
1.280 MB/s
128
9%
10
1.280 MB/s
256
18%
5
1.280 MB/s
512
36%
2
1.024 MB/s
1023
69%
1
1.023 MB/s
Protocol Overhead (9 Bytes)
2 SYNC bytes + 2 PID bytes + 2 Endpoint
bytes + 2 CRC bytes + 1 byte inter-packet
delay
There are two additional design considerations with an Isochronous supported device:

Bus bandwidth: Many USB devices with isochronous endpoints have multiple alternative interface
configurations (also known as alternate settings). One interface configuration supports a large payload while
another configuration has a much smaller payload using a smaller configured isochronous endpoint, or perhaps
even bulk endpoints. It is not uncommon to see an isochronous device with four or more alternate settings to
accommodate the available bus bandwidth. Additionally, the USB specification requires that a zero bandwidth
interface exists on isochronous designs. If the isochronous device controls the bus when it does not need to,
then this is a waste of bus bandwidth and can pose a bottleneck for other USB devices. Being able to adjust the
bus bandwidth reservation of the device helps avoid this issue.
www.cypress.com
Document No. 001-56377 Rev. *L
12
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers

Circular buffering: When dealing with isochronous transfers, the device developer will often want one buffer
actively transmitting, another buffer loaded and ready to transmit, and a third buffer being actively loaded. This is
not required but a good practice when streaming data from something like an ADC to maximize throughput.
Figure 17 shows the format and possible conditional flow of an isochronous transfer. Note that unlike the other flow
diagrams (such as Figure 9), there is no handshake. In the instance of an isochronous IN transaction, the IN token is
either received or becomes corrupt. The situation is the same for the data packet. Similar scenarios occur with an
isochronous OUT transactions (such as Figure 18).
Figure 18. Flowchart of an OUT Isochronous
Transaction
Figure 17. Flowchart of an IN Isochronous
Transaction
Idle
Idle
IN
DATA0
Idle
Error
Idle
OUT
DATA0
Idle
From Host
From Host
From Device
From Device
With isochronous transfers, a full-speed device or host controller can accept either DATA0 or DATA1 PIDs in data
packets. However, a full-speed device or host controller must only send DATA0 PIDs in data packets. Because of
this, full speed isochronous devices do not support data toggling. To implement error checking in isochronous
transactions, you need to rely on checking for bit stuffing errors or CRC errors. Figure 19 and Figure 20 show block
diagram examples of isochronous transactions, while Figure 21 shows an example of an Isochronous OUT
transaction, captured by a bus analyzer. Note the unchanging Data Toggle bit and the lack of a handshake packet.
Figure 19. Example of an IN Isochronous
Transaction
Figure 20. Example of an OUT Isochronous
Transaction
Figure 21. Isochronous 8-byte OUT Transactions on Bus Analyzer
www.cypress.com
Document No. 001-56377 Rev. *L
13
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
Figure 22 shows an example of an isochronous IN endpoint descriptor and Figure 23 shows an isochronous OUT
descriptor. The maximum packet size in both endpoint descriptors is configured for 1023 bytes and the interval is
configured to 1ms. The endpoint descriptor length and the descriptor type remain constant at 07h (indicating a 7-byte
length total) and 05h (indicating an endpoint descriptor). The rest of the descriptor parameters will change depending
on the configuration.
For example, referencing bEndpointAddress in Figure 22, notice that it contains a value of 0x85, where bit 8 is set to
‘1’, indicating an IN endpoint. Additionally, bits 3..0 have a value of 05h, indicating that this is endpoint number 5
(EP5). In both Figure 22 and Figure 23, you will notice that bmAttributes has a value of 01h. Referring back to Table
4, this indicates that the endpoints are isochronous endpoints. As a result, bits 4..2 of bmAttributes now have
significance. This was not the case with interrupt and bulk endpoints. Bits 3..2, which set the Synchronization Type,
are set to 00h indicating there is no synchronization. Additionally, bits 5..4 are set to 00h indicating that this endpoint
is configured as a data endpoint.
Figure 22. Example Endpoint Descriptor for IN Isochronous EP
/***********************************************
Endpoint Descriptor
***********************************************/
/* Endpoint Descriptor Length */ 0x07u,
/* DescriptorType: ENDPOINT
*/ 0x05u,
/* bEndpointAddress
*/ 0x85u,
/* bmAttributes
*/ 0x01u,
/* wMaxPacketSize
*/ 0xFFu, 0x03u,
/* bInterval
*/ 0x01u,
Figure 23. Example Endpoint Descriptor for OUT Isochronous EP
/*********************************************** Endpoint Descriptor
***********************************************/
/* Endpoint Descriptor Length */ 0x07u,
/* DescriptorType: ENDPOINT
*/ 0x05u,
/* bEndpointAddress
*/ 0x06u,
/* bmAttributes
*/ 0x01u,
/* wMaxPacketSize
*/ 0xFFu, 0x03u,
/* bInterval
*/ 0x01u,
www.cypress.com
Document No. 001-56377 Rev. *L
14
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
5.2
Synchronization of Isochronous Transfers:
Isochronous transfers are interesting because they have multiple synchronization options for use when transmitting
between two isochronous devices, rather than between a device and a host. It is one thing to transmit data as fast as
the device can, but it is another thing to have a device that is ready to do something with that data when it arrives.
Because of the continuous stream of data, it is important to make sure bottlenecks, such as two devices not able to
keep up with one another, are eliminated. You commonly see these synchronization options used on audio class
devices. If you want to stream isochronous data to a host, without a destination device, you typically use ‘No
Synchronization’ for the synchronization type and Data Endpoint for the Usage Type in the Endpoint descriptor.
Isochronous transfers have the ability to synchronize to a data source, a recipient, or the bus’s start of frame packets.
With these synchronization options comes new terminology: Source and Sink. An Isochronous source device is a
device that data you want to stream is being collected.
For example, if you have a USB microphone with an ADC that is sampling voice data and streaming it over an
isochronous IN endpoint, that is a source. On the other end, an isochronous sink is a device that is receiving data
from the Source and doing something with that received data. An example is a pair of USB speakers that receive the
digitalized voice data from the source microphone example, and convert that digital signal into sound waves.
Figure 24. Use Case Example of Isochronous Synchronization
Sink
Source
Synchronization Required to
Match Data Rate
Isochronous IN Pipe
USB
Port
on
Host
Driver for
Microphone
Isochronous OUT Pipe
PC Application
Driver for
Speakers
USB
Port
on
Host
There are three synchronization options available for isochronous source and sink devices: Asynchronous,
Synchronous, and Adaptive.

Asynchronous: Devices that use this synchronization method do not share a common clock source. They use
an internal free running or external clock source to generate their sample rate. They are not permitted to
synchronize to the SOF or any other USB clock. Because of this lack of common clock to provide a synchronized
sample rate, the sample rate of the two devices are not matched.
Additionally, the devices do not have a way to adjust the rate at which they handle data. To compensate, the
burden needs to be placed on the host application to provide data rate matching between the two devices.
To do this, an Asynchronous sink device provides feedback regarding the data rate at which it operates. The
source provides feed forward information to the host with regard to its sample rate. This information is provided
implicitly by the number of samples produced for each frame.
By knowing the data rate of the source, and the data rate handling capabilities of the sink, the host application
can buffer the data between the devices to help synchronize. This process adds overhead to the implementation.
Asynchronous devices operate at a fixed or limited number of data rates.
The USB specification gives an example of an asynchronous source, such as an audio CD player, that provides
its data on an internal clock or resonator. Because of that fixed clock, the CD player has a fixed sample rate,
44.1 kHz in the case of a CD. In this case, you have a fixed sample rate that is independent of the USB. An
asynchronous sink is a pair of speakers that run off their own internal clock.
www.cypress.com
Document No. 001-56377 Rev. *L
15
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers

Synchronous: Devices that use this synchronization method share the USB SOF as a common clock source
between them. The source and sink devices must generate their sample clock through the 1 ms SOF with the
use of a programmable PLL. Because both devices reference the same clock, there is no need for data rate
matching by the host application. Synchronous devices operate at a fixed or limited number of data rates.
The USB specification gives an example of a synchronous source as digital microphone that creates its sample
clock from the SOF and produces a fixed number of audio samples each frame. Additionally, a synchronous sink,
such as a pair of USB speakers, derives its sample clock from the SOF and consumes a fixed number of
samples every frame.

Adaptive: Devices that use this synchronization method have the greatest flexibility. While the other two
synchronization methods require a fixed or limited number of data rates, Adaptive synchronization enables sink
and source devices to operate at any data rate that is within their operating range. Adaptive source devices
produce data at a rate that is controlled by the sink device. The sink provides feedback of its desired data rate.
The source sample rate is then adjusted to match the requested rate. The sink device detects the data rate
based on the number of samples it receives within a certain amount of time. If the received rate is lower or higher
than desired by the sink, it feeds that information back to the host.
The USB specification gives an example of an adaptive source as a CD player that contains an adaptive Sample
Rate Converter (SRC), so the output sample frequency does not needs to be 44.1 kHz like the standard audio
CD player in the asynchronous example, but can be any other frequency within the operating range of the CD
players SRC. An Adaptive sink example includes digital speakers, headphones, and so on.
To maintain a constant and uninterrupted flow of data from device A to device B, some type of synchronization
feedback needs to be implemented. This synchronization feedback will ensure that the data rate on the source
matches the data rate on the sink.
The USB specification defines two ways in which information regarding the data rate can be communicated: explicit
and implicit feedback. With explicit feedback, a dedicated isochronous pipe is defined in the endpoint descriptor and
used to provide feedback information regarding the data rate. With implicit feedback, the data rate information is
extracted from the data stream. In the case of Synchronous synchronization, rate information is derived from the Start
of Frame. Table 7 shows the various synchronization options and the closed-loop relationship options between the
source and sink.
Table 7. Synchronization Characteristics
Asynchronous
Synchronous
Adaptive
5.3
Source
Sink
Free running sample rate.
Free running sample rate.
Provides implicit feedforward.
Provides explicit feedback.
Sample rate locked to SOF.
Sample rate locked to SOF.
Uses implicit feedback.
Uses implicit feedback.
Sample rate locked to sink
Sample rate locked to source.
Uses explicit feedback.
Uses implicit feedforawrd.
Feedback and Feedforward
The exchange of this information can also occur in two different fashions: Feedback and Feedforward. With feedback
information, the information regarding the data rate is sent in the direction opposite to the data flow. With
Feedforward, information is sent in the direction of the data flow.
In Table 7, note that only Adaptive sources and Asynchronous sinks provide and use explicit feedback information.
Thus, configuration for explicit feedback is only required when using that combination of synchronization.
Implementing explicit feedback requires configuring a feedback endpoint in an isochronous design. By referencing
the Endpoint Descriptor Table in Table 4, you can see that this is accomplished by setting the “Usage Type” in
bmAttribues to 01b, defining it as a Feedback endpoint. The feedback information sent across this endpoint consists
of a 3-byte data packet. This packet contains information that represents the average number of samples a device
must produce or consume for each frame in order to produce the desired sampling frequency within 1 Hz. The
disadvantage of using this method is the overhead in comprising the information in the data packet with the required
information outlined in Section 5.12.4.2 of the USB Specification. Additional information can be found in the USB
Audio Class Specification.
www.cypress.com
Document No. 001-56377 Rev. *L
16
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
Implicit feedback is much simpler to implement and can be implemented on all other combinations of isochronous
synchronization besides the Adaptive source and Asynchronous sink. As mentioned earlier, implicit feedback uses
information extracted from the data stream or derived from the SOF. Configuring an endpoint to use this type of
feedback requires setting the “Usage Type” in bmAttribues to 10b, defining it as an Implicit Feedback Endpoint.
Because the data rate is derived from already existing information, such as the data stream and SOF, no additional
complexity is added.
6
Control Transfers
Control transfers are used to identify, configure, and control USB devices, rather than stream data. Control transfers
are how the host gathers information regarding a USB device and how the host is able to configure the device. A
Control Transfer always occurs through Endpoint 0 (EP0), which is also why EP0 is referred to as the control
endpoint. A control transfer consists of three stages. These stages are a Setup Stage, a Data Stage, and a Status
Stage.
Table 8. Capabilities of a Full Speed Control Transfer
Data Payload
(Bytes)
Max Transfers per
Frame
Frame Bandwidth
per Transfer
Max Bandwidth
1
32
3%
32 KB/s
2
31
3%
62 KB/s
4
30
3%
120 KB/s
8
28
4%
224 KB/s
16
24
4%
384 KB/s
32
19
5%
608 KB/s
64
13
7%
832 KB/s
Protocol Overhead (45 Bytes)
9 SYNC bytes + 9 PID bytes + 6 Endpoint
bytes + 6 CRC bytes + 8 Setup data bytes + 7
byte inter-packet delay
There are three types of control transfers: Control Read, Control Write, and Control with No Data. Choosing the
transfer depends on whether receiving data from the device or writing data to it is required. In many USB requests, all
the required information can usually be transferred in the data packet of the SETUP stage. Figure 25 and Figure 26
show the flow of a control write and a control read transfer. If you look at DATA and STATUS stages, note that they
are the same as a bulk and interrupt transfer. The SETUP stage is, however, different. It has a handshake phase but
there is only one acceptable response, which is an ACK. You cannot NAK or Stall a Setup stage. In the instance of
no response, the packet is resent.
www.cypress.com
Document No. 001-56377 Rev. *L
17
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
Figure 25. Control Write Transfer
Figure 26. Control Read Transfer
SETUP Stage
SETUP Stage
Error
Idle
SETUP
DATA0
ACK
Data Error
DATA Stage
Idle
OUT
Error
DATA0 or
DATA1
ACK
Idle
SETUP
DATA0
Idle
Idle
DATA Stage
Idle
Idle
IN
DATA 0 or
DATA 1
Idle
Data Error
Idle
ACK
Idle
Data Error
Idle
NAK
Idle
STALL
Idle
STALL
Idle
Error
Idle
Idle
STATUS Stage
DATA1
ACK
Idle
STATUS Stage
IN
Idle
Idle
NAK
Data Error
Idle
Error
Idle
ACK
Idle
Data Error
Idle
Idle
NAK
OUT
Error
DATA1
Idle
ACK
Idle
NAK
Idle
STALL
Idle
Idle
STALL
Idle
Error
Idle
Data Error
From Host
www.cypress.com
From Device
Document No. 001-56377 Rev. *L
From Host
Idle
From Device
18
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
In Figure 25 and Figure 26, note the data toggle. The Setup stage always has a constant DATA0, the Status stage
always has a constant DATA1, and the Data stage alternates between DATA0 and DATA1, always beginning with
DATA1. A better depiction of this is illustrated in Figure 27.
Figure 27. Possible Scenarios of a Control Transfer
Data
Stage
Setup
Stage
Status
Stage
Control
Write
SETUP
(DATA0)
OUT
(DATA1)
OUT
(DATA0)
…..
OUT
(DATA0/1)
IN
(DATA1)
Control
Read
SETUP
(DATA0)
IN
(DATA1)
IN
(DATA0)
…..
IN
(DATA0/1)
OUT
(DATA1)
Setup
Stage
Status
Stage
SETUP
(DATA0)
IN
(DATA1)
No Data
Control
Control write transfers return information regarding the transaction in the data packet of the status stage. Control read
transfers return information regarding the transaction in the handshake packet of the status stage.
Table 9. Possible Status Stage Responses
Status Response
Control Write
Control Read
Request Complete
Zero-length Data Packet
ACK Handshake
Request Failed
STALL Handshake
STALL Handshake
Device Busy
NAK Handshake
NAK Handshake
Similar to bulk transfers, the data size is dependent on device speed and is limited to a maximum of 8 bytes for low
speed, maximum of 8, 16, 32, or 64 bytes on full speed, or a maximum of 64 bytes on high speed. Data packets in
control transfers are allowed to be less than the maximum packet size, specified in the Device Descriptor. On PSoC
3 and PSoC 5LP devices, the data size is limited to 8-bytes for EP0. The data stage is completed upon either
transferring the exact amount of data specified in the status stage, transferring a data payload less than what is
specified in wMaxPacketSize, or a zero length packet is received. When this occurs, the host moves on to the status
stage.
Because of the high overhead of a control transfer, 45 bytes versus 13 bytes of an interrupt transfer, this is not an
efficient way to constantly transfer data despite their guaranteed bandwidth, error correction, and lack of latency. As
shown back in Table 2, control transfers have a dedicated 10% of reserved bandwidth. If control transfers need to
exceed the 10% bandwidth, and there is spare bandwidth on the bus, they may do so. Additionally, if they go under
the 10% reserved bandwidth, they may reallocate bandwidth to bulk transfers.
7
USB Requests
USB requests are a major part of USB control transfers. The USB Specification describes three types of requests to
communicate to a device: standard, class, and vendor specific. All USB devices must support standard requests,
which are basic status and configuration commands. Class and vendor-specific commands, however, are optional.
Many USB devices are under a predefined USB class specification and support class commands. Examples of the
more common device specifications are Human Interface Device (HID), Mass Storage Device, or Communication
Device. There are some devices that do not fall under these or any other predefined classes. These are called
Vendor-Specific devices and are common with USB devices as it allows device designers to create custom
communication protocols for USB.
www.cypress.com
Document No. 001-56377 Rev. *L
19
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
USB Requests are how the USB host commands the device to provide it with information or perform specific control
and configuration operations. These requests are sent in the 8-byte data packet of the Setup phase of a Control
transfer. As mentioned in the Control Transfer section, these requests come across Endpoint 0. If we look at a
transfer of a USB request, you can see something similar to Figure 28.
Figure 28. Control Transfer of USB Request
S
E
T
U
P
A
D
D
R
E
P
D
A
T
A
0
C
R
C
5
Token
USB
REQUEST
PAYLOAD
DATA
C
R
C
1
6
DATA OUT
A
C
K
H/S
bmRequestType bRequest wValueL wValueH wIndexL wIndexH wLengthL wLengthH
The Token Packet (SETUP) identifies the receiver and identifies the transaction as a Setup transaction. The Data
Packet (DATA0) transmits the request and any related information to the request. The Handshake Packet (ACK)
identifies the devices acknowledgement of the transaction.
In Figure 28, note the various parameters such as bmRequestType, bRequest, wValue, and so on. These parameters
are what comprises the 8 bytes of the data in the Setup stage that the firmware decodes to know which request was
issued and how to handle it. The format of a USB request is illustrated in Table 10 and explained in greater detail.
Table 10. USB Request Format
Offset
Field
Size
Value
Description
0
bmRequestType
1
Bitmap
Characteristics of request (refer to Table 11)
1
bRequest
1
Value
Specific request (refer to Table 12)
2
wValue
2
Value
Word-sized field that varies according to request
4
wIndex
2
Index or Offset
Word-sized field that varies according to request; typically used to
pass an index or offset
6
wLength
2
Count
Number of bytes to transfer if there is a Data stage

bmRequestType is a byte that defines the direction of the transfer, the type of request, and the recipient of the
request. Bit 7 defines the transfer direction. Here, it is determined if the data is transferred from host to device, or
device to host. Bit 6 and bit 5 define the request type of the transfer such as Standard, Class, or Vendor. Bits 4
though 0 define who the request is directed to. This can be a device, interface, endpoint, or other. An example of
this can be seen in Table 11.
Table 11. bmRequestType Composition
Bits
7
Field
Direction
6..5
Type
4..0
Recipient
www.cypress.com

Values
0: Host to Device (OUT)
1: Device to Host (IN)
0: Standard
1: Class
2: Vendor
3: Reserved
0: Device
1: Interface
2: Endpoint
3: Other
4-31: Reserved
Document No. 001-56377 Rev. *L
bRequest is a byte that specifies a request.
Each request has a unique bRequest value.
As mentioned earlier, all USB devices must
respond to a Standard request. For
simplicity, we use a standard request as an
example. The USB Specification currently
defines eleven standard requests for control
transfers, which are listed in Table 12. Using
Table 12 as a reference, we can see the
various request numbers for each bRequest
with regards to a standard request.
20
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers

wValue is a two byte value, which the host uses to pass information to the device. What specifically goes into
these two bytes is dependent on what request has been made.

wIndex is a two byte value that the host uses to pass additional information to the device. Normally, this value
references an interface or endpoint. What specifically goes into these two bytes depends on the request that is
made.

wLength is a two byte value that contains the number of bytes in the data stage that will follow the SETUP
stage.
If the direction of the transaction, indicated by the Direction bit in bmRequestType, is an input request (device-tohost), the device can never send more than the number of bytes indicated by wLength. It may, however, return less. If
the request is an output (host-to-device), then wLength indicates the exact number of bytes to follow. A value 0 in
wLength indicates that this is not a data stage.
Now, let us look at a practical application of an USB Request. As mentioned, there are 11 standard requests for USB
that must be supported. Table 12 lists those requests and the parameters associated with them.
Table 12. Standard Device Request Table
bmRequestType
bRequest
wValue
wIndex
wLength
Data
CLEAR_FEATURE (0x01)
Feature Selector
Zero Interface
Endpoint
Zero
None
Zero
Zero
One
Configuration
Value
0000 0000b
0000 0001b
0000 0010b
1000 0000b
GET_CONFIGURATION
(0x08)
1000 0000b
GET_DESCRIPTOR (0x06)
Descriptor Type
and Index
Zero or
Language ID
Descriptor
Length
Descriptor
1000 0001b
GET_INTERFACE (0x0A)
Zero
Interface
One
Alternative
Interface
GET_STATUS (0x00)
Zero
Zero Interface
Endpoint
Two
Device,
Interface, or
Endpoint Status
GET_ADDRESS (0x05)
Device Address
Zero
Zero
None
SET_CONFIGURATION
Configuration
Value
Zero
Zero
None
SET_DESCRIPTOR (0x07)
Descriptor Type
and Index
Device Address
Descriptor
Length
Descriptor
SET_FEATURE (0x03)
Feature Selector
Feature Selector
Zero
None
0000 0001b
SET_INTERFACE (0x0B)
Alternative Setting
Alternative
Setting
Zero
None
1000 0010b
SYNCH_FRAME (0x0C)
Zero
Zero
Two
Frame Number
1000 0000b
1000 0001b
1000 0010b
0000 0000b
0000 0000b
0000 0000b
(0x09)
0000 0000b
0000 0001b
0000 0010b
For example, if a SET_ADDRESS request was sent, you may expect the bmRequestType to be configured with Hostto-Device as the direction, Standard as the type, and the Device as the recipient. According to Table 11, this gives us
a value of 00000000b. We can confirm this is the case in Table 12. Additionally in Table 12, bRequest contains a
value of 05h, wValue contains the device address, and all other fields (wIndex and wLength) are set to zero. There is
no data phase associated with this request since we see zero in the wLength field.
www.cypress.com
Document No. 001-56377 Rev. *L
21
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
Remember that Table 12 contains only standard requests. Class requests can be found in their supporting class
documentation. For example, the HID class specification lists various class requests such as GET_REPORT and
GET_PROTOCOL. Be sure to reference those documents when appropriate. Vendor requests, on the other hand,
are not listed in any documentation since they are custom commands that you, the developer, create. When
developing a vendor request, bmRequestType always follows the format defined in Table 11. However, you can
define your own RequestType value, and populate wValue, wIndex, and Data Phase (Data phase only if wLength is
greater than zero) as appropriate. Figure 29 shows the different paths bmRequestType can follow for various USB
Requests.
Figure 29. USB Request Types Chart
bmRequestType:
bmRequestType:
D7: D6: D5: D4: D3: D2: D1:
X
0
0
X
X
X
X
D7: D6: D5: D4: D3: D2: D1:
X
1
0
X
X
X
X
Class
Class
Standard
00
bmRequestType:
D7: D6: D5: D4: D3: D2: D1:
X
0
1
X
X
X
X
bRequest
Vendor
bRequest
GET_STATUS
01
GET_REPORT
CLR_FEATURE
02
GET_IDLE
03
SET_FEATURE
03
GET_PROTOCOL
05
SET_ADDRESS
09
SET_REPORT
06
GET_DESCRIPTOR
0A
SET_IDLE
07
SET_DESCRIPTOR
0B
SET_PROTOCOL
08
GET_CONFIG
Other
STALL
09
SET_CONFIG
0A
GET_INTERFACE
0B
SET_INTERFACE
0C
SYNC_FRAME
01
Other
STALL
bmRequestType:
D7: D6: D5: D4: D3: D2: D1:
X
1
1
X
X
X
X
Reserved
Custom
Programming
STALL
wValueH
01
DEVICE
02
CONFIGURATION
03
STRING
21
HID
22
REPORT
23
PHYSICAL
Other
STALL
By adjusting the bmRequestType field, you can issue the same request to different recipients. Table 13 shows an
example of how we can issue the same request by simply changing the recipient (bits 4..0) in bmRequest Type.
Table 13. Same Request with Different Recipients
Dir
Type
Recipient
Request
Result
IN
STD
DEV
GET_STATUS
Return device status to host
IN
STD
IF
GET_STATUS
Return interface status to host
IN
STD
EP
GET_STATUS
Return endpoint status to host
In some cases, the same request can be issued but with different request types. For example, there is a
GET_DESCRIPTOR command under Standard Requests and one under HID Class Requests (with Standard and
HID being the request types). The information that is returned depends on which request type is used. When
bmRequestType = 00, bRequest specifies that a standard USB request is issued. When bmRequestType = 01,
bRequest specifies that a device class request is issued. An example of this can be seen in Table 14.
Table 14. Same Request with Different Types
Dir
Type
Recipient
Request
Result
IN
STD
DEV
GET_DESCRIPTOR
Return DEVICE, CONFIG or STRING
descriptor based on wValue
IN
CLS
DEV
GET_DESCRIPTOR
For HID class, return HID, REPORT
or PHYSICAL descriptor based on
wValue. Differs for other classes.
www.cypress.com
Document No. 001-56377 Rev. *L
22
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
PSoC Creator automatically generates code to handle standard USB requests and some class requests. You as the
developer only need to focus on loading data into and out of the endpoint buffers using the provided PSoC Creator
APIs, which are described in the USBFS component datasheet. This application note discusses how to use those
APIs in conjunction with custom functions to handle vendor specific commands later on in the code examples.
8
Bus Bandwidth Management
Any transfer performed by a USB device requires some fraction of the USB bandwidth. Since the host is responsible
for controlling the transfers on the bus, the host is also responsible for managing the bandwidth on the bus. The
process of assigning bandwidth on the bus is known as Transfer Management. It is not just the host that makes the
decision. There are multiple components that work together to move data over the bus.
During the enumeration of a USB device, the host allocates bus bandwidth for Interrupt and Isochronous endpoints,
and continues to do so as long as they remain connected to the bus. Bulk endpoints are not included since they do
not have guaranteed bus bandwidth. Instead, they use whatever bandwidth is available. The USB specification
places a limit on the allocation of bandwidth for these endpoints by stating that not more than 90% of a frame can be
allocated to periodic transfers, which are interrupt and isochronous transfers, on a full speed device. This requirement
is even stricter on a high speed bus, which regulates that no more than 80% of a microframe can be allocated for
periodic transfers. On a full speed bus, this is not to say that the remaining 10% of the bus bandwidth is used for Bulk
transfer, but this is the 10% reserved bandwidth for Control transfers. Bulk transfers only get what remains in USB
frames from the interrupt or Isochronous transfers.
Figure 30. USB Traffic on the Bus Example
A
I D E
N D P
R
TOKEN
Interrupt
Transfer
(Mouse)
Isochronous Transfer
(Audio Device)
Idle Time
(No Traffic)
C
R
C
5
D
A
T
A
0
PAYLOAD
DATA
DATA IN
Interrupt
Transfer
(Mouse)
Frame 1 (1ms)
C
R
C
1
6
A
C
K
These transactions only
occur if there is not any
higher priority traffic
H/S
Interrupt
Transfer
(Keypad)
Bulk Transfer
(Flash Drive)
Frame 2 (1ms)
Idle
Time
(No
Traffic)
Interrupt
Transfer
(Mouse)
Bulk Transfer
(Flash Drive)
Idle Time
(No Traffic)
Frame 3 (1ms)
Figure 31. USB Controller Bandwidth Exceeded
When a bus is overused, in a Windows
environment, you can expect to see a window
such as the one shown in Figure 31 appear. In
this figure we can see two host controllers. In
AN57294 - USB 101, it is discussed that there
are often two host controller chips in a host. An
EHCI controller for High Speed transfers and
either an OHCI or UHCI for Low and Full Speed
transfers. In the following figure, this machine has
EHCI and OHCI controllers. Note that the various
percentage of used bus bandwidth adding up.
www.cypress.com
Document No. 001-56377 Rev. *L
23
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
9
USB Error Correction and Detection
Error correction is a major part of USB communication. You need to be aware when something has gone wrong in
your communication so that you can compensate or ignore data. There are two forms of error correction in a USB
system. Error checking bits are included with packets and are calculated with a mathematical equation defined by the
USB specification. This error checking is called the Cycle Redundancy Check (CRC). The second form of error
correction is the data toggle. The data toggle is a form of synchronization between the device and host using the
Packet ID (PID) in a data packet. Keeping track of this data toggle can alert you to an error in the transaction.
Additionally, handshake packets are a form of error correction, though they are, by definition, not. However,
handshake packets can give a lot of insight to the activity on the bus. How the device or host responds to something
can, especially if it is a negative response, can indicate that is something is wrong.
9.1
CRC Check
CRC is commonly used by hard drives and communication interfaces such as CAN. A CRC is calculated for all token,
data, and start of frame packets. The token and start of frame packets have a 5-bit CRC and the data packets have a
16-bit CRC.
Table 15. CRC Reference Table
Packet
Fields Used in CRC
Number of CRC Bits
Start of Frame
Frame Number
5 bits
IN
Device Address and
Endpoint Number
5 bits
OUT
Device Address and
Endpoint Number
5 bits
SETUP
Device Address and
Endpoint Number
5 bits
DATA0/DATA 1
Data Payload
16 bits
These CRCs are based on a generator polynomial. Details regarding the algorithm can be found in Section 3.5 of the
USB 2.0 Specification. The CRC calculations are handled by the USB hardware. Because no software is required to
handle the calculations, this application note does not discuss the math in detail. When a packet is transmitted, the
device that does the transmission performs the calculation. The result of the calculation is then included with the
packet transfer (see Figure 32).
Figure 32. CRCs in USB Packets
Packet #
50
F
S
Sync
00000001
SOF
0xA5
Packet #
50
F
S
Sync
00000001
Setup
0xB4
Packet #
51
F
S
Sync
00000001
DATA0
0xC3
Frame #
512
ADDR
0
CRC5
0x02
ENDP
0
EOP
3.00
CRC5
0x08
DATA
80 06 00 01 00 00 40 00
Idle
4
EOP
3.00
Idle
2
CRC16
0xBB29
EOP
2.75
Idle
5
The recipient of the packet then performs the same calculation of what it received and compares the CRC that was
transmitted to the CRC it calculated. If the two match, then the data is received without error and the ACK handshake
is returned by the recipient. If the two CRCs do not match, then the recipient of the data never responds with a
handshake, indicating there is something wrong with the transaction and causing the sender to resend the data. The
resend occurs after a timeout period, which is ~16 bit times long. The only exception to this is with an isochronous
transfer.
www.cypress.com
Document No. 001-56377 Rev. *L
24
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
Figure 33. CRCs Error
Packet #
100
F
S
Sync
00000001
IN
0x96
Packet #
101
F
S
Sync
00000001
DATA1
0xD2
ADDR
2
ENDP
2
CRC5
0x01
EOP
2.50
Idle
5
DATA
11 22 33 44 55 66 77 88 99 00 AA BB CC DD EE FF
CRC16
0x5748
EOP
3.00
Idle
7
Bad CRC:
Expected 0x4748
9.2
PID Check
While token packets use a CRC against the device address and endpoint number, let us see how error checks are
done against the PID. They implement something significantly simpler then a polynomial equation. 1’s compliment is
used to determine if there is an error in the PID. Figure 34 shows the composition of the PID. The receiver of the PID
compliments the Error check bits and compares them to the PID Type bits. If they do not match, then the packet is
ignored. There is not a retry event.
Figure 34. PID Check Format
PID Type
PID[0]
PID[1]
PID[2]
Error Check
PID[3]
_____
PID[0]
_____
PID[1]
_____
PID[2]
_____
PID[3]
In the Transfer Composition section, Table 1 listed the various PID values. Note the table only lists 4 bits of an 8-bit
value. The other four bits (MSbs) are the error checking.
9.3
Data Toggle
Data toggle ensures that data does not go missing when you have multiple data transactions. It acts as an error
checking system. The idea behind the data toggle is to have an endpoint alternate between DATA1 and DATA0. The
device and host keep track of the data toggle on a particular endpoint. When a USB device is configured, the data
toggle is initially set to DATA0. This provides synchronization between the host and device by putting them on the
“same page”.
Figure 35. Data Toggle on Data Packets
When data is transferred, the receiver of the data compares the data toggle of the data packet with its own known
data toggle. If these values match, then the receiver of the data issues an ACK as its handshake. When the sender of
the data packet receives this ACK, then it changes its Data Toggle value in preparation of the next transaction. If
there is another data packet to transfer, then the Data Toggle changes to DATA1. This continues back and forth until
all data has been transferred. An example of data toggle being used in USB transaction can be seen in Figure 36.
This process is shown in Figure 37.
www.cypress.com
Document No. 001-56377 Rev. *L
25
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
Figure 36. USB Bus Analyzer Trance of Data Toggle
Data PID toggles after
each transfer to the same
endpoint
Transaction
200
F
S
IN
0x96
ADDR
2
ENDP
1
T
0
DATA
00 02 FF 00
ACK
0x4B
Time
7.999 ms
Transaction
201
F
S
IN
0x96
ADDR
2
ENDP
1
T
1
DATA
00 01 FD 00
ACK
0x4B
Time
7.999 ms
Transaction
202
F
S
IN
0x96
ADDR
2
ENDP
1
T
0
DATA
00 00 FD 00
ACK
0x4B
Time
7.999 ms
Transaction
203
F
S
IN
0x96
ADDR
2
ENDP
1
T
1
DATA
00 FF FD 00
ACK
0x4B
Time
7.999 ms
Transaction
204
F
S
IN
0x96
ADDR
2
ENDP
1
T
0
DATA
00 FC FE 00
ACK
0x4B
Time
7.999 ms
Transaction
205
F
S
IN
0x96
ADDR
2
ENDP
1
T
1
DATA
00 FA FE 00
ACK
0x4B
Time
7.999 ms
Figure 37. Example of Successful Data Toggles
Host
Device
IN Packet
DATA 0 Packet
Transaction 1:
ACK Packet
T
Data
Accepted
0
T
T
1
0
Host
T
ACK
1
Device
IN Packet
DATA 0 Packet
Transaction 2:
ACK Handshake
T
Data
Accepted
1
T
T
0
1
T
ACK
0
However, if the receiver detects a mismatch between its data toggle and the data toggle of the packet, it responds by
not sending a handshake packet.
Figure 38. Data Toggle Error
Packet #
100
F
S
Sync
00000001
IN
0x96
Packet #
101
F
S
Sync
00000001
DATA1
0xD2
Packet #
102
F
S
Sync
00000001
ACK
0x4B
EOP
3.00
Packet #
103
F
S
Sync
00000001
IN
0x96
ADDR
2
Packet #
104
F
S
Sync
00000001
DATA1
0xD2
www.cypress.com
ADDR
2
ENDP
2
CRC5
0x01
EOP
2.50
Idle
5
DATA
11 22 33 44 55 66 77 88 99 00 AA BB CC DD EE FF
CRC16
0x4748
EOP
3.00
Idle
7
CRC16
0x4748
EOP
3.00
Idle
7
Idle
11793
ENDP
2
CRC5
0x01
EOP
2.50
Idle
5
DATA
11 22 33 44 55 66 77 88 99 00 AA BB CC DD EE FF
Document No. 001-56377 Rev. *L
26
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
There are two potential scenarios where you see the data toggle being extremely useful in error correction:
Scenario 1: The receiver returns a NAK because it is not ready to send data or the receiver detects corrupted data
(CRC Failure) and does not send a handshake. In these cases, the sender does not update its data toggle and
attempts to resend the packet with the same data and data toggle. An example is seen in Figure 39.
Figure 39. Example of Data Toggle with Corrupted Data
Host
Figure 40. Example of Data Toggle with Corrupted
Handshake
Device
Host
Device
IN Packet
IN Packet
DATA 0 Packet
(Corrupted Data)
Transaction 1:
T
Data
Rejected
0
T
T
0
0
Host
DATA 0 Packet
Transaction 1:
No Response
No
H/S
T
T
0
Data
Accepted
0
Device
ACK Handshake
(Corrupted)
T
T
1
0
Host
Failed
ACK
T
0
Device
IN Packet
IN Packet
DATA 0 Packet
Transaction 2:
0
Data
Accepted
DATA 0 Packet
Transaction 2:
ACK Handshake
T
T
T
1
0
ACK
ACK Handshake
T
T
1
Data
Ignored
1
T
T
1
0
Received
ACK
T
1
Scenario 2: If the receiver returns an ACK handshake and it becomes corrupted. In this case, the sender of the data
assumes that the receiver did not get the data and attempts to resend the same data with the same data toggle. The
receiver then does not update its data toggle, ignores the data, and returns an ACK handshake (see Figure 40).
10
Handshake
Handshake packets are essential in USB communication to ensure that data is properly received. They provide a
closed loop system and contribute heavily to error correction and debugging in USB applications. In an ideal world, all
USB transactions occur flawlessly and data does not become corrupt, there is always data ready to transmit, and all
USB requests are understood. Since there is no such thing as an ideal USB transaction, we have handshake
packets. These packets give us a closed loop system with Control, Interrupt, and Bulk transfers to provide two way
communications between the device and the host.
AN57294 mentions that Handshake packets are used to conclude each transaction. Each handshake includes an 8bit packet ID and is sent by the receiver of the transaction. There are multiple options for a handshake response and
which ones are supported depend on the USB speed. Additionally, there are four standard handshake packets: ACK,
NAK, STALL, and NYET. Since NYET is a high speed handshake, and PSoC is a full speed device, this application
does not discuss it.
Handshakes are used to report many things about a device such as successful completion of data, request command
acceptance or rejection, or flow control. Following are the three full speed handshakes:

ACK: Acknowledge successful completion and error free receipt of a data packet. An ACK indicates that the
packet was received without any data toggle, bit stuff, or CRC errors. An ACK can be issued by the host in the
case of IN transactions and by the device in the case of OUT and SETUP transactions. Figure 41 shows an
example of an ACK transaction on a bus analyzer.
Figure 41. Example of a ACK in a Transfer
Packet #
300
F
S
Sync
00000001
IN
0x96
Packet #
301
F
S
Sync
00000001
DATA1
0xD2
Packet #
302
F
S
Sync
00000001
ACK
0x4B
www.cypress.com
ADDR
3
ENDP
0
CRC5
0x0A
DATA
12 01 00 02 00 00 00 08
EOP
3.00
EOP
3.00
Idle
2
CRC16
0xEAE7
EOP
3.00
Idle
7
Idle
11793
Document No. 001-56377 Rev. *L
27
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers

NAK: Negative acknowledgement. Indicates that a device was unable to accept data from the host in the case of
a OUT request, or that the function does not have any data to transmit to the host in the case of an IN request.
NAKs only occur in the data phase of an IN transaction or the handshake phase of an OUT transaction.
Additionally, only a device can issue a NAK. The host is not capable of sending a NAK. They are used for flow
control purposes to inform the host that the device is temporarily unable to transmit or receive data. Figure 42
shows an example of a NAK transaction on a bus analyzer.
Figure 42. Example of a NAK in a Transfer
Packet #
200
F
S
Sync
00000001
IN
0x96
ADDR
2
ENDP
1
Packet #
201
F
S
Sync
00000001
NAK
0x5A
EOP
3.00
Idle
54

CRC5
0x18
EOP
2.50
Idle
8
STALL: Error indication sent by a device. Stalls are returned by a device in response to an IN token packet or an
OUT data packet. Stalls indicate that the device is unable to transmit or receive data, or a request made through
the control pipe is not supported. Stall handshake packets can only be sent by the device. A host cannot issue a
stall. Figure 43 shows an example of a STALL transaction on a bus analyzer.
Figure 43. Example of a STALL in a Transfer
11
Packet #
100
F
S
Sync
00000001
IN
0x96
ADDR
5
ENDP
0
Packet #
101
F
S
Sync
00000001
STALL
0x78
EOP
3.00
Idle
11883
CRC5
0x0B
EOP
2.50
Idle
8
Error Detection in PSoC 3 and PSoC 5LP
Detecting these errors on PSoC 3 and PSoC 5LP is accomplished with the help of the SIE on the device. Located in
the register reference of the PSoC 3/PSoC 5LP Technical Reference Manual (TRM), there are multiple registers
called non control endpoint control registers. These are the control registers for EP1 through EP8. Specifically, the
register is named USB_SIE_EPx_CR0, where ‘x’ is replaced by an endpoint number. Looking at
USB_SIE_EP1_CR0, for example, bit 6 is named err_in_txn.
Table 16. USB_SIE_EPx_CR0 Register Definition
Bits
7
6
5
4
3
2
Name
stall
err_in_txn
nak_int_en
acked_txn
mode
1
0
The err_in_txn bit is set whenever an error is detected. For an IN transaction, this indicates that no response was
received from the host. For an OUT transaction, this bit represents a receive error and includes PID error, CRC
errors, and bit stuff errors. Users who wish to implement error checking should read this register after polling the OUT
endpoint buffer to see if it is full. If this bit is set, then disregard the data. Table 17 provides a list of the different CR0
registers for the eight endpoints PSoC 3 and PSoC 5LP devices contain.
Table 17. USB_SIE_EPx_CR0 Registers
Register
PSoC 3 Address
PSoC 5LP Address
USB_SIE_EP1_CR0
0x600E
0x4000600E
USB_SIE_EP2_CR0
0x601E
0x4000601E
USB_SIE_EP3_CR0
0x602E
0x4000602E
USB_SIE_EP4_CR0
0x603E
0x4000603E
USB_SIE_EP5_CR0
0x604E
0x4000604E
USB_SIE_EP6_CR0
0x605E
0x4000605E
USB_SIE_EP7_CR0
0x606E
0x4000606E
USB_SIE_EP8_CR0
0x607E
0x4000607E
www.cypress.com
Document No. 001-56377 Rev. *L
28
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
12
PSoC Logical Transfer Modes
One of the many benefits of PSoC 3 and PSoC 5LP is its ability to support different transfer modes to the USB
hardware. In all of the PSoC USB application notes, the CPU has been used to move data into the endpoints to
prepare for transfer. However, there is another option: use the DMA to move data into and out of the USB memory.
The biggest benefit of this is that the DMA can move the data much faster than the CPU, which increases the capable
throughput of the USB device.
Logical transfer modes are a combination of memory management and DMA/CPU configurations. PSoC 3 and
PSoC 5LP have a 512 byte SRAM that is shared by 8 data endpoints (EP1 to EP8) and 1 control endpoint (EP0). The
management of this memory is done either automatically by PSoC or manually by the developer. These modes relate
to data transfer within the USB block (data from SRAM to each endpoint) and are unrelated to the various transfer
types discussed in this application note (such as, Interrupt, Bulk, Isochronous, and Control). The PSoC 3 / PSoC 5LP
TRM mentions two types of logical transfer modes as shown in Table 18.
Table 18. USB Transfer Modes
Feature
Store and Forward Mode
Cut Through Mode
SRAM Memory Usage
Requires More Memory
Requires Less Memory
SRAM Memory
Management
Manual
Automatic
SRAM Memory
Sharing
512 bytes of SRAM shared between
endpoints. Sharing is done by firmware.
Each endpoint is allocated less share of memory
automatically by the block. Rest of memory is available as
“Common Area.” This Common Area is used during the
transfer.
IN Command
Entire packet present in SRAM memory
before the IN command is received.
Memory filled with data only when SRAM IN command is
received.
Data is given to host when enough data is available
(based on DMA configuration). Does not wait for the
entire data to be filled.
OUT Command
Entire packet is written to SRAM memory on
OUT command. After entire data is available,
it is copied from SRAM memory to the USB
device.
Waits only for enough bytes (depends on DMA
configuration) to be written in SRAM memory. Once
enough bytes are present, it is immediately copied from
SRAM memory to the USB device.
Transfer of Data
Data is transferred when all bytes have been
written to the memory.
Data is transferred when enough bytes are available. It
does not wait for the entire data to be filled.
Types Based on DMA
No DMA mode
Only Automatic DMA mode
Manual DMA mode
Recommended
Transfer
Best suited for Interrupt and Bulk transfers
Best suited for Isochronous transfer
PSoC supports a maximum packet size of 64 bytes using the Store and Forward mode and a maximum packet size
of 1023 bytes, which is the limitation of a full speed isochronous transfer, using the Cut Through mode.
As mentioned in Table 18, the Cut Through mode is an automatic memory management mode with automatic DMA
access. The CPU performs initial configuration and then transfers control to the USB hardware to control partitioning
of the 512 bytes of SRAM and handle the pointers to that memory. Each active IN endpoint is allocated a small
amount of memory using the BUF_SIZE register. The remaining memory, after all the IN endpoints have been
allocated, is referred to as “common space memory”.
When an IN transfer request is made by the host, the device responds by transferring the data present in the
dedicated memory space for that specific endpoint. At the same time, the device issues a DMA request for more data
to be moved to that memory space. This data fills up the common space memory. The device does not wait for the
entire data payload to be available. For more information regarding USB Logical Transfer Modes, refer to the PSoC 3
/ PSoC 5LP TRM.
www.cypress.com
Document No. 001-56377 Rev. *L
29
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
13
Example Project Files
Up to this point, this application note has focused on the concepts and structure of data transfers under the USB 2.0
specification. The next step is to apply these different transfer types to simple example projects. The intention is to
get the user comfortable with implementing these transfer types in very basic examples, so that they feel more
comfortable implementing them in other practical applications. There are three example projects that will be explored.
These example projects cover topics such as how to implement basic control, interrupt, bulk, and isochronous
communication, implement vendor-commands, and use the DMA in PSoC to move USB data around.
13.1
Important Note on CyUSB Drivers
Accompanying this application note are digitally signed drivers by Microsoft that have undergone WHQL testing. This
in return prevents Windows from returning a warning (such as the one shown below) regarding the driver being
unsigned.
Figure 44. Driver Signing Warning in Windows
The signatures associated with the driver are linked to the INF file and the device VID/PID combination. Should any
of these parameters be altered, the driver signature would become invalid and the warning message shown prior
would appear with the device being unable to enumerate correctly in 64-bit Windows OS’s, regardless of clicking the
“Install this driver software anyway” button. As a result, when evaluating the example projects/lab exercises, ensure
to not make any changes to the discussed parameters.
Additionally, the drivers are only signed for Windows XP, Windows Vista, and Windows 7. They are not signed for
Windows 8 operating systems. Should you need to use these drivers in a Windows 8 or Windows 10 environment,
please refer to the steps outlined in Appendix A to disable driver signature enforcement. Should you want to use the
CyUSB driver in a production design, it will need to be subjected to Windows certification independently. More details
regarding WHQL certification can be found in AN57294 - USB 101: Introduction to Universal Serial Bus.
www.cypress.com
Document No. 001-56377 Rev. *L
30
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
14
Project 1: Implementing Multiple Transfer Types
This project demonstrates how to implement interrupt, bulk, and isochronous endpoints into a design. The application
reads data received in an OUT endpoint for a particular transfer, and perform a loopback by loading that data into a
corresponding IN endpoint. This project also demonstrates how to implement Alternate Settings for a single interface
in a design.
14.1
Configuring the Project
1.
Start by opening an empty PSoC Creator project and name it “Project 1 – USB Transfers”.
2.
Locate the USBFS component in the Component Catalog in PSoC Creator and drag it onto the schematic page
(TopDesign.cysh).
Figure 45. Project 1 – Schematic
3.
Right click on the USBFS component and click Configure. After the configuration window opens, click on
Descriptor Root. Ensure that the selections are made as shown in Figure 46:

Endpoint Memory Management: Manual with Static Allocation
Figure 46. Project 1 – Memory Management Mode Config
www.cypress.com
Document No. 001-56377 Rev. *L
31
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
4.
Next, configure the device descriptors for this USB design. Click on Device Descriptor and configure the options
in the Device Descriptor (see Figure 47). Make the following adjustments:





Vendor ID: 0x04B4
Product ID: 0xE175
Device Class: Vendor Specific
Manufacturing String: Cypress Semiconductor
Product String: Project 1: Implementing Multiple Transfer Types
Figure 47. Project 1 – Device Descriptor
www.cypress.com
Document No. 001-56377 Rev. *L
32
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
5.
Next, click on Configuration Descriptor and adjust the configuration options as follows (see Figure 48):



Configuration String: Configuration 1
Max Power: 80
Device Power: Bus Powered
Figure 48. Project 1 – Configuration Descriptor
In this example, there is a single interface, whose function is to loopback data. To implement different interfaces for
the three transfer types, alternate settings will be used. Each setting has a pair or Interrupt, Bulk, and Isochronous
IN/OUT endpoints. Therefore, all three transfer type pairs are never simultaneously active.
Using alternate settings for these endpoints accomplishes two things:


It allows you to easily switch between the transfer types you want to use.
It is easier on the bus bandwidth. Rather than having an interrupt and isochronous endpoints reserving
bandwidth they are not using, you can use the alternate settings to only reserve the bandwidth that you use.
For this example, you will reserve bandwidth for 8 bytes on each endpoint. While this is not enough to cause issues
with bus bandwidth, this is a good practice to get in the habit of with regard to USB development.
6.
Click on the Interface Descriptor in the USB configuration wizard and then click on Add Alternate Setting (see
Figure 49) thrice to add three additional alternate settings to the design. The end result should look like what is
shown in Figure 50.
www.cypress.com
Document No. 001-56377 Rev. *L
33
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
Figure 49. Project 1 – Adding Alternate Settings
Click
Here
Figure 50. Project 1 – After Adding Alternate Settings
7.
Click on the Endpoint Descriptor located under Alternate Setting 0 and click on the 'X' to remove the endpoint
descriptor (see Figure 51).
www.cypress.com
Document No. 001-56377 Rev. *L
34
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
Figure 51. Project 1 – Removing EP from Alt. Setting 0
Click Here
This endpoint must be removed because devices with isochronous endpoints are required to have a zero bandwidth
setting to free up bus availability when the isochronous endpoints are not in use.
www.cypress.com
Document No. 001-56377 Rev. *L
35
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
8.
Click on Alternate Setting 0 in the configuration wizard and apply the following configuration options (Figure 52).


Interface String: Zero Bandwidth Interface
Class: Vendor Specific
Figure 52. Project 1 – Alternate Setting 0 Configuration
9.
Click on Alternate Setting 1 in the configuration wizard and apply the following configuration options (see Figure
53). Additionally, click on the “Add Endpoint” button to add a second endpoint to Alternate Setting 1.


Interface String: Interrupt Interface
Class: Vendor Specific
Figure 53. Project 1 – Alternate Setting 1 Configuration
Click Here
www.cypress.com
Document No. 001-56377 Rev. *L
36
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
10. Click on the first Endpoint Descriptor under Alternate Setting 1 and configure it based on the following settings
(see Figure 54).





Endpoint Number: EP1
Direction: IN
Transfer Type: INT
Interval: 10
Max Packet Size: 8
Figure 54. Project 1 – Endpoint 1 Configuration
www.cypress.com
Document No. 001-56377 Rev. *L
37
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
11. Now click on the second Endpoint Descriptor under Alternate Setting 1 and configure it based on the following
settings (see Figure 55).





Endpoint Number: EP2
Direction: OUT
Transfer Type: INT
Interval: 10
Max Packet Size: 8
Figure 55. Project 1 – Endpoint 2 Configuration
www.cypress.com
Document No. 001-56377 Rev. *L
38
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
12. Click on Alternate Setting 2 and add an additional endpoint descriptor (similar to step 9). Apply the following
configuration options (see Figure 56) to Alternate Setting 2.


Interface String: Bulk Interface
Class: Vendor Specific
Figure 56. Project 1 – Alternate Setting 2 Configuration
www.cypress.com
Document No. 001-56377 Rev. *L
39
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
13. Click on the first Endpoint Descriptor under Alternate Setting 2 and configure it based on the following settings
(see Figure 57).




Endpoint Number: EP3
Direction: IN
Transfer Type: BULK
Max Packet Size: 8
Figure 57. Project 1 – Endpoint 3 Configuration
www.cypress.com
Document No. 001-56377 Rev. *L
40
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
14. Now click on the second Endpoint Descriptor under Alternate Setting 2 and configure it based on the following
settings (see Figure 58).




Endpoint Number: EP4
Direction: OUT
Transfer Type: BULK
Max Packet Size: 8
Figure 58. Project 1 – Endpoint 4 Configuration
www.cypress.com
Document No. 001-56377 Rev. *L
41
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
15. Finally, configure the third alternate setting. Click on Alternate Setting 3 and add an additional endpoint
descriptor just as you did in the previous step. Apply the following configuration options (see Figure 59) to
Alternate Setting 3.


Interface String: Isochronous Interface
Class: Vendor Specific
Figure 59. Project 1 – Alternate Setting 3 Configuration
www.cypress.com
Document No. 001-56377 Rev. *L
42
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
16. Click on the first Endpoint Descriptor under Alternate Setting 3 and configure it based on the following settings
(see Figure 60).







Endpoint Number: EP5
Direction: IN
Transfer Type: ISOC
Synch Type: No Synchronization
Usage Type: Data Endpoint
Interval: 1
Max Packet Size: 8
Since you are only going to stream data to the PC, you do not need to synchronize the PSoC to another device.
Therefore, choose “No Synchronization” and configure the endpoint as a data endpoint rather than a feedback
endpoint.
Figure 60. Project 1 – Endpoint 5 Configuration
www.cypress.com
Document No. 001-56377 Rev. *L
43
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
17. The last thing to configure in the wizard is the OUT ISOC endpoint. Click on the second Endpoint Descriptor
under Alternate Setting 3 and configure it based on the following settings (see Figure 61).







Endpoint Number: EP6
Direction: OUT
Transfer Type: ISOC
Synch Type: No Synchronization
Usage Type: Data Endpoint
Interval: 1
Max Packet Size: 8
Figure 61. Project 1 – Endpoint 6 Configuration
18. After all these changes are complete, click Apply and then OK to close out the configuration wizard.
19. Next, you must configure the pins and clocks for the project. In the Workspace Explorer in PSoC Creator, locate
“Project 1 - USB Transfers.cydwr” and double click on it to open a new configuration tab. The first item that
appears is the Pin Configuration. On the upper right hand side of the screen, there are two pins for the D+ and Dlines (see Figure 62). You can manually assign the D+ P15[6] and D- to P15[7]. However, since these are the
only two pins that these signal lines can be assigned to, this is a step that can be skipped as PSoC Creator
automatically assigns the pins to the proper location upon building the project.
Figure 62. Project 1 – Pin Configuration
www.cypress.com
Document No. 001-56377 Rev. *L
44
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
20. Click on the Clocks tab at the bottom of the screen. You will see a screen showing various rows and columns of
clocks as shown in Figure 63. Double click on any of the clocks to open the clocks configuration wizard.
Figure 63. PSoC Creator Clocks
21. Once you open the configuration wizard, adjust the clocks to the following specifications (see Figure 64). Click
OK upon completion of this step.





IMO: 24 MHz
ILO: 100 kHz
PLL: 48 MHz
USB: Check box to enable, set to IMOx2
Master Clock: PLL Out
Figure 64. Clocks Configuration Wizard
ILO clock must
be set to 100kHz
www.cypress.com
USB clock
must be 48MHz
Document No. 001-56377 Rev. *L
45
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
22. The last step that needs to be performed prior to programming out design into a PSoC is to place some code into
main.c. Located in Appendix C is the code for Project 1. Double click on the main.c file, located under source
files in the Workspace Explorer. Place this code in main.c. The code provided in Appendix C is commented to
provide additional context to overall functionality.
The GUI application used with this project is the Cypress USB Control Center. When you want to activate the
different Alternate Settings, the Control Center issues the USB request to switch over to that specific setting,
which we will look at later. The firmware in the PSoC device checks for the change in interface setting (alternate
setting) and executes the proper code for that alternate setting by polling, reading, and loading the proper
endpoints. Additionally, when information is received on the OUT endpoint, the firmware loads that data into the
paired IN endpoint to be read by the host.
23. The next step is to build the project so that it can be programmed into the device. In PSoC Creator, locate the
Project drop down menu at the top of the screen. Select Build > Build Project 1 – USB Transfers. After the
project is built without errors or warnings, program a PSoC 3 or PSoC 5LP device.
14.2
Testing the Project
One of the prerequisites of this application note is to download Cypress Suite USB v3.4.6 or later. Navigate to the
application folder from your Windows Start menu and open Control Center. You can find the application under All
Programs > Cypress > Cypress Suite USB 3.4.7 > Control Center.
24. Plug the PSoC into an open USB port on a PC. Since PSoC is configured as a Vendor Specific device, Windows
asks for a driver (.inf and .sys). Navigate windows to the “Driver” folder, included with the project files for this
application note.
Note: If you do not have access to the driver files, locate the INF file in Appendix B. Open an empty Notepad
document in Windows and place the text in Appendix B in the document. Save the file as AN56377.inf.
When Windows asks for the .sys file, navigate to the Cypress Suite USB folder. Depending on your operating
system, the path should be similar to the following:
C:\Cypress\Cypress Suite USB 3.4.7\Driver\bin
From that point, navigate further to the appropriate Operating System (such as Windows XP or Windows
Vista/7/8) and Operating System type (32-bit or 64-bit). Remember that when following this second method, the
driver will not be signed and may prevent the driver from being installed properly. It is recommended to use the
drivers that were downloaded with the associated project files.
25. After the PSoC has been enumerated, open USB Control Center, and expand out all the tabs on the left hand
side of the application. See Figure 65.
Figure 65. Project 1 in USB Control Center
www.cypress.com
Document No. 001-56377 Rev. *L
46
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
Note that there is a zero bandwidth alternate setting (Alternate Setting 0) and three other alternate settings
(Alternate Setting 1 through Alternate Setting 3) with the various endpoint types. Upon enumeration, Alternate
Setting 0 is selected by default.
26. Select Interrupt out endpoint (0x02), which is located under Alternate Setting 1, and click on the Data
Transfers tab. In the Data to send (Hex) text field, go ahead and place 8 hex bytes, followed by clicking
Transfer Data-OUT. Then click on Interrupt in endpoint (0x81) and click the Transfer Data-IN button. Note
that a successful IN and OUT transfer occurs in the status window (see Figure 66).
Figure 66. Testing Project
Going a step further and looking at a Bus Analyzer trace, note that a control transfer also took place prior to the
loopback data transfer. The control transfer switched the alternate setting from Alternate Setting 0 to Alternate Setting
1. Figure 67 shows the following information:


Transaction 0: Setup Stage


Transaction 2: OUT Transaction (Host to Device)
Transaction 1: Status Stage (No data stage occurred between the Setup and Status stage since wLength was
set to 0).
Transaction 3: IN Transaction (Device to Host)
Figure 67. Project 1 on a Bus Analyzer
You can experiment with the other transfer types. The general concept is similar in terms of implementation.
Isochronous can be more complex, however, depending on the configuration. While using the USB Control center,
you may transfer less than eight bytes when using interrupt and bulk. With the isochronous transaction, you will need
to transfer exactly eight bytes. This is not a limitation of USB but intended functionality of the CYUSB driver. Be sure
to fill in the “Bytes to Transfer” fields appropriately.
www.cypress.com
Document No. 001-56377 Rev. *L
47
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
Figure 68 shows the three various transfer types (Interrupt, Bulk, and Isochronous) and an OUT transfer for each
one, performed using this code example. You can see the three control transfers that change the Alternate Setting
(by using the SET_INTERFACE request). Also note the lack of a handshake packet in the isochronous transaction,
shown in Transaction 8.
Figure 68. Various USB OUT Transactions
14.3
Taking Project 1’s Concepts Further
With a basic understanding of what is involved in getting two-way communication between the device and the host
using interrupt, bulk, and isochronous transfers, the next step is to expand upon Project 1 to support more data in a
single transfer. Project 1 configured the endpoints to have an 8-byte transfer size, which is well below the maximum
transfer sizes discussed earlier in the application note.
Let’s say for example you are developing a device that performs an ADC measurement of some sensor and sends
that data to a host to be graphically displayed in a GUI application. In this application, we do not have any latency
requirements. We only care that the data is error checked. For this, Bulk is an ideal transfer type to use. On a Full
Speed device, Bulk transfers can be up to 64 bytes. To achieve this transfer size, the endpoint descriptors need to be
adjusted as shown in Figure 69 and Figure 70. Note that the Interrupt and Isochronous endpoints were removed for
simplification purposes.
Figure 69. Configure Bulk IN Endpoint for 64-Bytes
www.cypress.com
Document No. 001-56377 Rev. *L
48
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
Figure 70. Configure Bulk OUT Endpoint for 64-Bytes
By using code similar to what was used in main.c of Project 1, the PSoC firmware can send and receive eight times
more data then what was accomplished earlier. However, since Bulk transfer speed depends on available bus
bandwidth, throughput speed will vary. If it is desirable to have guaranteed latency, consider using Interrupt transfers.
Also take a look at AN82072 for an example on how to use the HID class to transfer data for applications such as this
(using Interrupt transfers).
www.cypress.com
Document No. 001-56377 Rev. *L
49
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
15
Project 2: Implementing Vendor Commands
This project demonstrates how to implement vendor commands into a USB design and how to transfer data using a
control transfer. Additionally, this code example uses vendor commands to turn LEDs on and off using a PSoC DVK
board.
15.1
Configuring the Project
1.
Start by creating a new PSoC Creator project and name it Project 2 – USB Control Transfers.
2.
Locate the USBFS component in the Component Catalog in PSoC Creator and drag it to the schematic page
(TopDesign.cysh) along with two digital output pins. (In this example, they are named LED_1 and LED_2). You
can name them anything, but make certain to modify the code that will be provided later.
Figure 71. Project 2 - Schematic
3.
Right click on the USBFS component and click Configure. After the configuration window opens, click on
Descriptor Root. Ensure that the following selections are made (see Figure 72).

Endpoint Memory Management: Manual with Static Allocation.
Figure 72. Project 2 – Memory Management Mode Config
www.cypress.com
Document No. 001-56377 Rev. *L
50
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
4.
Next, configure the device descriptors for this USB design. Click on Device Descriptor and configure the
component (see Figure 73). The settings to be made are as follows:





Vendor ID: 0x04B4
Product ID: 0xE176
Device Class: Vendor Specific
Manufacturing String: Cypress Semiconductor
Product String: Project 2: Implementing Vendor Commands
Figure 73. Project 2 – Device Descriptor
www.cypress.com
Document No. 001-56377 Rev. *L
51
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
5.
Next, click on the Configuration Descriptor and adjust the configuration options as follows (see Figure 74).



Configuration String: Configuration 1
Max Power: 80
Device Power: Bus Powered
Figure 74. Project 2 – Configuration Descriptor
6.
Click on Alternate Setting 0 and configure it to the following parameters (see Figure 75).


Interface String: Unused Interrupt Interface
Class: Vendor Specific
Figure 75. Project 2 – Alternate Setting 0 Configuration
www.cypress.com
Document No. 001-56377 Rev. *L
52
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
7.
After all these changes are complete, click Apply and then OK to close the configuration wizard. Since you do
not use an IN or OUT endpoint, there is no need to worry about configuring the Endpoint Descriptor.
8.
Next, double click on one of the digital output pins to open the configuration wizard. Leave the pins in their
default settings with the exception of un-checking the HW Connection box located in the Type tab on the
configuration wizard (see Figure 76). Apply the same change to the other digital output pin.
Figure 76. Project 2 – Digital Output Pin Configuration
Un-check
9.
Just as was done in Project 1, configure the pins and clock settings for this project. Double click on Project 2 USB Control Transfers.cydwr to open the configuration menu.
10. Beginning with the pin configuration, place the two LED pins at GPIO locations to which you can easily attach
two LEDs. If you do not have LEDs, you can use a DMM or an oscilloscope to observe the results. In this
example, a CY8CKIT-030/050 was used with LED_1 placed on P6[3] and LED_2 on P6[2]. Modify these pin
locations if you are using a CY8CKIT-001 or any other Cypress evaluation kit.
Figure 77. Project 2 – Pin Placement
www.cypress.com
Document No. 001-56377 Rev. *L
53
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
11. Next, click on the Clocks tab at the bottom of the .cydwr menu and configure the clocks in the same manner as
in steps 20 and 21 in Project 1 (see Figure 78).
Figure 78. Clocks Configuration Wizard
ILO clock must
be set to 100kHz
USB clock
must be 48MHz
12. Now that the components are configured, place the required C code in the design. There are two files that
require editing. Start by opening main.c, which can be found in the workspace explorer. Place the C code found
in Appendix E of this application note into main.c.
13. Some of the files that required editing do not yet exist until you build the project for the first time. Select Project >
Build Project 2 – USB Control Transfers from the drop down menu to build the project. After the project is
successfully built, look for the USBFS folder in the PSoC Creator workspace explorer. Inside that folder is a file
named USBFS_vnd.c. This file stores the code to handle vendor commands, as ‘vnd’ is an abbreviation for
vendor. Double click on USBFS_vnd.c to open it.
14. There are two locations in USBFS_vnd.c where code must be placed. At approximately line number 27, you
should see the following text (see Figure 79).
Figure 79. USBFS_vnd.c Custom Declarations
In between the “#START” and “#END” place the code found in the first half of Appendix D, located in Code 1. Note
that that if you changed the overall name of the USBFS component, you must edit the name of the
USBFS_InitNoDataControlTransfer function prototype seen in Appendix D.
www.cypress.com
Document No. 001-56377 Rev. *L
54
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
15. Scroll down further in the USBFS_vnd.c file to approximately line number 76. Note another section to place the
customer code in the file (see Figure 80).
Figure 80. USBFS_vnd.c Custom Code
In between the “#START” and “#END” place the code found in the second half of Appendix D. The code in
Appendix D implements the functionality to do something with the control data that is received by the device.
When a control transfer is performed, variables such as bmRequestType, wIndex, and others, are stored in a
register location. This code will read out the relevant information from those registers and perform the
appropriate function based on the information received.
There are four vendor commands implemented in this application. These values are the bRequest discussed in
the control transfer section earlier in the application note. The four commands, which are implemented, are the
following:




SET_LED = 0xA1
CLEAR_LED = 0xB1
CONTROL_READ = 0xA2
CONTROL_WRITE = 0xB2
When using the SET_LED and CLEAR_SET to turn the LED on and off, wValue will be used to indicate which
LED you wish to control by using either 0x0001 for LED_1 and 0x0002 for LED_2. The variable for wIndex is not
used in this application. SET_LED and CLEAR_LED will demonstrate how to implement a no data phase control
transfer. CONTROL_READ and CONTROL_WRITE will demonstrate how to send and receive data over a
control transfer by performing a control transfer with a data phase.
16. Now we are ready to test this project. Go ahead and rebuild the project. After the project is built without errors or
warnings, program a PSoC 3 or PSoC 5LP device.
www.cypress.com
Document No. 001-56377 Rev. *L
55
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
15.2
Testing the Project
1.
Plug the PSoC development board into the PC through a USB cable. You will need to go through the same
enumeration procedure with installing the driver, which was done in Project 1. Once the device is plugged into
the PC, powered, and fully enumerated, open the Control Center application just as was done in Step 25 of
Project 1. Expand the configuration tree for the device by clicking the “+” on left side of the application. The
application window should look similar to Figure 81.
Figure 81. Project 2 – Control Center View
2.
Click on Control endpoint (0x00) in Control Center, and then click on the Data Transfers tab. This is where you
will issue requests to the device. Start by making the following adjustments to the GUI.







3.
Bytes to Transfer: 0
Direction: OUT
Req Type: Vendor
Target: Device
Request Code: 0xA1
wValue: 0x0001
wIndex: 0x0000
Click on the Transfer Data button and you should see the Control Center application confirm a zero-length data
transfer was completed successfully as shown in Figure 83. Additionally, note that the LED on your DVK board is
illuminated. If you change the value in Req Code to 0x00B1, then press Transfer Data again, and the LED will
turn off again. You can also experiment with turning the other LED on and off by changing the wValue from
0x0001 to 0x0002. If we look at a bus analyzer trace, shown in Figure 82, we can see the presence of a setup
stage and a status stage. Note there is no data stage included with this transfer.
Figure 82. Bus Analyzer Capture for No Data Phase Transfer
www.cypress.com
Document No. 001-56377 Rev. *L
56
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
4.
Next, let us take a look at performing a data control transfer. Start by changing the Req Code (0xB2), wValue
(0x0000), and Direction (Out). In the “Data to Send (Hex)” field, type in eight bytes to send. Then press the
“Transfer Data” button. You should see a message saying that the data was successfully transferred.
5.
Now read the data back from the host. Change the Direction (In) and change the Req Code (0xA2). Press the
“Transfer Data” button again and the message window displays an echo of the data that was previously sent.
Figure 83 shows an example of the expected results.
Figure 83. Project 2 Testing using USB Control Center
If we were to look at data transfer on a bus analyzer, we see a total of six stages: three stages for the write and three
stages for the read. This bus analyzer trace can be seen in Figure 84. Notice that transaction 0 though transaction 2
show the setup, data, and status stage for the write, while transactions 3 through 5 show the setup, data, and status
stage for the read.
Figure 84. Bus Analyzer Capture for Control Data Transfer
www.cypress.com
Document No. 001-56377 Rev. *L
57
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
16
Project 3: Increasing USB Throughput with DMA
This project demonstrates how to implement the DMA in a USB application to achieve greater throughput and how to
implement 1023 byte isochronous transfers for streaming data to the host. This example specifically focuses on the
“DMA w/ Automatic Memory Mgt” configuration in the Endpoint Memory Management configuration of the USBFS
component.
16.1
Configuring the Project
1.
Start by creating a new PSoC Creator project and name it Project 3 – USB DMA Example and place a USBFS
component onto the schematic. Then, open the configuration wizard for USBFS.
Figure 85. Project 3 - Schematic
2.
Right click on the USBFS component and click Configure. Once the configuration window opens, start by
clicking on Descriptor Root. Ensure that the following selections are made as seen in Figure 86:

Endpoint Memory Management: DMA with Automatic Memory Mgmt
Figure 86. Project 3 – Memory Management Mode Config
www.cypress.com
Document No. 001-56377 Rev. *L
58
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
3.
Configure the device descriptors for this USB design. Click on Device Descriptor and configure the component
as you see in Figure 87. Make the following settings:





Vendor ID: 0x04B4
Product ID: 0x1003
Device Class: Vendor Specific
Manufacturing String: Cypress Semiconductor
Product String: Project 3: Increasing USB Throughput with DMA
Figure 87. Project 3 – Device Descriptor
www.cypress.com
Document No. 001-56377 Rev. *L
59
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
4.
Click on the Configuration Descriptor and adjust the configuration options as listed below and in Figure 88.



Configuration String: Configuration 1
Max Power: 80
Device Power: Bus Powered
Figure 88. Project 3 – Configuration Descriptor
5.
Since an isochronous endpoint that is reserving bus bandwidth for 1023 bytes every frame is being implemented,
it is important to configure a zero bandwidth alternate setting similar to what was done in Project 1. Click on the
Interface Descriptor in the USBFS wizard and add an additional alternate setting as shown in Figure 89.
Figure 89. Project 3 – Adding Alternate Settings
Click
Here
www.cypress.com
Document No. 001-56377 Rev. *L
60
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
6.
Remove the endpoint contained in Alternate Setting 0 so that only Alternate Setting 1 contains a single endpoint.
Click on Alternate Setting 0 and configure it according to the following settings and as shown in Figure 90.


Interface String: Zero Bandwidth Interface
Class: Vendor Specific
Figure 90. Project 3 – Configuring Zero Bandwidth Interface
7.
Next, click on Alternate Setting 1 and configure it according to the following settings and as shown in Figure 91.


Interface String: Isochronous Interface
Class: Vendor Specific
Figure 91. Project 3 – Configuring Alternative Setting 1
www.cypress.com
Document No. 001-56377 Rev. *L
61
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
8.
The final step in configuring the USBFS component is to configure the endpoint. This code example consists of a
single isochronous IN endpoint. Click on the Endpoint Descriptor and configure it based on the following
parameters and as shown in Figure 92.







Endpoint Number: EP1
Direction: IN
Transfer Type: ISOC
Synch Type: No Synchronization
Usage Type: Data Endpoint
Interval: 1
Max Packet Size: 1023
Figure 92. Project 3 – Endpoint Descriptor
Keep in mind that achieving 1023 byte isochronous transfers in PSoC 3 and PSOC 5LP is only achievable by using
automatic DMA mode since the endpoint RAM is limited to 512 bytes.
9.
Once these changes have been made, click Apply and OK to save and close the configuration wizard.
10. Open the Project 3 – USB DMA Example.cydwr file. The pins can be left alone since we only have the D+ and
D- pins in this design. They will be auto assigned by the router upon building the project.
www.cypress.com
Document No. 001-56377 Rev. *L
62
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
11. Proceed to configure the clocks the same way that was done in Project 1 and Project 2. However, make one
small change to the PLL (to 66MHz) as shown in Figure 93.
Figure 93. Project 3 – Clocks Wizard
ILO clock must
be set to 100kHz
USB clock
must be 48MHz
12. Apply these changes and proceed to the main.c file. Locate the code for Project 3 in Appendix F and place it
into main.c. The code initially configures the DMA using the USBFS_LoadInEP API. From that point on, the DMA
takes care of loading data from RAM into the EP buffer as space becomes available based on what was
discussed in the PSoC Logical Transfer Modes section. The only other required section of code is to reinitialize
the DMA with a null pointer upon completion of a DMA transaction. The remaining code in the application exists
to reinitialize the USB in the instance of a configuration change (either SET_INTERFACE or
SET_CONFIGURATION) or stop execution if the USB becomes disconnected.
13. Now we are ready to test this project. Go ahead and rebuild the project. Once the project has been built without
errors or warnings, program a PSoC device.
16.2
Testing the Project
14. Plug the PSoC into a USB port on a PC. Using the INF provided with the project files (or in Appendix B), install
the CYUSB driver for this application. For this code example, we will use a different SuiteUSB application.
Instead of using the SuiteUSB Control Center, this project uses the SuiteUSB Data Streamer application. This
application is used to send a constant stream of data to test the throughput. You should find the application
under All Programs > Cypress > Cypress Suite USB 3.4.7 > Streamer.
15. Configure the application with the following parameters via the drop down boxes.



www.cypress.com
Endpoint: ALT-1, 1023 Byte, Isoc in endpoint (0x81)
Packets per Xfer: 64
Xfers to Queue: 1
Document No. 001-56377 Rev. *L
63
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
16. Once all the settings have been made, press the Start button. You will see an incremental value of successful
transfers appearing in the “Success” box shown in Figure 94.
Figure 94. USB Streamer Application
The Streamer application creates a constant data stream to the specific endpoint selected based on the parameters
that were chosen. Notice the 800 KB/s transfer occurring. To provide further perspective, the following is a list of test
results of various transfer speeds obtained using the different USB Memory Management configurations.



Manual (64-byte): ~200 KB/s
DMA w/ MMM (64-byte): ~500KB/s
DMA w/ AMM (1023-byte): ~800KB/s
Additionally, if we look at a bus analyzer capture of the transfers being performed by the Streamer application in
Figure 95, we can see that with each SOF that occurs, we perform a 1023 byte data transfer.
Figure 95. Bus Analyzer Trace of Project 3
www.cypress.com
Document No. 001-56377 Rev. *L
64
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
17
Summary
Based on the material and examples in this application note, you should now have an understanding of the basics
involved with implementing different transfer types in a USB project, implementing vendor commands into a USB
design, and utilizing the DMA for faster data throughput to eliminate the bottle neck of the PSoC’s CPU handling the
information. If you want to experiment with the manual endpoint memory management mode for USB transfers, or
learn additional details about the automatic endpoint memory management, refer to the USBFS component data
sheet in PSoC Creator. Additionally, PSoC Creator includes an example project for creating an Audio Class device
which shows how to incorporate synchronous synchronization with isochronous transfers into a USB application.
Lastly, refer to the Related Resource section for information on how to build upon the concepts learned in this
application note.
18
Related Resources
18.1
Application Notes





18.2
AN57473 - PSoC® 3 / PSoC 5LP USB HID Fundamentals (with Mouse and Joystick)
AN58726 - PSoC® 3 / PSoC 5LP USB HID Intermediate (with Keyboard and Composite Device)
AN73503 - USB HID Bootloader for PSoC® 3 and PSoC 5LP
AN82072 - PSoC® 3 / PSoC 5LP USB General Data Transfer with Standard HID Drivers
Knowledge Base Articles


18.3
AN57294 – USB 101: An Introduction to Universal Serial Bus
KBA93269 - PSoC® USB Mass Storage Class Support
KBA93271 - PSoC® USB Audio Class Support
Additional Information



Cypress PSoC USB Landing Page
Official USB 2.0 Specification
USB Complete by Jan Axelson
About the Author
Name:
Robert Murphy
Title:
Systems Engineer Staff
Background:
Robert Murphy graduated from Purdue University with a Bachelor’s Degree in Electrical
Engineering Technology
www.cypress.com
Document No. 001-56377 Rev. *L
65
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
A
Appendix A: Disable Driver Signature Verification on 64-Bit Windows 8.1 or
10
Step 1: Select “Restart” from the power options menu while holding down the SHIFT key.

Windows 8.1: Press the  + C keys to bring up the Charms Bar, and then click on the Settings Charm.

Windows 10: Press the  key to open the start menu and click on “Power”.
Step 2: Once the PC has rebooted, select the “Troubleshoot” option, then click on “Advanced Options”. Then click on
“Advanced Options”, and finally click on “Startup Settings”
Step 3: Windows will ask you to restart. Click the “Restart” button.
Step 4: Finally, you will be presented a list of startup settings. The one we need is “Disable driver signature
enforcement” To select this option, press the F7 key.
www.cypress.com
Document No. 001-56377 Rev. *L
66
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
B
Appendix B: INF for AN56377
[Version]
Signature="$WINDOWS NT$"
Class=USB
ClassGUID={36FC9E60-C465-11CF-8056-444553540000}
provider=%CYUSB_Provider%
CatalogFile=CYUSB.cat
DriverVer=06/17/2011,3.4.6.000
[SourceDisksNames]
1=%CYUSB_Install%,,,
[SourceDisksFiles]
CYUSB.sys = 1
[DestinationDirs]
CYUSB.Files.Ext = 10,System32\Drivers
[ControlFlags]
ExcludeFromSelect = *
[Manufacturer]
%CYUSB_Provider%=Device,NT,NTx86,NTamd64
;for all platforms
[Device]
%VID_04B4&PID_E175.DeviceDesc%=CyUsb, USB\VID_04B4&PID_E175
%VID_04B4&PID_E176.DeviceDesc%=CyUsb, USB\VID_04B4&PID_E176
%VID_04B4&PID_1003.DeviceDesc%=CyUsb, USB\VID_04B4&PID_1003
;for windows 2000 non intel platforms
[Device.NT]
%VID_04B4&PID_E175.DeviceDesc%=CyUsb, USB\VID_04B4&PID_E175
%VID_04B4&PID_E176.DeviceDesc%=CyUsb, USB\VID_04B4&PID_E176
%VID_04B4&PID_1003.DeviceDesc%=CyUsb, USB\VID_04B4&PID_1003
;for x86 platforms
[Device.NTx86]
%VID_04B4&PID_E175.DeviceDesc%=CyUsb, USB\VID_04B4&PID_E175
%VID_04B4&PID_E176.DeviceDesc%=CyUsb, USB\VID_04B4&PID_E176
%VID_04B4&PID_1003.DeviceDesc%=CyUsb, USB\VID_04B4&PID_1003
;for x64 platforms
[Device.NTamd64]
%VID_04B4&PID_E175.DeviceDesc%=CyUsb, USB\VID_04B4&PID_E175
%VID_04B4&PID_E176.DeviceDesc%=CyUsb, USB\VID_04B4&PID_E176
%VID_04B4&PID_1003.DeviceDesc%=CyUsb, USB\VID_04B4&PID_1003
[CYUSB]
CopyFiles=CYUSB.Files.Ext
AddReg=CyUsb.AddReg
[CYUSB.HW]
AddReg=CYUSB.AddReg.Guid
[CYUSB.Services]
Addservice = CYUSB,2,CYUSB.AddService
[CYUSB.NT]
CopyFiles=CYUSB.Files.Ext
AddReg=CyUsb.AddReg
[CYUSB.NT.HW]
AddReg=CYUSB.AddReg.Guid
[CYUSB.NT.Services]
Addservice = CYUSB,2,CYUSB.AddService
[CYUSB.NTx86]
CopyFiles=CYUSB.Files.Ext
AddReg=CyUsb.AddReg
[CYUSB.NTx86.HW]
AddReg=CYUSB.AddReg.Guid
www.cypress.com
Document No. 001-56377 Rev. *L
67
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
[CYUSB.NTx86.Services]
Addservice = CYUSB,2,CYUSB.AddService
[CYUSB.NTamd64]
CopyFiles=CYUSB.Files.Ext
AddReg=CyUsb.AddReg
[CYUSB.NTamd64.HW]
AddReg=CYUSB.AddReg.Guid
[CYUSB.NTamd64.Services]
Addservice = CYUSB,2,CYUSB.AddService
[CYUSB.AddReg]
; Deprecating - do not use in new apps to identify a CYUSB driver
HKR,,DevLoader,,*ntkern
HKR,,NTMPDriver,,CYUSB.sys
; You may optionally include a check for DriverBase in your application to check for a CYUSB driver
HKR,,DriverBase,,CYUSB.sys
HKR,"Parameters","MaximumTransferSize",0x10001,4096
HKR,"Parameters","DebugLevel",0x10001,2
HKR,,FriendlyName,,%CYUSB_Description%
[CYUSB.AddService]
DisplayName
= %CYUSB_Description%
ServiceType
= 1
; SERVICE_KERNEL_DRIVER
StartType
= 3
; SERVICE_DEMAND_START
ErrorControl
= 1
; SERVICE_ERROR_NORMAL
ServiceBinary = %10%\System32\Drivers\CYUSB.sys
AddReg
= CYUSB.AddReg
LoadOrderGroup = Base
[CYUSB.Files.Ext]
CYUSB.sys
[CYUSB.AddReg.Guid]
HKR,,DriverGUID,,%CYUSB.GUID%
[Strings]
CYUSB_Provider
= "Cypress"
CYUSB_Company
= "Cypress Semiconductor Corporation"
CYUSB_Description = "Cypress Generic USB Driver"
CYUSB_DisplayName = "Cypress USB Generic"
CYUSB_Install
= "Cypress CYUSB Driver Installation Disk"
VID_04B4&PID_E175.DeviceDesc="Cypress AN56377 Project 1 Device Driver (3.4.6.000)"
VID_04B4&PID_E176.DeviceDesc="Cypress AN56377 Project 2 Device Driver (3.4.6.000)"
VID_04B4&PID_1003.DeviceDesc="Cypress AN56377 Project 3 Device Driver (3.4.6.000)"
CYUSB.GUID="{AE18AA60-7F6A-11d4-97DD-00010229B959}"
CYUSB_Unused
= "."
www.cypress.com
Document No. 001-56377 Rev. *L
68
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
C
Appendix C: Project 1 Firmware – Main.c
#include <device.h>
#include <device.h>
/* Create Defines for various Endpoints */
#define EP1 0x01
#define EP2 0x02
#define EP3 0x03
#define EP4 0x04
#define EP5 0x05
#define EP6 0x06
#define ZeroBandwidthInterface 0
#define UnassignedAddress 0
/* Function Prototypes */
void Interrupt_Transfer (void);
void Bulk_Transfer (void);
void Isochronous_Transfer (void);
/* External variable that contains device address assigned by host */
extern volatile uint8 USBFS_deviceAddress;
/* Buffers variables where data sent from host will be stored */
uint8 Interrupt_OUT_Buffer[8], EP2_Count;
uint8 Bulk_OUT_Buffer[8], EP4_Count;
uint8 Isochronous_OUT_Buffer[8], EP6_Count ;
int main(void)
{
/* Local Variable to store active configuration number */
uint8 AltSettingNumber = 0u;
/* Enable global interrupts */
CYGlobalIntEnable;
/* Start USBFS Component based on power settings in DWR (5V in this case) */
USBFS_Start(0, USBFS_DWR_VDDD_OPERATION);
/* Wait until device address is assigned */
while(USBFS_deviceAddress == UnassignedAddress);
for(;;)
{
/* Ensure USB device is fully enumerated prior to running code */
if(USBFS_GetConfiguration() != 0)
{
/* Check USB configuration has changed */
if(USBFS_IsConfigurationChanged() != ZeroBandwidthInterface)
{
/* Get the active interface number and re-enable OUT EP based on Alternative Setting */
AltSettingNumber = USBFS_GetInterfaceSetting(0);
if(AltSettingNumber == 0x01) USBFS_EnableOutEP(2);
if(AltSettingNumber == 0x02) USBFS_EnableOutEP(4);
if(AltSettingNumber == 0x03) USBFS_EnableOutEP(6);
}
/* Check the Alternative Setting variable to see which endpoint buffers to read and load */
switch(AltSettingNumber)
{
/* Check if Interrupt Configuration is Active */
case 0x01:Interrupt_Transfer();
break;
/* Check if Bulk Configuration is Active */
case 0x02:Bulk_Transfer();
break;
/* Check if Isochronous Configuration is Active */
case 0x03:Isochronous_Transfer();
break;
/* Should Never Get Here */
default: break;
}
}
www.cypress.com
Document No. 001-56377 Rev. *L
69
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
return(0);
}
void Interrupt_Transfer (void)
{
/* Check to see if OUT Endpoint has data. If so, read EP2 buffer and load back into EP1 for loopback */
if(USBFS_GetEPState(EP2) == USBFS_OUT_BUFFER_FULL)
{
/* Determine the number of bytes received */
EP2_Count = USBFS_GetEPCount(EP2);
/* Read data from OUT endpoint and store in Interrupt_OUT_Buffer */
USBFS_ReadOutEP(EP2, Interrupt_OUT_Buffer, EP2_Count);
/* Create loopback by reloading data received into IN endpoint */
USBFS_LoadInEP(EP1, Interrupt_OUT_Buffer, 8);
/* Re-arm the Out Endpoint */
USBFS_EnableOutEP(EP2);
}
}
void Bulk_Transfer (void)
{
/* Check to see if OUT Endpoint has data. If so, read EP4 buffer and load back into EP3 for loopback */
if(USBFS_bGetEPState(EP4) == USBFS_OUT_BUFFER_FULL)
{
/* Determine the number of bytes received */
EP4_Count = USBFS_wGetEPCount(EP4);
/* Read data from OUT endpoint and store in Bulk_OUT_Buffer */
USBFS_ReadOutEP(EP4, Bulk_OUT_Buffer, EP4_Count);
/* Create loopback by reloading data received into IN endpoint */
USBFS_LoadInEP(EP3, Bulk_OUT_Buffer, EP4_Count);
/* Re-arm the OUT Endpoint */
USBFS_EnableOutEP(EP4);
}
}
void Isochronous_Transfer (void)
{
/* Check to see if OUT Endpoint has data. If so, read EP6 buffer and load back into EP5 for loopback */
if(USBFS_bGetEPState(EP6) == USBFS_OUT_BUFFER_FULL)
{
/* Determine the number of bytes received */
EP6_Count = USBFS_wGetEPCount(EP6);
/* Read data from OUT endpoint and store in Isochronous_OUT_Buffer */
USBFS_ReadOutEP(EP6, Isochronous_OUT_Buffer, EP6_Count);
/* Create loopback by reloading data received into IN endpoint */
USBFS_LoadInEP(EP5, Isochronous_OUT_Buffer, EP6_Count);
/* Re-arm the OUT Endpoint */
USBFS_EnableOutEP(EP6);
}
}
www.cypress.com
Document No. 001-56377 Rev. *L
70
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
D
Appendix D: Project 2 Firmware – USBFS_vnd.c
Add the following custom declarations to the VENDOR_SPECIFIC_DECLARATIONS section:
/***************************************
* Vendor Specific Declarations
***************************************/
/* `#START VENDOR_SPECIFIC_DECLARATIONS` Place your declaration here */
#include "device.h"
/* Define Vednor Commands */
#define SET_LED 0xA1
#define CLEAR_LED 0xB1
#define CONTROL_READ 0xA2
#define CONTROL_WRITE 0xB2
/* Misc. Variables */
uint16 wValue, wIndex;
uint8 ControlDataArray[8];
uint8 USBFS_InitNoDataControlTransfer(void);
/* `#END` */
Add the following custom vendor command code to the USBFS_HandleVendorRqst() function:
/* `#START VENDOR_SPECIFIC_CODE` Place your vendor specific request here */
/* Grab the wValue and wIndex that was sent with the control transfer */
wValue = CY_GET_REG16(USBFS_wValue);
wIndex = CY_GET_REG16(USBFS_wIndex);
/* Based on the bRequest sent, perform the proper action */
switch (CY_GET_REG8(USBFS_bRequest))
{
case SET_LED:
/* If bRequest is SET_LED (0xA1) and wValue is 0x0001 */
if(wValue & 0x0001)
{
LED_1_Write(1);
}
/* If bRequest is SET_LED (0xA1) and wValue is 0x0002 */
if (wValue & 0x0002)
{
LED_2_Write(1);
}
/* Initialize a no data control transaction */
requestHandled = USBFS_InitNoDataControlTransfer();
break;
case CLEAR_LED:
/* If bRequest is CLEAR_LED (0xB1) and wValue is 0x0001 */
if(wValue & 0x0001)
{
LED_1_Write(0);
}
/* If bRequest is CLEAR_LED (0xB1) and wValue is 0x0002 */
if (wValue & 0x0002)
{
LED_2_Write(0);
}
/* Initialize a no data control transaction */
requestHandled = USBFS_InitNoDataControlTransfer();
break;
/* When a read request occurs over EP0 */
case CONTROL_READ:
/* Set transfer size to 8-byes */
USBFS_currentTD.wCount = 8;
/* Set pointer to data array (defined earlier) for control transfers */
USBFS_currentTD.pData = ControlDataArray;
/* Initialize a control read transaction */
requestHandled = USBFS_InitControlRead();
break;
www.cypress.com
Document No. 001-56377 Rev. *L
71
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
/* When a write request occurs over EP0 */
case CONTROL_WRITE:
/* Set transfer size to 8-byes */
USBFS_currentTD.wCount = 8;
/* Set pointer to data array (defined earlier) for control transfers */
USBFS_currentTD.pData = ControlDataArray;
/* Initialize a control write transaction */
requestHandled = USBFS_InitControlWrite();
break;
}
/* `#END` */
www.cypress.com
Document No. 001-56377 Rev. *L
72
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
E
Appendix E: Project 2 Firmware – Main.c
#include <device.h>
#define UnassignedAddress 0
/* External variable that contains device address assigned by host */
extern volatile uint8 USBFS_deviceAddress;
int main(void)
{
/*Enable Global Interrupts */
CYGlobalIntEnable;
/* Start USBFS Component based on power settings in DWR (5V in this case) */
USBFS_Start(0, USBFS_DWR_VDDD_OPERATION);
/* Waits until device address is assigned */
while(USBFS_deviceAddress == UnassignedAddress);
for(;;)
{
/* Use to do other USB or Non-USB related tasks */
/* Code for Control tranfsers is contained in USBFS_vnd.c */
}
return(0);
}
www.cypress.com
Document No. 001-56377 Rev. *L
73
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
F
Appendix F: Project 3 Firmware – Main.c
#include <device.h>
#define EP1 0x01
#define ZeroBandwidthInterface 0
#define UnassignedAddress 0
extern uint8 USBFS_deviceAddress;
uint8 AltSettingNumber = 0;
uint16 i = 0;
uint8 EP1_RAM[1023];
int main(void)
{
CYGlobalIntEnable;
USBFS_Start(0, USBFS_DWR_VDDD_OPERATION);
while(USBFS_deviceAddress == UnassignedAddress);
for(i=0;i<sizeof(EP1_RAM);i++) EP1_RAM[i] = i;
for(;;)
{
/* Wait for Configuration to Complete */
if(USBFS_GetConfiguration() != 0)
{
/* Reinitialize after SET_CONFIGURATION or SET_INTERFACE Requests */
if(USBFS_IsConfigurationChanged() != 0x00)
{
/* Get the active interface number and reinitalize DMA */
AltSettingNumber = USBFS_GetInterfaceSetting(0);
USBFS_LoadInEP(EP1, &EP1_RAM[0], sizeof(EP1_RAM));
}
/* Check that ISO Interface is active (Not Interface 0) */
if(AltSettingNumber != ZeroBandwidthInterface)
{
/* Check that all data has been transfered and IN Buffer is empty */
if (USBFS_GetEPState(1) == USBFS_IN_BUFFER_EMPTY)
{
/*Rearm the IN Endpoint (EP1) */
USBFS_LoadInEP(EP1, USBFS_NULL, sizeof(EP1_RAM));
}
}
}
}
return(0);
}
/* [] END OF FILE */
www.cypress.com
Document No. 001-56377 Rev. *L
74
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
Document History
Document Title: AN56377 - PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
Document Number: 001-56377
Revision
ECN
Orig. of
Change
Submission
Date
Description of Change
**
2811300
BHA/HRID
11/18/2009
New application note
*A
3010626
HRID
08/19/2010
Updated with PSoC 5
*B
3092283
HRID
11/23/2010
The Code Font size has been changed in page 6, 7, 8,9,10 and 11.
*C
3221695
RLRM
04/11/2011
The application note has been extensively updated. The projects have also been
updated. The project from AN57294 is also merged into this application note.
*D
3250514
RLRM
05/06/2011
Updated Figure 1, 2, 3, 4, and 23
*E
3281366
RLRM
06/13/2011
Broken links fixed and document formatted as per template.
*F
3451232
RLRM
11/30/2011
Updated content throughout the application note based on software updates.
Updated template.
*G
3470131
RLRM
12/20/2011
Updated software version from “PSoC Creator 1.0” to “PSoC Creator 2.0”.
*H
3821266
DASG
11/09/2012
Updated for PSoC 5LP
*I
4294418
RLRM
02/28/2014
Updated for PSoC Creator 3.0.
*J
4484487
RLRM
09/03/2014
Changed application note title
Made clarification improvements
Added Windows 8 support
Updated example projects
Expanded related resources
Added disclaimer on driver signatures.
*K
4625779
RLRM
1/15/2015
Updated example project to fix a DRC error due to a dependency.
*L
5082036
RLRM
01/12/2016
Updated project files to PSoC Creator 3.3 and steps for Windows 10 were added.
Updated template
www.cypress.com
Document No. 001-56377 Rev. *L
75
PSoC® 3 and PSoC 5LP – Introduction to Implementing USB Data Transfers
Worldwide Sales and Design Support
Cypress maintains a worldwide network of offices, solution centers, manufacturer’s representatives, and distributors. To find
the office closest to you, visit us at Cypress Locations.
PSoC® Solutions
Products
Automotive
cypress.com/go/automotive
psoc.cypress.com/solutions
Clocks & Buffers
cypress.com/go/clocks
PSoC 1 | PSoC 3 | PSoC 4 | PSoC 5LP
Interface
cypress.com/go/interface
Cypress Developer Community
Lighting & Power Control
cypress.com/go/powerpsoc
Memory
cypress.com/go/memory
PSoC
cypress.com/go/psoc
Touch Sensing
cypress.com/go/touch
USB Controllers
cypress.com/go/usb
Wireless/RF
cypress.com/go/wireless
Community | Forums | Blogs | Video | Training
Technical Support
cypress.com/go/support
PSoC is a registered trademark and PSoC Creator is a trademark of Cypress Semiconductor Corp. All other trademarks or registered trademarks
referenced herein are the property of their respective owners.
Cypress Semiconductor
198 Champion Court
San Jose, CA 95134-1709
Phone
Fax
Website
: 408-943-2600
: 408-943-4730
: www.cypress.com
© Cypress Semiconductor Corporation, 2009-2016. The information contained herein is subject to change without notice. Cypress Semiconductor
Corporation assumes no responsibility for the use of any circuitry other than circuitry embodied in a Cypress product. Nor does it convey or imply any
license under patent or other rights. Cypress products are not warranted nor intended to be used for medical, life support, life saving, critical control or
safety applications, unless pursuant to an express written agreement with Cypress. Furthermore, Cypress does not authorize its products for use as
critical components in life-support systems where a malfunction or failure may reasonably be expected to result in significant injury to the user. The
inclusion of Cypress products in life-support systems application implies that the manufacturer assumes all risk of such use and in doing so indemnifies
Cypress against all charges.
This Source Code (software and/or firmware) is owned by Cypress Semiconductor Corporation (Cypress) and is protected by and subject to worldwide
patent protection (United States and foreign), United States copyright laws and international treaty provisions. Cypress hereby grants to licensee a
personal, non-exclusive, non-transferable license to copy, use, modify, create derivative works of, and compile the Cypress Source Code and derivative
works for the sole purpose of creating custom software and or firmware in support of licensee product to be used only in conjunction with a Cypress
integrated circuit as specified in the applicable agreement. Any reproduction, modification, translation, compilation, or representation of this Source
Code except as specified above is prohibited without the express written permission of Cypress.
Disclaimer: CYPRESS MAKES NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS MATERIAL, INCLUDING, BUT
NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Cypress reserves the
right to make changes without further notice to the materials described herein. Cypress does not assume any liability arising out of the application or
use of any product or circuit described herein. Cypress does not authorize its products for use as critical components in life-support systems where a
malfunction or failure may reasonably be expected to result in significant injury to the user. The inclusion of Cypress’ product in a life-support systems
application implies that the manufacturer assumes all risk of such use and in doing so indemnifies Cypress against all charges.
Use may be limited by and subject to the applicable Cypress software license agreement.
www.cypress.com
Document No. 001-56377 Rev. *L
76
Similar pages