![]() ![]() This failure will affect 100% of the production run, with no acceptable workaround except recalling the product and changing out the serial chips. ![]() 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). ![]() They also do not provide a program or other means to validate a particular device as being genuine. And yes, it's intentional because the corrupted data stream contains “NON GENUINE DEVICE” or something like that. Other versions silently but intentionally corrupt the data stream. Some versions of the FTDI drivers "brick" devices they decide are fake, by changing the USB ID reported by the device. 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.)įTDI drivers don't just "not work", they take aggressive actions which can cause you major headaches in a product. 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: 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. Only fix will be with a new chip revision which has an undetermined time frame. 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. 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. The truth is that it crashes if your device sends UART data while the port is being opened, but everything else stands. Ok, so that's an exaggeration, but not by much. 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. Hi all, It feels like just yesterday I got burned by a crazy silicon bug: 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. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |