We've recently become aware of an issue with a new update to Windows 10 and our CP210x VCP "Universal" Driver for Windows 10, driver version v10.1.1. When attempting to install the driver, an error is given by Windows that states "A service installation section in this INF is invalid." This occurs because Windows has changed drive INF requirements slightly, and our current driver's INF file does not meet these requirements.
We currently are working to fix this issue, although due to testing and recertification requirements, we do not expect the fixed driver to be available until mid-June.
A work-around exists currently, but it involves manually editing the .INF file for the driver. This causes another issue - the driver is no longer signed in this case, so the driver must be forced to install, and Windows will show a warning that the driver is unsigned.
Firstly, the work-around is as follows:
Download the Windows 10 Universal driver from here: https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers
Edit the .inf file with this driver, performing the following modifications:
On or around line 118, change/edit
ServiceBinary = %13%\silabser.sys
ServiceBinary = %12%\silabser.sys
And on or around line 160, change/edit
Silabser_CopyFiles_FileListSection = 13 ; Driver package's Driver Store directory (%WINDIR%\System32\DriverStore\FileRepository ) (was 12 Drivers directory (%SystemRoot%\system32\drivers))
Silabser_CopyFiles_FileListSection = 12 ; Driver package's Driver Store directory (%WINDIR%\System32\DriverStore\FileRepository ) (was 12 Drivers directory (%SystemRoot%\system32\drivers))
I.e. replace every 13 in the file with 12.
Once these changes are made, attempt to re-install the driver. A warning will be shown that the driver is unsigned, but you can ignore this for now. If you do not receive a warning issue, or if Windows refuses to install the unsigned driver (you may get an error about the hash being invalid), you can disable driver signing enforcement by following these instructions: https://www.maketecheasier.com/install-unsigned-drivers-windows10/
Alternatively, rolling back to a previous build of Windows also resolves the issue.
Hi Everyone ,
I have an embedded system with the CP-2108 assembled and connected via usb to a Windows 7 embedded PC permanently ( on PCB )
I want to configure the four port to be for example com10,11,12,13.
I am doing so with the control panel and it works ok , but once I use a tool like ghost or Acronis to deploy the software on a new hardware , the windows re-enumerated the com-ports to other com-port numbers.
Is there anyway to force the driver not to allow this enumeration and make it static ? or maybe build a script that changes the port com-numbers automaticly that I can run upon image deployment ?
Appreciate your help,
We have designed an electronic board using CP2102 and an associated software to control our product. Until now, everything was working fine. For a few weeks, we have several reports from customers that complaints about 2 things:
1/ When plugging the board to their computer, board is not automatically detected by using Windows 10, so they have to install manually Silicon Labs driver
2/ When installing last version of Silicon Labs driver, device appear in Windows Device Manager, but our software can't detect it in the list of available COM port. We found a workaround by downgrading to driver v6.0.0.
Does some of you have similar issues? Are there files that I can share to help troubleshooting the issue?
Thanks for your help
I have a CP-2102 downstream from a USB2512 Hub. I usually see D+ transition to +3.3V for about 40ms on power-up and then J/K data begins to flow.
I have a couple of board that after CP-2102 power-up D+ goes to +2.0V for 10ms, 0V for 20ms, and then +3.3V for 60ms. I expect the conditions that would cause this two hump camel are well known to the CP-2012 experts.
The Hub does not raise it "pwr port" pin connected via a mosfet to the CP-2102 VBUS. So there is no activity after the two D+ humps.
We are using a CP2615 bridge to acquire audio signal on Windowds and Android systems. We would like to extend or to develop a new product for IOS.
But I read that CP2614 is not recommended for new developments .... Have you a solution for an USB audio bridge working on IOS ?
This post serves as a reference : https://github.com/Microsoft/WSL/issues/3706
WSL (Windows Subsystem for Linux) expects the redirection for the COM Port to have the Physical Device Name in Computer\HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM. The driver currently creates \Device\Silaberser0 as the key for the COM port. This prevents WSL from detecting the COM port.
The post above describes how to get around it - you have to create a new registry string value with the "Physical Device Name" as the Name and the COM port number "COM4" as the value. This is fine as a workaround. However, every time the device is plugged in, a new Physical Device Name is created.
I had an older version of the driver that did not exhibit this. Can this issue be fixed?
I have installed the latest drivers from the web page https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers
after the installation when I tried to connect to the serial device by selecting SLAB_USBtoUART at 9600 baud rate my program stops working and nothing works
I tried different programs CoolTerm, Arduino, ESplorer each and every program stops working after I try to connect to the device(NodeMCU - esp8266). Can anyone please tell me where I did wrong
Here is my system specification:
macOS Sierra v10.12.6
MacBook Pro (13-inch, 2017, Four Thunderbolt 3 Ports)
3.5 GHz Intel Core i7
I am using ESP32 development boards with CP2102. I have Surface3 running Win 10 Home, 1809.
When connected to the dev board, the USB Serial does not connect and configure. Device manager reports -
"This device is not configured correctly. (Code 1)
To find a driver for this device, click Update Driver."
Driver identifies "Device USB\VID_10C4&PID_EA60\6&646ea32&0&1 requires further installation." but I have not been able to find a way to get the driver to load correctly. I have been able to connect to the same board using a different PC so I believe the ESP32 board tob e functional.
Thanks - Barry
I have completed installation of the CP210x USB to UART Bridge VCP Drivers here: https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers
The installation went smoothly, with the resulting new entry shown here:
However, no COM ports show in Device Manager no matter which view I choose:
Needless to say, no SiLabs USB/UART devices are recognized by Windows. Please advise.
This article discusses the main considerations of a touch sensor designer when choosing the sensor’s cover glass.
First, we focus on common mechanical and optical design problems. Then we go into some more specific problems, in more intricate touch sensor designs.
Cover glasses’ mechanical properties:
A thicker cover glass results in a sturdier touch sensor. Thicker cover glasses are usually preferred for applications in harsh (e.g. industrial) environments. In devices like smartphones and smartwatches the designs need to be as thin as possible. So designers focus on trimming thickness, and the cover glass is no exception. A general rule of thumb to keep in mind is that the thinner the cover glass, the less it affects the performance of the touch sensor.
The material of the cover glass and its thickness affect the sensor’s weight. Again, smartphones and smartwatches are expected by the consumers to be lightweight so designers resort to lightweight materials. In touch sensors that are mounted on other devices (e.g. on white goods) weight is not a driving force on design choices. In these cases, designers go for the most cost-effective material and thickness solution.
3. Scratch resistance
The need to mitigate the scratches is crucial in most of the industries. A cover glass that easily scratches can compromise both the functionality of the sensor and its cosmetic appearance. So, in smartphones and smartwatches, scratch resistance is a design priority. Customers simply expect their device to be able to withstand a moderate amount of scratches.
In harsh and industrial environments, the touch sensor is almost expected to be subject to scratches. The designer has to take this into account and select a cover glass durable enough to withstand them.
Finally, in healthcare, touch sensor should remain as smooth as possible so that it can be easily sterilized. Having scratches on their surface means a rougher surface that is harder to clean.
4. Drop resistance
Similar to scratch resistance, a basic level of drop resistance is something that customers expect from their products. In fact, drop resistance is so important that the latest version of Corning Gorilla glass is designed to withstand 15 drops from 1m without shattering. Again, smartphones and industrial devices are more likely to need such protections, while mounted devices are not likely to need it.
These are, in a nutshell, the mechanical properties a touch sensor designer should account for before making a cover glass design choice. Next up, we’re going to examine the most important optical features to consider.
Cover glasses' optical properties:
The general consensus regarding touch sensor designs that are on top of screens is that the whole sensor should have a transparency of more than 90%. As far as the cover glass is considered, the transparency lost on it is negligible. Most of the light is blocked by the electrodes. The material electrodes are made of, be it ITO or one of its alternatives, is not perfectly transparent. However, this doesn’t mean there aren’t other optical performance parameters to be considered.
Anti-glare is the ability of a glass to diffuse the mirror-like reflections off its surface, enabling the viewer to better see what’s behind the glass. So, anti-glare is used to increase the visibility of what’s behind the touch sensor. If there isn’t a screen behind the cover glass sensor, this property can be omitted. However, if there is one and the device is going to be used outdoors (e.g. in a POS device) then having such a property can vastly improve the usability of the device.
Again, in any device that features a screen behind the touch sensor, anti-haze coating is a must. Hazy or cloudy glass can reduce the clarity of what’s shown on the screen. This reduces the usability and its cosmetic appearance of the product.
Cover glasses’ geometrical properties:
8. Finger’s angle and distance relative to the electrodes
Designing a touch sensor that features a curved cover glass instead of a flat one can create problems on its own. Consider a flat sensor with a slightly bent cover glass, or a cover glass with curved edges. The glass will have a different effect on the performance of the design. This happens because the distance between the finger of the user and the electrodes will differ in the non flat areas. The difference will alter the coupling between the two and affect the sensor’s design.
But the problem magnifies if the cover glass forms a bigger curve angle. In this case, it is not only the distance between the finger and the electrodes, but also the orientation of the finger when it’s near the sensor that changes. Since the curve is bigger, the tip of the finger will probably have a different orientation that it does on the flat areas. This will introduce a different geometry to the sensor and again, alter the coupling between the two.
We also have to mention the case in which a stylus will be used to operate the touch sensor.
A stylus has a significantly smaller area than the fingers. So the general train of thought here is that in order to operate a sensor via a passive stylus you’ll need a more sensitive sensor than one you’d operate with a finger. In terms of cover glass selection, if you know that a stylus will be used, you might want to opt for a thinner cover glass or one with a higher relative permittivity.
9. Signal-to-Noise Ratio
Signal-to-noise ratio, or SNR, is a constant headache for touch sensor designers. Thankfully, proper cover glass selection can you help increase the SNR. Without going into too much detail, keep in mind that thicker cover glasses result in a worse SNR.Thinner cover glasses or ones made of a material with a higher permittivity lead to a better SNR.
How to achieve the desired properties of your touch sensor.
You can implement the desired properties in your touch sensor designs in two ways.
1) using a single cover glass layer with all of the properties or
2) using multiple (usually two) cover glass layers, each with different characteristics.
You can read more for these methods here.
One of our customers reported a strange error with CP2101 driver on Windows 10 :
When trying to install the drivers, an error message indicates that the device cannot run on USB 3.0 port.
Here is a screen caps (sorry, it's in french). Translation would be something like this :
"Silicon Labs CP210x USB to UART Bridge is an anterior USB peripheral which cannot run with USB 3.0. Connect the peripheral to an available USB 2.0 port, then click on Next. Else, click on Cancel."
I cannot check this issue as I do not have a computer running Windows 10, with USB 3.0 ports.
Any idea or workaround concerning this issue ?
Thanks for your help !
I've noticed a recent change in which driver you get automatically via the windows update function ... until about 2 weeks ago, it was still the 188.8.131.52, which is why I sticked to SiUSBX.dll V 184.108.40.206. until now.
Now I get a driver that identifies as V220.127.116.11 and dates from Nov 6th, 2015 .... which Version of SiUSBXp.dll am I supposed to use with this driver?
I believe it's a WinUsb-based driver, since I was able to get some results with the 3.9.0.X-dlls.
But i.e. SI_GetDriverVersion() fails, independent from which version of the SiUSBXp.dll I use.
I'm also suspicious of the version number, since it is so far away from 4.X ... can someone please explain what's up with this driver?
I've been having issues with getting the i2c interface to work reliably with the EFM32GG STK3700.
Notably, for the i2c lines I've been able to get working, the SCL line is looking like a sawtooth wave, instead of a nice square wave.
To see if this is just an artifact of that particular bus, I was trying out the different i2c ports. It seems that the different i2c ports/pins have different behavior. I'm wondering if I'm configuring them incorrectly.
Below is the code for the InitDevice.c file I'm using to configure the bus.
My understanding is that, wherever used:
/* Module I2C0 is configured to location 1 */ I2C0->ROUTE = (I2C0->ROUTE & ~_I2C_ROUTE_LOCATION_MASK) | I2C_ROUTE_LOCATION_LOC1; /* Enable signals SCL, SDA */ I2C0->ROUTE |= I2C_ROUTE_SCLPEN | I2C_ROUTE_SDAPEN; /* Module PCNT0 is configured to location 1 */ PCNT0->ROUTE = (PCNT0->ROUTE & ~_PCNT_ROUTE_LOCATION_MASK) | PCNT_ROUTE_LOCATION_LOC1; /* Module USART1 is configured to location 1 */ USART1->ROUTE = (USART1->ROUTE & ~_USART_ROUTE_LOCATION_MASK) | USART_ROUTE_LOCATION_LOC1; /* Enable signals RX, TX */ USART1->ROUTE |= USART_ROUTE_RXPEN | USART_ROUTE_TXPEN; // [Route Configuration]$ // Relocated from above... /* Pin PD6 is configured to Open-drain with pull-up and filter */ GPIO->P.MODEL = (GPIO->P.MODEL & ~_GPIO_P_MODEL_MODE6_MASK) | GPIO_P_MODEL_MODE6_WIREDANDPULLUPFILTER; /* Pin PD7 is configured to Open-drain with pull-up and filter */ GPIO->P.MODEL = (GPIO->P.MODEL & ~_GPIO_P_MODEL_MODE7_MASK) | GPIO_P_MODEL_MODE7_WIREDANDPULLUPFILTER; // [Port D Configuration]$
The only pins that I'm able to configure with mostly expected behavior is PB11 and PB12. For this, I'm seeing a nice square wave for PB11, but the sawtooth wave for PB12.
All other pins, for the same scope frequency, only seem to give a single step. Images are attached for comparison.
Any thoughts on what I might be doing wrong?
I'm using a CP2102 on a Windows 7 machine but I'm getting some problems with it.
I've build a little program that call SI_GetNumDevices, SI_GetProductString several times and then SI_Open.
Q1 - I don't understand why SI_Open doesn't find device whereas SI_GetNumDevices found it : does anyone have any ideas ?
Before that I understand that I had to change the PID of my CP2102 to 0xEA61 instead of 0xEA60 (to use USBXpress driver), using AN721 tool (CP21xxCustomizationUtility.exe). But now the tool doesn't find the CP20102 anymore...
Q2 - How can I change back the PID to 0xEA60 knowing that I can't do it with AN721 tool ?
I read in another topic that I have to use V4.0 of USBXpress driver, but even if I download the lastest SDK software, the driver version used seems to be V3.2:
Q3 - How to really install the V4.0 of the driver ?
I've attached the source code of my little test program so that you can see exactly what I'm trying to do, and maybe tell me what's wrong.
Thanks in advance for your help.