Electronics > Projects, Designs, and Technical Stuff
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 :palm: 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?
--- Quote from: jeremy on March 07, 2019, 11:22:12 am ---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.
--- End quote ---
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:
--- Quote from: oPossum on March 07, 2019, 02:23:31 pm ---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.
--- End quote ---
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
Navigation
[0] Message Index
[#] Next page
Go to full version