AN571

CP210X VIRTUAL COM PORT INTERFACE

1. Introduction

This document describes the CP210x Virtual COM Port interface between the host and CP210x device for the

purposes of creating custom drivers that interface with the CP210x. For more information on how to customize the

CP210x hardware, see “AN144: CP210x/CP211x Device Customization Guide” on the Silicon Labs Application

Notes webpage:

https://www.silabs.com/products/mcu/Pages/ApplicationNotes.aspx

1.1. Related Documents

Universal Serial Bus Specification: version 2.0 (also referred to as the USB Specification). This specification is

available at http://www.usb.org.

Universal Serial Bus Class Definitions for Communication Devices: version 1.1 (also referred to as the CDC

Specification, where “CDC” stands for “Communication Device Class”. This specification is available at http://

www.usb.org.

ANSI/TIA-602: Serial Asynchronous Automatic Dialing and Control - available at http://www.eia.org.

1.2. Terms

end device: refers to the hardware connected to the CP210x UART pins.

host: refers to the PC dr iver and host controller.

2. Interface Architecture

The CP210x device implements one or more communications interfaces implemented using the Bulk protocol.

These USB Bulk pipes transport data only and any status information must be obtained from the control pipe.

To configure and control the port, the host sends requests to the device via the control pipe. The host uses these

requests to perform such functions as setting the baud rate, setting handshaking modes, and configuring special

characters.

To send data from the host to the port, the host queues BULK-OUT packets to the endpoint of the interface

associated with the port. The data from these packets will be loaded into the interface’s data buffers and p assed on

to the external device.

To move data from the port to the host, the host issues IN requests to the port’s data IN endpoint.

AN571

2 Rev. 0.1

3. Flow Control

The Virtual COM Port protocol is designed to allow ports to perform the same handshaking that is performed by

PCs when running Windows with a real serial port. To do this, the device is required to follow det ailed rules fo r flow

control.

The Virtual COM Port protocol provides full-duplex data streams. The transmit stream is used for data from the

host to the serial port; the receive stream is used for data from the serial port to the host. Each stream has

provisions for flow control.

 Transmit flow control allows the end device to ask the port to stop transmitting data. The CP210x will continue

to accept OUT data from the host until its internal buf fers are full, and then will NACK further OUT packets to the

transmit endpoint. When the end device has accepted enough data from the CP210x buffers, the CP210x will

accept more OU T packets from the ho st.

 Receive flow control allows the port to ask the end device to stop transmitting data to the host. The CP210x

device holds the data received from the end device in buffers until the host asks for it. If the host does not ask

for data in a timely fashion (usually because the application is busy), the CP210x ’s buffers may start to fill up,

and the CP210x uses receive flow control to ask the end device to stop sending data. When the host catches

up and empties the CP210x’s buffers, the CP210x then uses receive flow control to ask the end device to

resume sending data.

All flow-control handling is perform ed in the CP210x device. This is done for two reasons:

 To reduce overhead at the host.

 To eliminate latency for responding to flow-control events.

The host’s only involvement with flow control is to set the device into the desired flow control mode.

3.1. XON/XOFF Flow Control

Two characters are defined by the “set special characters” mechanism (SET_CHARS): XON (normally 0x11,

CTRL/Q), and XOFF (normally 0x13, CTRL/S). The same values are used for XON and XOFF for both transmit

and receive flow control. XON and XOFF may be set to the same character, but usually are different.

The CP210x device follows “OS/2 rules:” if transmit flow control says “don’t transmit”, the port prevents any

characters from being transmitted, including the flow control characters. The device normally stops transmitting

whenever it sends XOFF for receive flow control. The port resumes transmitting only when it sends XON to allow

the remote device to send data. This prevents a potential buffer overflow because the flow control characters

cannot be transmitted while XOFF is in effect.

3.2. Flow Control Rules

 The CP210x uses a bit pattern similar to the ulHoldReasons mask from the Seri al S tatus response (see Table 8)

to control transmission. If any of the hold reasons are set, the CP210x will not send (except that certain

characters, such as XON for receive flow control, can always be sent).

 If the CP210x sends an XOFF special character in order to stop reception, the device will transmitting until the

device decides to send XON. While transmission is halted, the CP210x will set bit 4 in ulHoldReasons (see

Table 8).

 If the CP210x receives an XOFF special cha racter and is configured to XON/XOFF flow control mode, then the

CP210x will stop transmitting characters. While stopped, the CP210x sets bit 3 in ulHoldReasons. When an

XON is received, the CP210x clears bit 3 in ulHoldReasons an d resumes transmissi on if ulH oldRe asons [5..0]

is now zero.

 If the CP210x is instructed to send a BREAK, it will stop sending normal characters while BREAK is asserted

and set bit 5 of ulHoldReasons.

 If the CP210x is waiting for any of the modem control signals CTS, DSR or DCD, the CP210x sets the

appropriate bits in ulHoldReasons when the corresponding signal is causing a delay; the device will clear those

bits when the hold condition is removed, either because the flow-control programming was changed, or

because the signal changed state externally.

 Immediate characters are not blocked by software flow control (either due to XOFF sent or due to XOFF

received). However , they are held off by BREAK, CTS handshaking, DSR handshaking or DCD handshaking (if

enabled and holding off traffic).

 After sending an XOFF, the CP210x sends XON to start receiving data only if output is not being held, or

otherwise if either a sent XOFF or a received XOFF is the only reason that output is being held.