PSA: Do not use the CP2102N USB to serial converter in your designs (for linux)

[jeremy]

Hi all,

It feels like just yesterday I got burned by a crazy silicon bug: https://www.eevblog.com/forum/projects/psa-do-not-use-the-tps61099-boost-reg-in-your-designs/

But it seems I'm having a particularly bad run of luck lately, because I've tripped on another silly bug in the exact same design, this time with the CP2102N. Turns out if you send UART data (of all things!) to the USB to UART IC, it can crash, requiring a power cycle to come back online    Also, the older version of the chip that works (CP2102) is NRND.

Ok, so that's an exaggeration, but not by much. The truth is that it crashes if your device sends UART data while the port is being opened, but everything else stands. Of course, since you can't really predict when a device is going to send UART data with respect to the port opening time, this means that you will have devices randomly needing a power cycle to communicate. To make matters worse, they know about this problem and appear to have put a workaround in the windows driver recently, but they have no plans or intention to fix it in linux. Only fix will be with a new chip revision which has an undetermined time frame. There is also no info about the workaround, so there is no way to fix it by just writing the patch myself 

You can see the thread on their forums here: https://www.silabs.com/community/interface/forum.topic.html/cp2102n_stops_receiv-GeH2

Just to make sure that the google bot definitely catches this and hopefully saves someone else the hassle and stress, using the CP2102N in a device which might connect to linux is a really bad idea right now.

Can we create a subforum where people just post the part numbers of chips which have critical errors like this? (I'm joking of course, but I'm starting to think it would just be a list of basically every commercial IC that has ever been made...)

[tsman]

Ugh. How did that firmware bug get past QA?

To make matters worse, they know about this problem and appear to have put a workaround in the windows driver recently, but they have no plans or intention to fix it in linux.

It looks like they've got poor support for Linux anyway. The Linux kernel module was reverse engineered from the Windows driver by a third party. SiLabs do supply a modified copy of that driver which adds GPIO pin twiddling but they recommend that you use the kernel supplied version.

[FrankE]

Which is best then Prolific, FTDI?

I read that some can read counterfeit chipsets in adaptors and will not work but I can't remember which.

[oPossum]

Prolific's current drivers don't support older chips. The older chips where cloned, so they stopped supporting them. Doesn't matter if they are genuine or fake.

Some versions of FTDI drivers won't work with the fake chips.

10 years ago those where the brands I used the most. I no longer use either.

My current favorites are the CH340C and CH340E.

[DDunfield]

Prolific's current drivers don't support older chips. The older chips where cloned, so they stopped supporting them. Doesn't matter if they are genuine or fake.

Some versions of FTDI drivers won't work with the fake chips.

10 years ago those where the brands I used the most. I no longer use either.

My current favorites are the CH340C and CH340E.

FTDI drivers don't just "not work", they take aggressive actions which can cause you major headaches in a product.

Some versions of the FTDI drivers "brick" devices they decide are fake, by changing the USB ID reported by the device.
Other versions silently but intentionally corrupt the data stream. And yes, it's intentional because the corrupted data stream contains “NON GENUINE DEVICE” or something like that.

They also do not provide a program or other means to validate a particular device as being genuine.

This means that your in-production product which has been ticking along just fine suddenly can have a serious failure because of a change in the parts supply chain (Which depending on who you have manufacturing your product you may or may not have been made aware of). This failure will affect 100% of the production run, with no acceptable workaround except recalling the product and changing out the serial chips.

For this reason, nobody I work with is using FTDI devices any more.

CP2102's have been for the most part OK, but there seems to be issues with their drivers, which I think relate to excessive delays in USB driver chaining ... For example, I'm currently working on a product which uses an STM32 series device as it's main processor and has a CP2102 for the maintenance port ... guess what, the ST-LINK (primary STM32 debug interface) is unreliable or doesn't work at all on many systems while the CP2102 is connected - works perfectly when the CP2102 is not around.

Agree on the CH340s ... these are my current favorites as well.

Dave

[KE5FX]

Interesting, as this bug seems to apply to Windows as well as Linux going by the thread on the SILabs forum. 

I have a customer with a CP2104-based design that would almost certainly have run into this problem by now, but there's been no sign of it.  The CP2104 is actually an older part, but it's footprint compatible.  Have you tried it as a substitute for the CP2102N, or is that not an option?

[Marco]

Also, it can be upgraded to EFM8UB1 with no PCB change (CP2102N is itself a pre-programmed version of EFM8UB1), and gain access to ADC, PWM and others.

Wild guess ... the driver reprograms it but they don't want to expose the method to do so any more than they are already doing, because then you could just use the CP2102N as a generic micro.

Of course that would mean that reverse engineering the windows driver would allow you to do so now.

[wraper]

Also, it can be upgraded to EFM8UB1 with no PCB change (CP2102N is itself a pre-programmed version of EFM8UB1), and gain access to ADC, PWM and others.

Wild guess ... the driver reprograms it but they don't want to expose the method to do so any more than they are already doing, because then you could just use the CP2102N as a generic micro.

Of course that would mean that reverse engineering the windows driver would allow you to do so now.

There is no point doing this. The same blank MCU is cheaper. Also, if they are using 8KB flash variant of EFM8UB1, there is not enough space for USB bootloader in addition to main firmware. Although most likely it's EFM8UB10F16G considering there is 28 pin variant.

[texaspyro]

I have had a lot of problems using Prolific chips with Lady Heather on Windows...  they work fine for a few hours then start garbaging the data.  It could be the USB dongles I have contain clone chips?  The same dongles work fine on Linux.

Also, the CHxxx drivers for Linux seem to have issues working with clone chips... they don't let you set the baud rate.

[sleemanj]

Both the 2102 and 2014 are NRND, but there is no shortage of them and as above pin compatible (I'm pretty sure the 04 and 02 are pin compatible), the 2104 is cheaper and seems about the same price as 2102N.  I'd just use one of those until the N series is fixed.

Also, disappointing behaviour of Silabs not fixing it for Linux, that's uncool.  The CH340 is OK but it's a large package and needs it's own xtal.

[oPossum]

CH340B, CH340C and CH340E do not require a crystal.

CH340E is MSOP10 package.

[stj]

adding my experience, +1 for WCH chips 340/341 series.
never had an issue with them - they seem o.k. on windowz too, but i didnt test that much - just on my eeprom programmer.

[jeremy]

Thanks for the pointers. I do normally use the CH340, but for the ESP32 you need both RTS and DTR. This means that you need to use the SOIC-16 version of the CH340, which is pretty big compared to a QFN, which is why I was trying to use the CP2102N. I think I'll just try to use the CP2102 instead for now.

[bson]

Never FTDI.    I'll never use any of their products.

[radar_macgyver]

So just in case anyone else stumbled on this, the original thread on Silabs' forum indicates that this was caused by a firmware bug that was fixed in the CP2102N-A02 version of the chip. I guess the underlying micro used can't be reflashed?

[Syntax Error]

Anecdotally, my CP2102N usb to uart board was somewhat unpredictable in it's performance. It would tend to hang. Even after rebinding the USB bus, it was still DOA. I concluded I had a 'fake' device, so I sent it to Silicon Hell burn

I've been using FT232H devices, and they've proved stable with both Windows and Linux. https://www.ftdichip.com/Products/ICs/FT232H.htm

fyi I note on SourceForge, someone has a beta CP210x Programmer to adjust the EEPROM settings.
https://sourceforge.net/projects/cp210x-program/

[bson]

Good to see this is fixed in -A02, which seems to be in the pipeline as of now; e.g. https://www.mouser.com/ProductDetail/Silicon-Labs/CP2102N-A02-GQFN20R?qs=sGAEpiMZZMtv%252Bwxsgy%2FhiN7Hc8YFqmm3eGPXuA7UG2U%3D has a predicted ship date of 13-Jan-20.

[voltsandjolts]

+1 for FTDI

[LukeW]

The most reliable choice across multiple operating systems is FTDI.

Fake parts may not work reliably? Who would have thunk it?!
I’ve never had any issues with any silicon purchased through reputable distributors.

[Yansi]

How about start using the CTS and RTS flow control with these USB VCP chips?

Or just to learn how to avoid them completely and use your own USB stack so you can only blame yourself?

[mikerj]

How about start using the CTS and RTS flow control with these USB VCP chips?

Only useful if you have control over the other end of the link, not always the case.

Or just to learn how to avoid them completely and use your own USB stack so you can only blame yourself?

Or alternatively vendors could thoroughly test parts before selling them to avoid these issues.  Why do you enjoy victim blaming so much?