When I try to access certain features of the 'Standard' CP2105 COM Port, I get an error code from Windows.
For example, when I try to set/reset the RTS pin, I get an error code reported by Windows (error code '31'). The same code to set/reset RTS works on the enhanced COM port. Why do I get this error, and what is the solution?
An error code is being returned by Windows because the default baud rate set for all COM ports by the serial enumeration filter driver is 1200 bps. While this baud rate is supported by the Enhanced port, it is not supported by the Standard port.
Typically, Windows PC application code reads the DCB structure, modifies one or more settings (such as the RTS enable) and writes the DCB back using the SetCommState function. In this process, if the baud rate is left unchanged from the default, that would imply that the code is also trying to set the baud rate to 1200 bps. Because that baud rate is not supported by the Standard port, the CP2105 STALLs (rejects) that request, which is then returned as an error on Windows. The list of baud rates supported by the Standard port is in Table 10 of the CP2105 datasheet. As long as code sets it to one of the supported baud rates, all the other features of the CP2105 Standard COM port will work as expected.
The 'Enhanced' baud rate does not have restrictions on specific baud rates, so the same original code will work on that port without any need to change the baud rate.
When I connect the CP210x device to the PC with the appropriate Virtual COM Port (VCP) driver loaded, the DTR pin toggles after the initial connection. This is not desired in my application because I am using the DTR pin for some other specific purpose and this DTR toggle is not initiated by my PC application. How can prevent this from happening?
The DTR pin toggling is due to a feature called 'serial enumeration' in Windows. Whenever Windows discovers a COM port, it automatically opens the port and toggles the signals as part of a process to check if the COM port is connected to a serial mouse. This is a legacy feature to support older serial mouse devices.
To prevent Windows from toggling the DTR pin, you will need to remove the Silicon Labs Serial Enumeration filter driver that comes packaged with the Silicon Labs Virtual COM Port driver. Follow these steps to remove serial enumeration:
1) Locate the slabvcp.inf file (or your modified INF file from AN220) 2) Comment out the following lines (using the ';' character); Note that the line numbers are specific to the v6.4 VCP driver, so if you are using a different version, the line numbers might be different: - Line 45 ;Addservice = silabenm,,silabenm.AddService - Lines 56-62 ;[silabenm.AddService] ;DisplayName = %silabenm.SvcDesc% ;ServiceType = 1 ; SERVICE_KERNEL_DRIVER ;StartType = 3 ; SERVICE_DEMAND_START ;ErrorControl = 1 ; SERVICE_ERROR_NORMAL ;ServiceBinary = %12%silabenm.sys ;LoadOrderGroup = PNP Filter - Line 80 ;HKR,,'UpperFilters',0x00010000,'silabenm' - Line 85 ;silabenm.sys - Line 95 ;silabenm.sys = 1 - Line 133 ;silabenm.SvcDesc='Silicon Labs CP210x USB to UART Bridge Serial Port Enumerator Driver'
3) Save the inf file with the above changes; right-click the device in Device Manager and select 'Update driver software...'.
4) Use the manual installation option and point to the modified inf file (instead of the automatic search).
You might see unsigned driver warning because the inf file has been modified, thus rendering the driver signature invalid. On 32-bit systems, you should be able to bypass this warning and proceed with installation to test the functionality. On certain 32-bit systems and on 64-bit Windows Vista/7, you have to follow these steps to allow unsigned drivers: /display/2/kb/article.aspx?aid=311418&p=12977
Once you have made these changes and reinstalled the driver, the CP210x device will no longer be checked for a serial mouse and the DTR pin will not toggle.
When moving a design between the CP2110 and CP2102 devices, what should I be aware of regarding the hardware?
The CP2110 and CP2102 are mostly compatible with respect to the hardware. The following lists the differences to keep in mind when moving designs between the two devices.
The CP2102 is available in a QFN28 package. The CP2110 is available in two different packages. The CP2110-GM is a QFN24 package, and the CP2110-GM1 is a QFN28 package. The CP2102 and CP2110-GM1 are mostly pin compatible and share many pins, but some changes are required to the PCB depending on what features are used.
The following pins have the same behavior on the CP2102 and CP2110-GM1: Pin 3 : GND Pin 4 : D+ Pin 5 : D- Pin 6 : Vdd Pin 7 : REGIN Pin 8 : VBUS Pin 9 : /RST Pin 11: /Suspend Pin 12: Suspend Pin 23 : CTS (if the CP2110-GM1 has GPIO2 configured to CTS) Pin 23 : RTS (if the CP2110-GM1 has GPIO1 configured to RTS) Pin 25 : RXD Pin 26 : TXD Pin 13, 14, 15, 20, 21, 22 : No Connect
The following pins are No Connect on the CP2102, but have some function on the CP2110-GM1. When moving from a CP2102 to a CP2110-GM1, these pins can be safely left as No Connect pins if they are not needed, except for Pin 18 (VPP). If in-system device customization is required for the CP2110-GM1, VPP must be connected to a capacitor as stated in the data sheet. When moving from a CP2110-GM1 to a CP2102, a capacitor is not required on Pin 18 for in-system customization.
The following pins have different capabilities on the CP2102 and CP2110-GM1 devices. On the CP2102, these four pins are used for modem flow control. Modem flow control is not available on the CP2110 devices; instead, these pins are used general purpose I/O pins or specific features such as clock out, RS485 control and TX and RX LED toggle.
Pin 1 : RI (CP2102) and GPIO0-CLK (CP2110-GM1) Pin 2 : DCD (CP2102) and GPIO3-RS485 (CP2110-GM1) Pin 27 : DSR (CP2102) and GPIO5-RXT (CP2110-GM1) Pin 28 : DTR (CP2102) and GPIO4-TXT (CP2110-GM1)
Is there an Android interface library available for the CP2110?
Pre-built CP2110 interface libraries are available for Windows and Mac operating systems. A pre-built library for Android is not available.
The CP2110 HID interface is fully documented in Application Note AN434 and is provided for developers who want to write their own driver. The Windows and Mac interface libraries are documented in Application Note AN433 and may provide a helpful reference. Application Notes can be found on the Silicon Labs website: http://www.silabs.com/products/mcu/Pages/ApplicationNotes.aspx.
Can I use the CP2110 to create a Virtual COM Port (VCP)?
The CP2110 is a USB HID-to-UART device. It works with the USB Human Interface Device (HID) Driver built into the operating system and enumerates with a custom HID interface. The CP2110 is not capable of enumerating as a Virtual COM Port.
Can I use the CP2110 to implement a USB keyboard or mouse?
The CP2110 device is not capable of enumerating as a USB mouse or USB keyboard.
The CP2110 is a fixed-function device that operates as a USB-to-UART bridge. PC applications interface to the device using a customer HID interface, which is detailed in Application Note AN434. This custom interface is the only interface available for the CP2110.
Can I use the GPIO pins on the CP21xx USB-to-UART bridge devices to generate an interrupt on the host PC?
The GPIO pins on the CP21xx devices must be polled from the PC host application in order to read their state. They cannot autonomously generate an interrupt on the host PC when a transition occurs on the pin.
Why do I lose control of my pin-shared C2D pin during MCU operation?
The Silicon Labs 2-Wire (C2) debug interface is widely used in Silicon Labs MCU products for Flash programming and in-system debugging. The C2 interface consists of a clock signal C2CK and a bi-directional data signal C2D. The interface transfers information between the device and a host system. Besides serving the C2 interface functionality, the C2CK and C2D pins can be shared and flexibly function as reset pin and general purpose I/O pin, respectively.
An electrostatic Discharge (ESD) event could affect the C2 interface undesirably. An ESD event could cause a glitch in the C2CK pin and put the device in a special mode in which user firmware loses control of the pin-shared C2D pin, which can have far-reaching consequences in a system. For example, if the pin-shared C2 pin is being used as an interrupt pin to other chips, this phenomenon can force the MCU into an unresponsive state.
In this mode, software self resets, watchdog resets, and flash error resets cannot enable user firmware to regain the control of C2D pin. Firmware can only regain control of the C2D pin by resetting the chip using Power-On Reset (POR) or pulling low the RESET pin.
There are a few potential solutions that can be used and combined to address this issue:
1.It is recommended to always put a 2kOhm pull-up resistor on the C2CK pin to minimize the possibility of glitches on the C2CK pin due to ESD or similar events. This, in turn, reduces the chances of getting into the special mode where the C2D pin is uncontrollable.
2.If extra pin is available, try to use the extra pin instead of the sharing function of the C2D pin.
3.If a pin-limited connector design is required, the connector may not be able to carry extra pin. In that case, sharing of the C2D pin could be used. To work-around the loss of control of C2D due to ESD event, connect another free pin to the C2D pin through a resistor of 100-500 ohm and use this pin for your application purpose as shown in the following figure.
4.If no free pin is available, C2D pin should be self-monitored. Self-monitor can be done by reading back the value of the pin after writing to it. When the pin is unresponsive, the MCU should communicate with the remote HOST to reset the MCU through POR or RESET pin. This is only applicable for designs where the remote HOST can control the MCU.
Is it possible for an I2C master to inadvertently write to unintended I2C oscillator registers?
Yes, it is possible for an otherwise properly operating I2C master to accidentally write to unintended I2C oscillator registers. The mechanism is a 'fractured' I2C message where the master is reset before an I2C message is completed.
Some indications that this might be happening are that sometimes, but not always, it appears that the I2C oscillator is somehow being reconfigured after a board level reset or during a board start-up sequence. As always, whenever weird or mysterious I2C bus behavior is suspected, one should probe the SCL and SDA signals.
Listed below is an example from one of our customers where an Si570 was being inadvertently disabled. By monitoring the I2C bus, and the board level reset to the I2C master, before and after the event, the customer was able to determine what was going on.
1. A board level reset occurs after the I2C master sends the device address, and before receiving an acknowledge from the slave. 2. During reset, the I2C clock (SCL) is tristated and floats high. SDA is then pulled low by the slave waiting for a clock cycle to release SDA. 3. After reset, SCL is driven and SDA released by the slave. SDA is in tristate and floats high. 4. However, the slave is still in the middle of a transaction and enters the register address phase. It reads in the 8 bit address (0xFF or 255 dec) and acknowledges. 5. The slave then writes in the data (0xFF) to the address. (In this case, register 0xFF or 255 dec is a 'don't care' register address for the Si570.) 6. The slave doesn't see a stop command so it executes a multi byte write. It increments the address, which rolls over to 0x00. It then writes in the data (0xFF) into register 0x00. (In this case, register 0x00 is a restricted register address for the Si570.) The result for the customer's particular part number was a mis-configured device with no clock output.
Does the 'RS-485 Invert' option in the AN223SW enable an active-low or active-high output signal on my CP2104 or CP2105?
In the AN223SW package, the CP210x Port Configuration utility allows for a user to enable the RS-485 mode on their CP2104 or CP2105 device. To enable the RS-485 mode, the GPIO pin that is shared by the RS-485 function should be set to Automatic by Device in the Latch Control drop-down box. Table 1 of AN223 has more information on the enhanced functionality available on GPIO pins. In addition, the polarity of the output signal can be configured for active-high or active low. By default, the RS-485 is active-low (or low while the CP210x devices is transmitting). If the RS-485 Invert box is checked, the RS-485 signal will be active-high (or high while the CP210x device is transmitting). After selecting all the appropriate options, click Set Configuration.
Note: To use this utility, a 4.7 uF capacitor must be connected to the VPP pin. Also, these fields can only be modified once.
The Bus Free Timeout is an error recovery mechanism that will allow the SMBus or I2C state machine to consider the bus “free” whenever the SDA and SCL lines are both high for more than 10 SMBus clock source periods or the configured I2C bus free timeout period.
If Bus Free Timeouts are disabled, the SMBus or I2C state machine will consider the bus “busy” as soon as a START is seen on the bus and will consider the bus “free” as soon as a STOP is seen on the bus.
If the Bus Free Timeouts are enabled, the SMBus or I2C state machine will consider the bus “free” without a STOP being issued on the bus. A master device begins a transmission with a START+ADDR+R/W and DATA, but does not transmit a STOP. In this scenario, the bus would not be considered busy indefinitely, but will instead be considered free after 10 SMBus clock source periods or when the I2C bus free timeout period expires. The following example shows the bus becoming free after 10 SMBus clock source periods.
How is an SMBus or I2C transfer scheduled if the bus is not free?
When STA is set, an SMBus or I2C transfer will be scheduled. If the bus is currently free, the bus will be claimed by issuing a START+ADDR+R/W. If the bus is not free when STA is set, the transfer will be scheduled to occur as soon as the bus is considered free. The bus will be considered free when:
A stop condition is seen on the bus
If Bus Free Timeouts are enabled and both SCL and SDA are high for more than 10 SMBus clock source periods or the timeout set by the I2C bus free timer.
It is important to note that the STA bit may be cleared inside the SMBus or I2C ISR before the transfer starts. In this case, the firmware must ensure that the STA bit is set again to keep the transfer pending. In the picture below, Master 2 begins to transfer the START+ADDR+R/W after Master 1 issues a stop on the bus.
I want to use a USB MCU for my application and I want to run it with Linux. What is the recommended implementation I should use?
There currently are no dedicated drivers (such as VCP or USBXpress) that operate with Linux when using the programmable USB MCUs. However, Linux implements most standard USB classes which includes the Human Interface Device (HID) class. It would be recommended to use the HID class firmware targeted to one of the USB MCUs to communicate with the Linux OS. There are code examples provided with the IDE and Precision32 installations that provides a template for implementing HID devices. The IDE and Precision32 software package can be found at the links provided below:
The CP2120 can provide data MSB first or LSB first. What is the default setting?
The CP2120 is capable of transmitting the data in bit reversed order. The
SPI Configuration command configures the bit orientation of transfers across the SPI bus to one of two states. If SPI transmits most-significant-bit first, bit 7 is transmitted first. If SPI transmits least-significant-bit first, bit 0 is transmitted first. The default setting for the byte order is to transmit the MSB first.
What latencies exist when using the USB VCP drivers?
UART communication provides a defined timebase between the two devices transmitting and receiving data. The time interval between the two devices can have defined latency as well depending on the application. USB communications is always initiated by a host. A device must wait for a request from the host before sending or receiving data. In addition, there are different transfer types with different timing constraints. When usng the Silicon Labs VCP drivers, the transfer type used is the Bulk transfer which has a guranteed delivery, but the host schedules transfers when the bandwidth is available. This can make the data transfers appear bursty.
Both the host and the device side timings should be evaluated when determining latencies. On the host side data should be transmitted in the largest packet size available (in this case it is 64 bytes). Each packet contains overhead and issuing packets that are smaller then the maximum packet size reduces the overall bus bandwidth. By allocating a large buffer (the host side driver has a 4K buffer) in the host application then the lower level driver can parse the packet and split the packets into the appropriate size to maximize the bus bandwidth.
There are two methods the CP210x devices use to determine when to write data from the UART to the USB buffers. The CP210x devices provide internal buffers that will queue up data and generate a USB packet when a 64 byte threshold is reached. This decreases the overhead and maximizes the bandwidth. In addition, the CP210x devices will also create a packet when UART data is idle. The CP210x doesn't finish sending received UART data until a certain amount of time has passed without receiving a UART character. This is referred to as the USB receive timeout and is individually configurable for each application requested baud rate range. The default timeout length is 1 ms or (18/BaudRate), whichever is shorter. This minimizes the latency when data is not being received and the buffers are not full. AN205 covers the baud rate settings and the timeout adjustments that can be made.
I can not successfully program my CP2104, CP2105, CP2110, or CP2112 device's customizable parameters.
In order to use the CP21xxSetIDs utility to program a CP2104, CP2105, CP2110, or CP2112 device's customizable parameters, the following items are required:
-4.7 uF capacitor on the VPP pin -Supply voltage must be greater than or equal to 3.3 V. -VPP pin should not be connected to any additional external circuitry.
If you are attempting to program the customizable parameters on a CP2105-EK board, you must first remove the J6 pin 9-10 jumper. This jumper connects the VPP pin on the CP2105 to additional external circuitry that will prevent the device from being programmed. The CP2104-EK, CP2110-EK, and CP2112-EK boards can be successfully programmed over USB without removing any jumpers on the board.
It is important to note that the some of the customizable parameters can only be programmed once. The device-specific datasheet will have more information on which parameters can only be programmed once.
I'm writing a PC program to interface with the CP210x VCP driver and I'm not sure whether to use Overlapped or Non-Overlapped I/O. Do you have a recommendation?
The Overlapped versus Non-Overlapped decision depends largely upon the application's design and the desired behavior. The following MSDN page includes a discussion of using Overlapped versus Non-Overlapped I/O: