There's a term we in random ee blogs call this: being ftdicked
If you run a windows platform and you introduce FTDI chips in your design schematic, you run afoul of using accidentally counterfeit chips. Digikey and Mouser both have had this problem of counterfeits in their supply chain. And we aren't discussing FTDI-compatible chips, that do not counterfeit or claim to be FTDI. But the FTDI kills them all.
The safer alternative is to use a USB-serial chip that's cheaper, and doesn't harass users or nuke their chips: ch340G
How reliable is the documentation for the ch340g? I don't have experience with Olimex directly, and for production designs I'm wary of datasheets that are translated this poorly -- while they frequently are just fine, i've run into numerous cases where the translation has either introduced ambiguity or is just plain incomprehensible.
And that's the rub: if i get a legit ftdi chip, I have a high level of trust that it will do what it says, and there's tons of documentation.
I dont. I'm not defending FTDI's actions w/r/t their driver, just pointing out that ftdi does currently fill the market niche of "reliable, good usb-serial devices", and while I'd love for someone else to provide equivalent chips without the shit ftdi pulls, no one else has.
Cypress and Microchip also have USB-UART chips that cost less than FTDI's parts and are well documented. The CY7C65213 is even a pin-compatible replacement for the FT232R and shows up as a USB CDC device.
Nifty, thanks. I've been lucky enough to be able to default to microcontrollers with usb-serial built in recently, but that's lookkng to be short lived...
Are the CH340G drivers open source? I bought a pile of them, but have been skittish about installing one because I can't figure out where the drivers come from. Granted, knowing that FTDI's drivers come from FTDI doesn't prevent them from messing around with them, but still, the CH340G seems like more of a mystery.
The datasheet does not seem to be very specific on what protocol it actually uses.
It does however state it is software-compatible to CH341 and for that there is a linux driver[1].
Or better yet, you just stay away from FTDI, knowing that their capriciousness can lead to customers' devices being bricked or disabled in various ways.
The CH340G is really a nice and cheap chip. And I'm starting to see it in more established American designs too (as opposed to Chinese designed electronics).
LOL! Don't buy from farnell, mouser, or digikey? They've all had issues with fakes getting into the supply. Are we supposed to just up and boycott them all? And, once I've exhausted the top 3 distributors, now where do I go? I'm sure I can just call up FTDI and order 10k chips on a weekly basis right?
Actually, that's a pretty good idea. Anyone who works in supply chain, switch to ordering directly from FTDI. They'll soon realize the folly in this decision.
It's their responsibility to make sure that they're selling me what they promised me. If they can't do that, then maybe I shouldn't be purchasing from them.
Ok fine. Link me the spec that allows me to determine whether an FTDI part is genuine and I'll gladly inform the supply chain, manufacturing and testing teams I work with to reference that spec moving forward. Until then, we have to avoid anything with an FTDI brand as there's no way to be sure. Going with whomever I think is the most reputable supplier and then praying my products aren't bricked at some point in the future isn't the solution.
And what if the fake FTDI is in a piece of medical equipment keeping someone alive? Surely FTDI has no culpability in bricking it, they should have gotten a grip on their supply chain!
Yes, they should have. And tested the function. The applicable standards actually demand it.
Safety development is serious business. You cannot justify your "I want everything as cheap as possible, counterfeit or not" attitude with some hallucinated safety risk.
> As far as I understand, this "behaviour" is totally deterministic and certain. You immediately notice the problem in any test system.
FTDI does not provide any guide lines to third parties how to test whether their chips are counterfeit or not.
The only way to test it is trying to use it with FTDI's Windows driver, and FTDI randomly changes the both the detection criteria, and the action done on detecting a counterfeit chip – sometimes it bricks them, sometimes it sends gibberish, you have no way of knowing beforehand. FTDI doesn't even guarantee that this behaviour is deterministic!
"you are not allowed to update drivers unless you have validated them."
And when QA validates them on a set of systems that happen to be legit and ships it to systems that happen to have counterfeits?
You seem to be arguing in this thread with a false dilemma between EITHER we must accept counterfeiting OR we must brick the chips, but there are in between measures that are way safer.
Prior art: Several versions of Windows have been able to detect if they were "genuine". Non-genuine windows did not brick their machine, or destroy themselves. Quick googling suggests it blocks you from getting updates, and pops up with links to a page on Microsoft where you could properly license it with some discount. That exact solution may not apply here, but there are options other than destroying hardware that is carrying your name.
(I mean, this isn't even good for FTDI... how many customers will never find out about this and simply learn that "FTDI chips spontaneously die a lot"? Not the brand experience I'm looking for!)
The problem I'm pointing out is the device makes it through QA, testing and is in production in a hospital. Then, one day a Windows driver update comes down and bricks the device.
That is indefensible, regardless of whether it's right or wrong to use counterfeit parts.
> a pre-production system that will behave the exact same way
So what if all of your preproduction systems have a genuine FTDI chip in them, and many of your millions of deployed production systems have counterfeits that you don't know about? That'll be exciting.
Quality is a matter of defense in depth. You can't rely on your preproduction system running the exact same way as production. You strive for consistency, but ultimately each chip in each computer is a unique physical object made with different silicon crystals, and being identical is impossible. You want a system that's robust against a variety of subtle differences.
FTDI is just doing their small bit to make everything just a little more fragile and unpredictable where their chips are concerned, and as such their products ought to be shunned.
I see your point, and, well, agree with it. The only opposition I could see would be to make sure all your system incorporating FDTI chips comes from the same batch, and to change them all when you change one. Not realistically doable imo.
It's entirely doable and manufacturers of safety critical equipment the world over are doing it daily and recording the batch information Just In Case.
I agree with your premise, but in this case, for a medical device it would also be a Quality Systems failure. Any change in a component is scrutinized and analyzed for impact. You have no idea how many times (as a software dev for medical devices), I've had someone from Manufacturing or Purchasing come to ask me "if we change (trivial part X) to a new vendor, what can go wrong and how can we test it?" as a precursor to executing a Change Plan.
I'm not kidding. Even something as seemingly trivial as changing the type of paint used on an enclosure can trigger weeks or months of analysis depending on what's in that enclosure.
I don't disagree, it's also indefensible to ship counterfeit parts. But it's likely to happen anyways.
It's clearly unsafe to not wear a seatbelt, but it's also clearly wrong to build a device into cars that kills occupants that get in a crash if they aren't wearing one.
The fact that your have/had net downvotes for your comment demonstrates that consensus reality is not always reality.
As an embedded medical devices engineer, I know you are exactly right. For safety-critical devices, control of the supply chain is beyond good practice, it's required by federal law, precisely so bad actors can't interfere with peoples' lives. The long list of requirements around approving a vendor are tiring and result in epic stories like the $500 toilet seat, etc., but they prevent stuff like this FTDI debacle from happening. You know it's going to be a toilet seat when the box arrives.
The medical device industry is a massive cultural shift from the majority of the HN crowd (e.g. startups and cloud services). In the world of PCs and servers, disruption is, literally, the name of the game. In IEC62304 land though, everything has to be on the straight, narrow and predictable path. This is why medical devices are expensive, laggy and not very startup-compatible. The FDA's system is actually more secure than Europe's. Take that, socialized medicine!
So it's not always wild and fun here in medical-land. It's like being a cop vs. a cowboy. You're not paid to sling your guns, but to de-escalate. But thank the conservative practices next time your elderly or congenitally defective family members found themselves in the hospital!
The medical device doesn't need to run Windows Update. The medical device might still be bricked if the computer accessing the device runs Windows Update.
We already have fitness devices that can communicate with a PC. Is it really unthinkable that the next batch of medical devices will do something similar? For example, a wearable sensor to continuously measure your insulin levels?
Will you be using an FTDI chip in such consumer devices?
The medical device doesn't need to run Windows Update. The medical device might still be bricked if the computer accessing the device runs Windows Update.
Yes, exactly.
I used to work at a sub-contractor for a large manufacturer of medical equipment, and all the systems we dealt with were like that. The device would run a very small embedded OS but would have a serial port for talking to a PC for firmware development, firmware updates, logging, diagnostics, etc. Their older stuff used real hardware serial ports, but their newer systems (~6-7 years ago now) were moving to virtual USB/FTDI serial ports, with an FTDI chip included in the embedded system.
These tricky FTDI drivers would absolutely have the potential to brick and/or alter the operation of such a device; it's not far-fetched or a flight of fancy at all.
I have a special interest in this thread/issue because I have recently been contacted by that manufacturer regarding one of these FTDI-using systems which has recently begun to exhibit new problems. I haven't started looking into that yet, and I don't know where it will lead, but I'll have to bear in mind the possibility of deliberate driver-based monkey-business now.
Instead, 'How do I know that the devices I bought up to 3 years ago don't have a "detected counterfeit" chip and get nuked by a future FTDI driver update?'
Or, 'How do I keep from getting malware and other bad actor software in via Windows Updates?'
But that's the rub: FTDI doesn't have any good process to identify fake chips, other than "install it in your board and wait and see". And if you've tried ordering from FTDI themselves, they routinely have shortages and backlogs going from 3-6 months out. Meaning you lean on reputable places like Mouser or Digikey.
And you also glossed over "FTDI compatible" chips. They too exist, and do not claim to be a legit FTDI (the markings on the case are what make a counterfeit, not the underlying silicon). Yet the FTDI driver disables them all, in one way or another.
You assume I'm talking purely about the hobbyist market: anyone who pays for a usb FTDI adapter at $1.50 should know it's likely a counterfeit.
3-6 months is not that bad. Especially if it means you can guarantee that you get genuine parts. Most real projects can easily handle this lead time for production.
At least on recent OSX the OS CDC one seems more robust than the FTDI provided one if you pull a cable while it's running. (I assume it's a genuine chip, who knows!)
Windows 10 automatically installs FTDI's driver without asking the user, or giving the user the option to opt-out, or a way to downgrade to a working version of the driver.
The best Windows ever keeps getting better; or something.
Those FTDI chips and clones only work with that driver. They aren't class compliant. What should Windows do here when a device gives the FTDI USB ID? Seems like its doing what it should.
Also, businesses typically use WSUS, where you need to intentionally whitelist driver updates.
If you have a CNC machine set to get all Windows Update from MS without oversight and testing, well, you're doing it wrong. I suspect a lot of "GUISE MY CLIENTS ALL HAVE DOWNED MACHINES THIS MORNING" is straight-up bullshit. In my experience, CNC machines are sacred cows and never, ever updated, let alone ever get driver updates. Hell, it isn't even patch Tuesday.
This does punish the hobbyist who just bought some toy and WU grabbed the latest driver. The world's manufacturing isn't going down this morning. Lets stop being naive.
/*
* Certain versions of the official Windows FTDI driver reprogrammed
* counterfeit FTDI devices to PID 0. Support these devices anyway.
*/
#define FTDI_BRICK_PID 0x0000
You can get better performance using the proprietary driver because you get access to all the device parameters. Depending on your application this can be critical.
I seem to recall that the reason was that Windows XP had a very badly broken CDC class driver so everyone (FTDI and Prolific own this market) ignored CDC and made their interfaces vendor specific.
Here's the old knowledge base article for the fix that eventually patched usbser.sys:
Had to resort to the FTDI supplied driver on OSX because the OSX bundled FTDI driver caused the entire usb subsystem to die.
I reproduced the issue by connecting two FTDI serial ports, opened each /dev/cu.usbserial* device node with a screen session, and piped War and Peace.txt through at 115200 baud. Closing the screen session on the read end would cause ALL usb devices connected to the Mac to cease functioning.
Frankly, I don't think about counterfeit chips. If I did, and had a meaningful way to determine a counterfeit, then I'd not buy products with them.
But there's no way for an end-user to do this. And since they're the ones being punished by the bricking (any supply chain movement is a second-order effect driven by upset customers), and since I lack the technical capacity to identify a knock-off, then my most rational course of action is to avoid anything that might be counterfeit . . . by insisting on a totally different chip.
Not having FTDI in your design is a feature. And that's easily checked by plugging the device into a USB port and looking at the VID/PID.
I've purchased what I thought was an industrial spec microcontroller board from a legitimate and respected supplier, through Farnell, and it had a counterfeit FTDI chip on it.
I built that board into a piece of test equipment that's likely to be used for 5 or 10 years. Fortunately this whole saga happened while I was still developing it - if their chip bricking driver had been released a year later, I'd probably not have known about it. Someone would connect the test PC to Windows Update in 3 years time, and the device would stop working.
Counterfeit chips are a reality, and not one that people building devices on a small scale can properly mitigate against. Not buying chips on alibaba is common sense, but not buying pre-built modules from Farnell? If you're not going to buy them from Farnell, where are you going to buy them from?
I'm not disputing that you can easily get a counterfeit chip without it being your fault.
But why do you simply accept that? Have you even complained to Farnell?
Read the sundry web forums, very few people complain to their distributor. Everyone bitches about FTDI.
And that's what's really bugging me here. In the FTDI case the problem has obviously gotten out of hand. I can totally understand that the manufacturer wants to get tougher.
The problem is that FTDI ist taking it out on the customer, and hoping that "the FTDI driver bricked my board" somehow gets those customers to (1) realize that the problem is a counterfeit chip, (2) work their way up the supply chain until they find the party at fault (or get the supply chain to take care of the problem), and (3) manage to get a replacement for the product which uses genuine FTDI chips.
Why not just pop up a small window with a message "Hey, this product seems to contain counterfeit chips. Please tell us where you bought it so that _we_ can take care of the problem."
Just FYI, but displaying a Message Box from the context of a Windows device driver is not trivial and would add significant overhead to the driver.
I'd prefer it if FTDI weren't utter douchebags around this whole ordeal. I understand they have to make money, but since when is it a problem when devices are API-compatible with existing device drivers? As far as I'm concerned, this is a rather common and generally beneficial thing.
That's because FTDI has taken the approach of fucking as many people that didn't actually do anything wrong to somehow punish the counterfeiters. How does bricking something sold 4 years ago do anything helpful?
That breaking a license and using software with hardware it wasn't ever intended to be used with might produce undefined behaviour?
Don't get me wrong: It would be great if we had an open source FTDI driver. But putting the blame on FTDI for all the people effectively pirating their software isn't the way to go.
If you are a stern supporter of Free/open source licenses you also need to accept other peoples' rights to license their work as they think is right. Because without a strong licensing framework GPL & co. don't work either.
Here we go again. The issue here is that it's really difficult to buy chips directly from FTDI. So.. you have to buy from a distributor. Those distributors also buy from 3rd parties, trade inventory, issue new old stock, etc...
How can I, as consumer, be absolutely positive that that the "FTDI" chip in my device is genuine? I'll go ahead and answer that. I can't. Anyone who works in the electronics industry knows this. When everything is made in china, it's very hard to be sure that fakes don't end up where they shouldn't belong.
Why do I bring this up? Because, last time they pulled this crap, reputable brand's products were damaged. Somehow some fakes ended up in their supply and those customers got screwed.
OK, so sure, we can fix the supply chain, add expensive testing to the manufacturing process, buy direct from manufacturer, etc... or hey, I got a better idea. Let's just not buy FTDI any longer. That sounds much cheaper and less painful.
>So.. you have to buy from a distributor. Those distributors also buy from 3rd parties
In countries that respect IP this isn't a problem. The larger issue is China, Taiwan, etc don't respect IP and hard tactics like the FTDI driver bricking becomes a reality. No one wants to talk about the elephant in the room: Asian manufacturer corruption and lack of accountability with IP issues in those countries.
Lets get one thing straight here. Multiple people/management in the supply chain here know these things are fake. They aren't stupid. They know that a no-name manufacturer who suddenly undercuts everyone else and uses FTDI's driver is a counterfeit. They chose this knowingly to save cost and said 'fuck all' to any issues later down the line.
>Let's just not buy FTDI any longer.
Dell didn't need to buy FTDI to have the nightmarish capacitor plague issue. FTDI didn't make all the toxic dogfood that killed all those US dogs in 2007. FTDI had nothing to do with putting melamine in infant formula. Again, you're ignoring the real issues of how China and Taiwan and other governments do a "wink, wink, nod, nod" when its comes to IP issues and encourage and even protect counterfeiters for the sake of economic output and underselling those who respect IP.
Oh well, here comes the downvotes because on HN you can't criticize China, only Western nations.
edit: to the person who thinks the capacitor issue was just a 'QA issue.' It was corporate espionage against Japan from China to get around IP issues:
> In countries that respect IP this isn't a problem. The larger issue is China, Taiwan, etc don't respect IP and hard tactics like the FTDI driver bricking becomes a reality. No one wants to talk about the elephant in the room: Asian manufacturer corruption and lack of accountability with IP issues in those countries.
Wait what? The real issue is that manufacturers can push broken drivers (kernel-mode code!), with seemingly no oversight, to users who no longer have an option to opt out.
> In countries that respect IP this isn't a problem.
I don't disagree with you, but you can't ignore the realities of the world. One of those is that almost all electronics are made in these regions (fake and genuine). This is why supply chain control is very difficult in these places. Additionally, supply chain control is not my problem to solve. It's the vendor's (FTDI).
> Dell didn't need to buy FTDI to have the nightmarish capacitor plague issue.
None of those issues were created intentionally by a reputable company. Dell didn't intentionally start building bad caps. It was due to a QA process gap at a fairly reputable capacitor manufacturer. It was a mistake... In this case, FTDI is doing this on purpose. It's totally reasonable to blame FTDI for a problem they created.
I think GP's point was the capacitor issue was still a corporate IP issue. A (tampered) formula for electrolytic capacitor dielectric was stolen and the resulting capacitors were prone to premature failure.
Dell didn't intentionally create that issue. They simply should have been performing better HALT to ensure they had coverage for bad caps. That's the qa escape.
In this case, there is no way to test for this as ftdi doesn't provide any way to do so. They simply break stuff after the fact. The only way to prevent this from happening is to not use ftdi branded parts.
Why do I bring this up? Because, last time they pulled this crap, reputable brand's products were damaged. Somehow some fakes ended up in their supply and those customers got screwed.
Doesn't the Somehow some fakes point to those brands not entirely deserving a reputation for not shipping fakes? I get that an isolated incident is different than not caring at all, but fake chips ending up in their products is a demonstration that they are not fully preventing it.
Whether consumers are interested in paying for products that they can be sure do not contain counterfeits is a different question than whether a given company shipped counterfeits or not.
No. It points to ftdi not providing specs or tests for detecting fakes. They just randomly break shit. If there was a way to reliably check for fakes, people would use it.
That just leads to the conclusion offered in the post I replied to:
or hey, I got a better idea. Let's just not buy FTDI any longer. That sounds much cheaper and less painful.
If you want to trade on your reputation and a manufacturer makes it impossible to verify their parts, don't use that manufacturer.
I think differing ideas of 'reputable brand' may be the problem, you can't just want to be a reputable brand and go through some motions of providing quality, you have to walk the freaking walk.
No. I'm worried that a supply chain screw up upstream is going to create unbounded liabilities for our company. If FTDI provided a mechanism to prevent this, I'd have no issue with it. We WANT to use genuine FTDI parts, but have no way to be sure other than accepting this risk that FTDI has created out of thin air. That's a risk that we simply can't take.
Well, yes. Or at least until they shape up and no longer introduce an unknown failure mode to all products using those chips.
The cost for a company to use those chips are too great now. And that result is purely FTDI's response.
They could have taken other avenues: Windows Syslog, GUI messages, warnings. Instead they chose to do a path that we plebes would have been arrested and charged with the CFAA for doing (vandalizing hardware over a network).
FTDI discovered a way to detect fakes. Obviously, this does them no good to keep it to themselves, because they know that all the chips they make are, by definition, genuine.
Logically, the proper thing to do would be to develop a counterfeit detector and distribute it to all reputable intermediaries in the supply chain between them and the customers. That way, distributors could test the chips before accepting a shipment, and before paying for knockoffs.
Instead, FTDI gave the tester to end-users, all the way down at the other end of the supply chain. Many of these people will not even know what a FTDI is. And the tester actually works by making all detected counterfeit chips non-functional, which basically means someone ordered a package and it blew up in their face after they already paid for it.
The responsibility for protecting and enforcement of trademarks rests entirely upon the owner of the mark, not upon the customer.
Agreed. I'd love to get a tool that allowed fakes to be identified and certification be provided by OEMs. Instead, we get a windows update that randomly bricks devices. Not cool.
>How can I, as consumer, be absolutely positive that that the "FTDI" chip in my device is genuine?
Well, you can't. But that's just a side effect of the clones working with FTDI's drivers for so long. Now, when the clones stop working, your distributor won't be able to sell you counterfeit chips anymore.
>Let's just not buy FTDI any longer.
That or let your distributor know (wallet, lawyers, whatever) that you want the original FTDI chips you paid for and not knock offs.
In any case this creates new opportunities on the market. FTDI had/has a quasi monopoly on those chips. When this end this might be painful in the short run but we could get so more competition into the market.
That's the booby prize. It's too late. You've shipped product containing chips that the FTDI driver bricks or disables, and (a) you are screwed, and (b) your customers are screwed.
Meanwhile FTDI is chastising you for buying counterfeit chips.
Logical response: To heck with the whole mess. Buy someone else's chips.
FTDI would arguably be justified in having their driver refuse to bind to counterfeit chips. Binding but causing deliberate malfunctions seems, to me, deserving of a lawsuit.
Exactly what they should have done. Return an error in the driver framework's evtDeviceStart (or similar...), let DeviceManager show the "device could not start" icon and write a "You are using a non-genuine USB to UART chip..." to the eventlog.
> breaking a license and using software with hardware it wasn't ever intended to be used with might produce undefined behaviour?
The problem today isn't just "undefined behavior". It could have been a problem yes, but FTDI defined this behavior quite specifically. The problem is they defined it with an in-band licensing message instead of out-of-band.
Imagine if you were using Microsoft Outlook for email (hey, we're corporate here, cut us some slack) and the Outlook client determined that your Windows installation wasn't Genuine and it decided that the proper recourse was to replace the body of all your outgoing emails with a message saying "NON GENUINE WINDOWS(TM) FOUND".
Would that sort of design be (a) insane, or (b) insane?
The end-user rarely use knowningly a FTDI chip or driver. They are part of a larger product that he payed for. An extreme example would be Monsanto selling genetically modified corn and potato seeds. Once they find counterfeit corn seeds, they alter their potato seeds so that when consumed with counterfeit corn seeds they make you vomit. You visit a restaurant, order a salad and since “you don't have license to consume the corn” you end up in the bathroom. :)
There is a free-software FTDI driver[1]. What this driver doesn't do, is to destroy or send random data to a chip it doesn't recognize as original.
While I don't like that FTDI is pushing their brick-making drivers out over automatic updates, I think the folks calling for everyone to ditch their chips are a little over the top.
Personally, I would love to have a reliable way to detect counterfeit chips. For FTDI I do! Now it is trivial to lot test my chips: Just put one (or a few depending on your level of quality) on a test jig and use the latest driver with it.
Contrast that with one of these other generic pieces of silicon. Is the argument that since the drivers are generic it doesn't matter if counterfeits make it into your products? Of course it still matters! Every single datasheet value that you used in your design is now out the window.
FTDI should absolutely be more forthcoming with their counterfeit detection process. It is going to be a tough call next time I need a USB-Serial chip. FTDI has a great product and documentation, but a future update might break my device if it used counterfeit components that were so far undetected.
The correct thing to do would be to throw the user a warning... not cause irrevocable harm. It's not going to stop the counterfeiters, it's just going to hurt legitimate customers.
This would be akin to the government poisoning cocaine shipments with anthrax to try to stop the drugs from flowing in. You won't stop anything, you'll only hurt "innocent" people.
Nobody has total control over their supply chain. Substitution of counterfeit parts can happen at many points in the supply chain. Until resilient die-level traceability is universal, the best you can hope for is to minimise the risk.
FTDI do not provide any useful traceability systems. Rather than providing their customers with a reliable means to identify genuine parts, they have hugely increased the risk posed to their customers by counterfeit parts.
And the calls from my manufacturing clients are already beginning to roll in. Lots of expensive CNC machines are going to be idle this morning while local stores are raided for serial to USB adapters, tested, then returned.
It is impossible to detect counterfeit chips electronically. The driver can only check if something produces signals that when interpreted as USB protocol indicate the FTDI PID/VID, but crucially it cannot know if this is the correct interpretation. That depends on the presence or absence of the trademarked USB logo on the device. It's entirely possible that the device has no USB logo, in which case it is not officially USB and the data the driver is interpreting as FTDI PID/VID could mean anything.
If the device doesn't have the USB logo, it means they didn't pay the USB implementors forum. There are plenty of devices which implement USB, but don't pay the license fees. It doesn't mean they just output garbage. I've also seen devices with the vaunted logo on them which failed spectacularly when it came to following USB specs.
I'm not sure what point you're making regarding the infeasibility of detecting counterfeit chips. It's not like these chips were bricked by accident. FTDI is specifically going out of its way to exploit bugs in these clones to brick them. So it looks like they have the detection thing pretty well covered.
You'll note that the opensource linux drivers works just as well with the clones. That's because they do not expend extra effort to make them not work.
The point is it's possible to build something that does not use USB, but which uses an almost identical protocol differing only in the meanings of the PIDs/VIDs. If it's based off USB 1.0 then any patents have expired, and if you don't call it "USB" or "FTDI" there is no trademark violation. In that case you would be doing absolutely nothing wrong, but the FTDI driver would still falsely detect it as "counterfeit".
Not sure why I'm being downvoted here. In the USA, deliberately using counterfeit trademarks is a crime, not just a tort (see https://en.wikipedia.org/wiki/Trademark_Counterfeiting_Act_o... ). The standard for being found guilty of a crime is "beyond reasonable doubt", not just "preponderance of the evidence" as it would be for a tort. There is no way to electronically establish counterfeiting has occurred beyond reasonable doubt, because the completely legal scenario I described is electronically indistinguishable. It's not acceptable to go accusing people of crimes when you know you can't meet that standard of proof.
EDIT: As a practical example, consider the case of I2C. This is a proprietary NXP protocol, and you have to pay to get slave addresses. So instead people use "Two Wire Interface", which is not I2C but is electronically indistinguishable. The only way to detect counterfeit use of I2C is looking at the packaging/documentation.
That's why nobody is addressing "FTDI USB serial compatible". That too is a thing, and the Chinese use 16 bit arm chips, and still get them out for about $1/ea.
and then, if I use "compatible", am I still a counterfeit? And why does my device deserve to be destroyed?
There's also 10bit addressing mode. I couldn't find a reference to address fees on NXP's current website, but as recently as 2013 they had a FAQ on their website mentioning address allocation fees:
https://web.archive.org/web/20130401000000*/http://www.nxp.c...
If you're connecting something that speaks your non-USB protocol without giving it a way to tell drivers that it's not USB then you can't really complain if th drivers think it's usb and act accordingly.
I have no problem with drivers thinking it's USB. That's not the same as actively sabotaging it and making accusations ("NON GENUINE DEVICE FOUND!") they can't prove.
Popular moralism in a nutshell. "I can steal from big companies because they're evil! But if someone even samples one of my songs I'm lawyering up!"
There's something almost psychopathic about how people just rationalize amorality because the entity they're attacking from is "big" or "different" Or "the other." I guess the mp3 wars are over with Google Music, Spotify, Apple Music, etc but for a long time it was creepy to hear these justifications from otherwise normal adults. It made you think, "What if they see me and my interests as 'the other'? What would they do without a conscience to stop them?"
If anyone out there is looking for alternatives, last time this happened I switched to the MCP2221 from microchip. It's been in about 6 hobby projects now and I'm very happy with it. Half the price in small quantities and easier to hand solder (14SO or even DIP vs 28TSSOP)
Answering my own question, it looks like it's a plain-Jane CDC device, which seems to me like really great progress - now that we've put Windows XP behind us, these chips really should be using CDC rather than proprietary drivers.
It's also worth mentioning that it uses the USB-CDC ("communications device class") standard driver, which is long supported/included in windows and linux and intended for use by arbitrary manufacturers.
The situation is not unlike that of usb keyboard/mice which use the HID ("human interface device") standard driver (which MCP2221 apparently also supports). So there won't be any argument or shenanigans about whether any third-party chip should be allowed to be compatible with this commonly available driver.
Recently I bought a 3D printer from China, and surprise, can't flash the Arduino chip. This was a bit of a set back but after a little googling, I found a work around and was backup and running.
This is (still) a stupidly reckless approach to "addressing" the supply chain counterfeit problem.
One of these days they're going to brick a pacemaker and kill someone. You have to be a special kind of delusional to think that the courts are going to care about your "good intentions" when you knowingly release a driver like this.
And "pacemaker" is really a placeholder for any system that could end up affecting safety of life, regardless of whether it was intentionally designed to. How many of these FTDI chips do you suppose are on a 747? An elevator controller? A fire suppression system? A one-off alarm system at a power plant? A nuclear power plant? How many hoops do you have to jump through before you start to leave your comfort zone? Not many...
A single lawsuit from a bad enough accident could end the company in one fell swoop. This should be a much bigger existential concern for FTDI than any amount of potential IP theft. If I were their general council, I would be looking for the vigilante engineer to sumarily fire, and put in place mechanisms to ensure that this never happens in the future.
I think the damage is done and more subtle than a huge public disaster.
When the fake-killer driver burst onto the scene previously, I just switched to microchip MCP2221's. It just wasn't worth the risk that I might accidentally source a counterfeit on a BOM and not find out until later.
If it says FTDI on it, its now a no go. Just no way to be sure anymore.
Exactly. I switched to Cypress (CP2102) chips as a response to this, even though I haven't been hit with any of these tactics from FTDI yet. They work just great. Prolific (PL2303) work well too, but I've had some issues with high baud rates there so I avoid them.
The fact is, it's impossible for me to know if an IC is genuine or not. Therefore, buying FTDI is now like playing russian roulette. If you got unlucky, you (or your customer) will have a nasty surprise, possibly years down the line. The rational choice is therefore to buy chips from manufacturers that don't do this.
Holy crap, that part's incredible. Let me count the ways...
1. It's half the price of a FT232R.
2. It's available in SOIC. Much easier to solder.
3. It's USB CDC compliant. No drivers required on most OSes.
4. Along with GPIOs, its spare pins can also be configured for ADC or DAC operation. Also, it's got an I2C master.
It doesn't have a full set of UART signals, unfortunately, but it does have a couple of configurable GPIOs. There's also the MCP2200 which sacrifices I2C for RTS/CTS.
Not quite, failing to talk to them would be not sending anything, what they're actually doing is much worse. Based on what people have seen it's sending random data to the device. E.G. I send it something like "Hello World" and it sends the device "Launch Nuke". If it actually failed to talk to the device that wouldn't be too bad, it would just look like the chip was defective. What it's doing is massively dangerous because it's basically performing fuzzing on the underlying device and who knows what that might trigger.
> What it's doing is massively dangerous because it's basically performing fuzzing on the underlying device and who knows what that might trigger.
Yes, this exactly. Most of the systems these chips are attached to are tiny embedded processors with very little RAM and no memory protection. It's almost a given that a non-negligible number of these systems will crash on this kind of input. The FTDI chip wouldn't even need to be in a critical signal path if it's spewing garbage all over memory.
I can't say I'm feeling sorry for the counterfeiters. Now it sucks if you got suckered into thinking you had bought one thing and ended up with another, back when RAM was both expensive and in short supply(and Intel was still making it) it was not uncommon to have "grey market" RAM with Intel markings but substandard chips.
It is always interesting to see the mechanics at play too, people who get counterfeit chips are more often (but not always) people who have released all "quality" requirements in order to achieve the lowest possible price. As being price preferred they put themselves at risk of getting substandard parts, and then when they get parts that don't work or work anomalously, they frame that problem as someone else's problem rather than their own choice.
In the referenced forum post you have a person using "Chinese clone" Arduino nanos which happen to have chips on them that report as FTDI USB to serial converters but are in fact something else. So drop the vendor or have the vendor write their own USB driver for windows but why hate on FTDI for identifying the bogus chip and refusing to work with it?
Because they're breaking the consumer's experience, not the vendor's. I guess their assumption is that angry consumers will trickle up to the vendor and cause them to go "genuine," but that seems unlikely to me. Why? Because as a consumer, I have no way of knowing whether the FTDI product I'm buying is genuine. It adds risk to buying anything that says "FTDI" on it. I'm not going to vote with my wallet for some nebulous, unverifiable assertion that a chip will be real FTDI before I get it. I'm going to vote for something I know I can plug in and use.
Already a lot of counterfeit users of FTDI (i.e. knockoff Arduinos and cheap "VAG-COM KKL" auto diagnostic cables) are switching to CH340 instead of buying real FTDI.
I agree, and then the consumer decides it isn't worth buying the knock-offs, and the vendor switches to something which costs more than their counterfeit but isn't as expensive as the FTDI parts and we're back to competing above ground rather than below ground.
I'm hoping we can train consumers to not buy things based on "lowest price" without understanding what was done to achieve that price.
> Already a lot of counterfeit users of FTDI (i.e. knockoff Arduinos and cheap "VAG-COM KKL" auto diagnostic cables) are switching to CH340 instead of buying real FTDI.
The driver situation for CH340 seems a bit sketchy. Whenever I've considered buying cheap Arduino Uno R3 clones via aliexpress.com, but then first went searching for CH340 OS X drivers, all I've found have been drivers on random sites whose provenance seems to be "I found this somewhere". Often these are unsigned drivers so I'd have to disable driver signing to use them, although last time I looked there was a set of signed drivers floating around.
For Arduino knockoffs, I prefer something that uses the same hardware that a genuine Arduino would use, or something that works with the CDC driver that comes with the OS. For Uno R3, this is the clone I'm using for development [1]. It uses an ATmega16u2 to handle the USB, which is what a genuine Uno R3 uses.
The counterfeiters aren't the ones being punished. They're getting off scott free.
The only thing the counterfeiters are losing is one of the chips they are fabricating. They're fabbing other fakes, they'll move on. And they can always try to push their pile of fake FTDI parts (it's sunk cost, and you can always find a sucker).
The counterfeiters aren't the ones being punished. They're getting off scott free.
Why do you think that? A lot of players in the supply chain are enabling the counterfeiting. It's going to be very difficult for any of them to move inventory on those counterfeit chips.
I agree. And in a way, end users have to bear some of the responsibility for this mess too - we all benefit from lower-priced components because of the electronics supply chain in China that freely mixes in counterfeit parts. No one who benefits from a crime or from immoral behaviour can be said to be completely innocent.
We don't absolve people who buy diamond jewelry of all responsibility for buying 'blood diamonds' - we say that consumers have to be aware of where diamonds come from and hold jewelers responsible for sourcing diamonds carefully.
I think the really unfortunate lesson for small parts suppliers like FTDI is that if they really want to protect their IP from Chinese counterfeiters free-riding on their driver development work, they need to begin building designs that require software uploads, binary blobs, and key exchanging, none of which are good for open hardware development and open source software.
>No one who benefits from a crime or from immoral behaviour can be said to be completely innocent.
Then there is no innocent person in existence and the term becomes meaningless. So, to avoid having to fully deprecate the term, we veto the above definition.
Whatever is on the knockoff nanos now seems great. cg340 or something. 5 years ago I had a hell of a time trying to unlearn parallel port crap and figure out all the ftdi hype, aaand now I don't have to worry about it. Stupid move ftdi.
Somedays ago discovered that my FT232 which I used to develop a FTDI user-space driver for Android is a counterfeit one. Ironically the feedback I've received about this project is mostly positive.
I now have to test the Flow control and the parity/frame... signals so I hope I wont have to buy one.
Before the 1st FTDIGate, as a guy who has implemented user-space drivers for the most common USB to serial converters my opinions about the FTDI were quite good (from an engineering standpoint I really like the solution they use to send the CTS,Parity status, Break... in a two bytes packet every 40ms which it is a good simulation of a serial port instead of having to poll sending control commands) but now I would recommend to avoid them.
From my humble experience I would recommend CP2102, they work fine (and have a nice documentation for driver developers). The CH340/CH341 is real pain.
141 comments
[ 4.7 ms ] story [ 203 ms ] threadIf you run a windows platform and you introduce FTDI chips in your design schematic, you run afoul of using accidentally counterfeit chips. Digikey and Mouser both have had this problem of counterfeits in their supply chain. And we aren't discussing FTDI-compatible chips, that do not counterfeit or claim to be FTDI. But the FTDI kills them all.
The safer alternative is to use a USB-serial chip that's cheaper, and doesn't harass users or nuke their chips: ch340G
Datasheet: https://www.olimex.com/Products/Breadboarding/BB-CH340T/reso...
And that's the rub: if i get a legit ftdi chip, I have a high level of trust that it will do what it says, and there's tons of documentation.
Even after seeing them pull a stunt like this in their drivers?
[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....
The manufacturer's website is http://wch.cn
Their drivers are here: http://wch.cn/index.php?s=/page-search_content-keyword-USB%E...
They don't appear to be open source, but I believe they are signed drivers for both Windows and OSX.
The CH340G is really a nice and cheap chip. And I'm starting to see it in more established American designs too (as opposed to Chinese designed electronics).
https://en.wikipedia.org/wiki/Pyrrhic_victory
Actually, that's a pretty good idea. Anyone who works in supply chain, switch to ordering directly from FTDI. They'll soon realize the folly in this decision.
Safety development is serious business. You cannot justify your "I want everything as cheap as possible, counterfeit or not" attitude with some hallucinated safety risk.
I agree. I don't want to put counterfeits in my product.
Now, show me FTDI's standards documents that indicate how to identify and test for fakes. (Hint: they don't)
As far as I understand, this "behaviour" is totally deterministic and certain. You immediately notice the problem in any test system.
Don't believe that safety-critical devices are allowed to install some drivers willy-nilly!
FTDI does not provide any guide lines to third parties how to test whether their chips are counterfeit or not.
The only way to test it is trying to use it with FTDI's Windows driver, and FTDI randomly changes the both the detection criteria, and the action done on detecting a counterfeit chip – sometimes it bricks them, sometimes it sends gibberish, you have no way of knowing beforehand. FTDI doesn't even guarantee that this behaviour is deterministic!
And when QA validates them on a set of systems that happen to be legit and ships it to systems that happen to have counterfeits?
You seem to be arguing in this thread with a false dilemma between EITHER we must accept counterfeiting OR we must brick the chips, but there are in between measures that are way safer.
Prior art: Several versions of Windows have been able to detect if they were "genuine". Non-genuine windows did not brick their machine, or destroy themselves. Quick googling suggests it blocks you from getting updates, and pops up with links to a page on Microsoft where you could properly license it with some discount. That exact solution may not apply here, but there are options other than destroying hardware that is carrying your name.
(I mean, this isn't even good for FTDI... how many customers will never find out about this and simply learn that "FTDI chips spontaneously die a lot"? Not the brand experience I'm looking for!)
That is indefensible, regardless of whether it's right or wrong to use counterfeit parts.
So what if all of your preproduction systems have a genuine FTDI chip in them, and many of your millions of deployed production systems have counterfeits that you don't know about? That'll be exciting.
Quality is a matter of defense in depth. You can't rely on your preproduction system running the exact same way as production. You strive for consistency, but ultimately each chip in each computer is a unique physical object made with different silicon crystals, and being identical is impossible. You want a system that's robust against a variety of subtle differences.
FTDI is just doing their small bit to make everything just a little more fragile and unpredictable where their chips are concerned, and as such their products ought to be shunned.
I agree with your premise, but in this case, for a medical device it would also be a Quality Systems failure. Any change in a component is scrutinized and analyzed for impact. You have no idea how many times (as a software dev for medical devices), I've had someone from Manufacturing or Purchasing come to ask me "if we change (trivial part X) to a new vendor, what can go wrong and how can we test it?" as a precursor to executing a Change Plan.
I'm not kidding. Even something as seemingly trivial as changing the type of paint used on an enclosure can trigger weeks or months of analysis depending on what's in that enclosure.
Safety-critical and safety-related applications are a totally different game than what most HNers are used to!
It's clearly unsafe to not wear a seatbelt, but it's also clearly wrong to build a device into cars that kills occupants that get in a crash if they aren't wearing one.
As an embedded medical devices engineer, I know you are exactly right. For safety-critical devices, control of the supply chain is beyond good practice, it's required by federal law, precisely so bad actors can't interfere with peoples' lives. The long list of requirements around approving a vendor are tiring and result in epic stories like the $500 toilet seat, etc., but they prevent stuff like this FTDI debacle from happening. You know it's going to be a toilet seat when the box arrives.
The medical device industry is a massive cultural shift from the majority of the HN crowd (e.g. startups and cloud services). In the world of PCs and servers, disruption is, literally, the name of the game. In IEC62304 land though, everything has to be on the straight, narrow and predictable path. This is why medical devices are expensive, laggy and not very startup-compatible. The FDA's system is actually more secure than Europe's. Take that, socialized medicine!
So it's not always wild and fun here in medical-land. It's like being a cop vs. a cowboy. You're not paid to sling your guns, but to de-escalate. But thank the conservative practices next time your elderly or congenitally defective family members found themselves in the hospital!
We already have fitness devices that can communicate with a PC. Is it really unthinkable that the next batch of medical devices will do something similar? For example, a wearable sensor to continuously measure your insulin levels?
Will you be using an FTDI chip in such consumer devices?
Yes, exactly.
I used to work at a sub-contractor for a large manufacturer of medical equipment, and all the systems we dealt with were like that. The device would run a very small embedded OS but would have a serial port for talking to a PC for firmware development, firmware updates, logging, diagnostics, etc. Their older stuff used real hardware serial ports, but their newer systems (~6-7 years ago now) were moving to virtual USB/FTDI serial ports, with an FTDI chip included in the embedded system.
These tricky FTDI drivers would absolutely have the potential to brick and/or alter the operation of such a device; it's not far-fetched or a flight of fancy at all.
I have a special interest in this thread/issue because I have recently been contacted by that manufacturer regarding one of these FTDI-using systems which has recently begun to exhibit new problems. I haven't started looking into that yet, and I don't know where it will lead, but I'll have to bear in mind the possibility of deliberate driver-based monkey-business now.
Instead, 'How do I know that the devices I bought up to 3 years ago don't have a "detected counterfeit" chip and get nuked by a future FTDI driver update?'
Or, 'How do I keep from getting malware and other bad actor software in via Windows Updates?'
And you also glossed over "FTDI compatible" chips. They too exist, and do not claim to be a legit FTDI (the markings on the case are what make a counterfeit, not the underlying silicon). Yet the FTDI driver disables them all, in one way or another.
You assume I'm talking purely about the hobbyist market: anyone who pays for a usb FTDI adapter at $1.50 should know it's likely a counterfeit.
But for a normal part? It's lousy.
At least on recent OSX the OS CDC one seems more robust than the FTDI provided one if you pull a cable while it's running. (I assume it's a genuine chip, who knows!)
The best Windows ever keeps getting better; or something.
Also, businesses typically use WSUS, where you need to intentionally whitelist driver updates.
If you have a CNC machine set to get all Windows Update from MS without oversight and testing, well, you're doing it wrong. I suspect a lot of "GUISE MY CLIENTS ALL HAVE DOWNED MACHINES THIS MORNING" is straight-up bullshit. In my experience, CNC machines are sacred cows and never, ever updated, let alone ever get driver updates. Hell, it isn't even patch Tuesday.
This does punish the hobbyist who just bought some toy and WU grabbed the latest driver. The world's manufacturing isn't going down this morning. Lets stop being naive.
Also, it's a little late for driver rollback if your hardware is already bricked.
Here are all the drivers for "proprietary" USB UARTs that are currently supported by Linux: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....
Here's the class compliant "Abstract Control Model driver for USB modems and ISDN adapters": https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....
Here's the old knowledge base article for the fix that eventually patched usbser.sys:
https://support.microsoft.com/en-ca/kb/943198
I reproduced the issue by connecting two FTDI serial ports, opened each /dev/cu.usbserial* device node with a screen session, and piped War and Peace.txt through at 115200 baud. Closing the screen session on the read end would cause ALL usb devices connected to the Mac to cease functioning.
But there's no way for an end-user to do this. And since they're the ones being punished by the bricking (any supply chain movement is a second-order effect driven by upset customers), and since I lack the technical capacity to identify a knock-off, then my most rational course of action is to avoid anything that might be counterfeit . . . by insisting on a totally different chip.
Not having FTDI in your design is a feature. And that's easily checked by plugging the device into a USB port and looking at the VID/PID.
FTDI has a death wish.
I built that board into a piece of test equipment that's likely to be used for 5 or 10 years. Fortunately this whole saga happened while I was still developing it - if their chip bricking driver had been released a year later, I'd probably not have known about it. Someone would connect the test PC to Windows Update in 3 years time, and the device would stop working.
Counterfeit chips are a reality, and not one that people building devices on a small scale can properly mitigate against. Not buying chips on alibaba is common sense, but not buying pre-built modules from Farnell? If you're not going to buy them from Farnell, where are you going to buy them from?
But why do you simply accept that? Have you even complained to Farnell?
Read the sundry web forums, very few people complain to their distributor. Everyone bitches about FTDI.
And that's what's really bugging me here. In the FTDI case the problem has obviously gotten out of hand. I can totally understand that the manufacturer wants to get tougher.
Why not just pop up a small window with a message "Hey, this product seems to contain counterfeit chips. Please tell us where you bought it so that _we_ can take care of the problem."
I'd prefer it if FTDI weren't utter douchebags around this whole ordeal. I understand they have to make money, but since when is it a problem when devices are API-compatible with existing device drivers? As far as I'm concerned, this is a rather common and generally beneficial thing.
That breaking a license and using software with hardware it wasn't ever intended to be used with might produce undefined behaviour?
Don't get me wrong: It would be great if we had an open source FTDI driver. But putting the blame on FTDI for all the people effectively pirating their software isn't the way to go.
If you are a stern supporter of Free/open source licenses you also need to accept other peoples' rights to license their work as they think is right. Because without a strong licensing framework GPL & co. don't work either.
How can I, as consumer, be absolutely positive that that the "FTDI" chip in my device is genuine? I'll go ahead and answer that. I can't. Anyone who works in the electronics industry knows this. When everything is made in china, it's very hard to be sure that fakes don't end up where they shouldn't belong.
Why do I bring this up? Because, last time they pulled this crap, reputable brand's products were damaged. Somehow some fakes ended up in their supply and those customers got screwed.
OK, so sure, we can fix the supply chain, add expensive testing to the manufacturing process, buy direct from manufacturer, etc... or hey, I got a better idea. Let's just not buy FTDI any longer. That sounds much cheaper and less painful.
In countries that respect IP this isn't a problem. The larger issue is China, Taiwan, etc don't respect IP and hard tactics like the FTDI driver bricking becomes a reality. No one wants to talk about the elephant in the room: Asian manufacturer corruption and lack of accountability with IP issues in those countries.
Lets get one thing straight here. Multiple people/management in the supply chain here know these things are fake. They aren't stupid. They know that a no-name manufacturer who suddenly undercuts everyone else and uses FTDI's driver is a counterfeit. They chose this knowingly to save cost and said 'fuck all' to any issues later down the line.
>Let's just not buy FTDI any longer.
Dell didn't need to buy FTDI to have the nightmarish capacitor plague issue. FTDI didn't make all the toxic dogfood that killed all those US dogs in 2007. FTDI had nothing to do with putting melamine in infant formula. Again, you're ignoring the real issues of how China and Taiwan and other governments do a "wink, wink, nod, nod" when its comes to IP issues and encourage and even protect counterfeiters for the sake of economic output and underselling those who respect IP.
Oh well, here comes the downvotes because on HN you can't criticize China, only Western nations.
edit: to the person who thinks the capacitor issue was just a 'QA issue.' It was corporate espionage against Japan from China to get around IP issues:
https://en.wikipedia.org/wiki/Capacitor_plague#Industrial_es...
Wait what? The real issue is that manufacturers can push broken drivers (kernel-mode code!), with seemingly no oversight, to users who no longer have an option to opt out.
I don't disagree with you, but you can't ignore the realities of the world. One of those is that almost all electronics are made in these regions (fake and genuine). This is why supply chain control is very difficult in these places. Additionally, supply chain control is not my problem to solve. It's the vendor's (FTDI).
> Dell didn't need to buy FTDI to have the nightmarish capacitor plague issue.
None of those issues were created intentionally by a reputable company. Dell didn't intentionally start building bad caps. It was due to a QA process gap at a fairly reputable capacitor manufacturer. It was a mistake... In this case, FTDI is doing this on purpose. It's totally reasonable to blame FTDI for a problem they created.
I don't see that as a "QA process gap".
In this case, there is no way to test for this as ftdi doesn't provide any way to do so. They simply break stuff after the fact. The only way to prevent this from happening is to not use ftdi branded parts.
Please don't do this here. The HN guidelines explicitly ask you not to go on about downvotes, and the on-HN-my-opinion-is-oppressed line is tiresome.
Doesn't the Somehow some fakes point to those brands not entirely deserving a reputation for not shipping fakes? I get that an isolated incident is different than not caring at all, but fake chips ending up in their products is a demonstration that they are not fully preventing it.
Whether consumers are interested in paying for products that they can be sure do not contain counterfeits is a different question than whether a given company shipped counterfeits or not.
or hey, I got a better idea. Let's just not buy FTDI any longer. That sounds much cheaper and less painful.
If you want to trade on your reputation and a manufacturer makes it impossible to verify their parts, don't use that manufacturer.
I think differing ideas of 'reputable brand' may be the problem, you can't just want to be a reputable brand and go through some motions of providing quality, you have to walk the freaking walk.
The cost for a company to use those chips are too great now. And that result is purely FTDI's response.
They could have taken other avenues: Windows Syslog, GUI messages, warnings. Instead they chose to do a path that we plebes would have been arrested and charged with the CFAA for doing (vandalizing hardware over a network).
Logically, the proper thing to do would be to develop a counterfeit detector and distribute it to all reputable intermediaries in the supply chain between them and the customers. That way, distributors could test the chips before accepting a shipment, and before paying for knockoffs.
Instead, FTDI gave the tester to end-users, all the way down at the other end of the supply chain. Many of these people will not even know what a FTDI is. And the tester actually works by making all detected counterfeit chips non-functional, which basically means someone ordered a package and it blew up in their face after they already paid for it.
The responsibility for protecting and enforcement of trademarks rests entirely upon the owner of the mark, not upon the customer.
Well, you can't. But that's just a side effect of the clones working with FTDI's drivers for so long. Now, when the clones stop working, your distributor won't be able to sell you counterfeit chips anymore.
>Let's just not buy FTDI any longer.
That or let your distributor know (wallet, lawyers, whatever) that you want the original FTDI chips you paid for and not knock offs.
In any case this creates new opportunities on the market. FTDI had/has a quasi monopoly on those chips. When this end this might be painful in the short run but we could get so more competition into the market.
That's the booby prize. It's too late. You've shipped product containing chips that the FTDI driver bricks or disables, and (a) you are screwed, and (b) your customers are screwed.
Meanwhile FTDI is chastising you for buying counterfeit chips.
Logical response: To heck with the whole mess. Buy someone else's chips.
This was not well thought out.
The problem today isn't just "undefined behavior". It could have been a problem yes, but FTDI defined this behavior quite specifically. The problem is they defined it with an in-band licensing message instead of out-of-band.
Imagine if you were using Microsoft Outlook for email (hey, we're corporate here, cut us some slack) and the Outlook client determined that your Windows installation wasn't Genuine and it decided that the proper recourse was to replace the body of all your outgoing emails with a message saying "NON GENUINE WINDOWS(TM) FOUND".
Would that sort of design be (a) insane, or (b) insane?
There is a free-software FTDI driver[1]. What this driver doesn't do, is to destroy or send random data to a chip it doesn't recognize as original.
[1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...
We do have an open source FTDI driver, and it works perfectly with both the real thing and with clones.
Personally, I would love to have a reliable way to detect counterfeit chips. For FTDI I do! Now it is trivial to lot test my chips: Just put one (or a few depending on your level of quality) on a test jig and use the latest driver with it.
Contrast that with one of these other generic pieces of silicon. Is the argument that since the drivers are generic it doesn't matter if counterfeits make it into your products? Of course it still matters! Every single datasheet value that you used in your design is now out the window.
FTDI should absolutely be more forthcoming with their counterfeit detection process. It is going to be a tough call next time I need a USB-Serial chip. FTDI has a great product and documentation, but a future update might break my device if it used counterfeit components that were so far undetected.
Oh and it's not reliable because you might get one that's accepted by the current driver but gets bricked in the future
This would be akin to the government poisoning cocaine shipments with anthrax to try to stop the drugs from flowing in. You won't stop anything, you'll only hurt "innocent" people.
A better analogy would be the government enforcing an import ban by adding sugar to the petrol imported from specific countries.
FTDI do not provide any useful traceability systems. Rather than providing their customers with a reliable means to identify genuine parts, they have hugely increased the risk posed to their customers by counterfeit parts.
http://www.publicintegrity.org/2011/11/07/7323/counterfeit-c... http://spectrum.ieee.org/computing/hardware/counterfeit-chip...
I'm not sure what point you're making regarding the infeasibility of detecting counterfeit chips. It's not like these chips were bricked by accident. FTDI is specifically going out of its way to exploit bugs in these clones to brick them. So it looks like they have the detection thing pretty well covered.
You'll note that the opensource linux drivers works just as well with the clones. That's because they do not expend extra effort to make them not work.
EDIT: As a practical example, consider the case of I2C. This is a proprietary NXP protocol, and you have to pay to get slave addresses. So instead people use "Two Wire Interface", which is not I2C but is electronically indistinguishable. The only way to detect counterfeit use of I2C is looking at the packaging/documentation.
and then, if I use "compatible", am I still a counterfeit? And why does my device deserve to be destroyed?
You what? But there's only a hundred of them.
Popular moralism in a nutshell. "I can steal from big companies because they're evil! But if someone even samples one of my songs I'm lawyering up!"
There's something almost psychopathic about how people just rationalize amorality because the entity they're attacking from is "big" or "different" Or "the other." I guess the mp3 wars are over with Google Music, Spotify, Apple Music, etc but for a long time it was creepy to hear these justifications from otherwise normal adults. It made you think, "What if they see me and my interests as 'the other'? What would they do without a conscience to stop them?"
The situation is not unlike that of usb keyboard/mice which use the HID ("human interface device") standard driver (which MCP2221 apparently also supports). So there won't be any argument or shenanigans about whether any third-party chip should be allowed to be compatible with this commonly available driver.
Here is the patch for anyone who's interested, http://kiguino.moos.io/2014/12/31/how-to-use-arduino-nano-mi...
One of these days they're going to brick a pacemaker and kill someone. You have to be a special kind of delusional to think that the courts are going to care about your "good intentions" when you knowingly release a driver like this.
And "pacemaker" is really a placeholder for any system that could end up affecting safety of life, regardless of whether it was intentionally designed to. How many of these FTDI chips do you suppose are on a 747? An elevator controller? A fire suppression system? A one-off alarm system at a power plant? A nuclear power plant? How many hoops do you have to jump through before you start to leave your comfort zone? Not many...
A single lawsuit from a bad enough accident could end the company in one fell swoop. This should be a much bigger existential concern for FTDI than any amount of potential IP theft. If I were their general council, I would be looking for the vigilante engineer to sumarily fire, and put in place mechanisms to ensure that this never happens in the future.
When the fake-killer driver burst onto the scene previously, I just switched to microchip MCP2221's. It just wasn't worth the risk that I might accidentally source a counterfeit on a BOM and not find out until later.
If it says FTDI on it, its now a no go. Just no way to be sure anymore.
The fact is, it's impossible for me to know if an IC is genuine or not. Therefore, buying FTDI is now like playing russian roulette. If you got unlucky, you (or your customer) will have a nasty surprise, possibly years down the line. The rational choice is therefore to buy chips from manufacturers that don't do this.
1. It's half the price of a FT232R.
2. It's available in SOIC. Much easier to solder.
3. It's USB CDC compliant. No drivers required on most OSes.
4. Along with GPIOs, its spare pins can also be configured for ADC or DAC operation. Also, it's got an I2C master.
It doesn't have a full set of UART signals, unfortunately, but it does have a couple of configurable GPIOs. There's also the MCP2200 which sacrifices I2C for RTS/CTS.
And quite frankly, why should they be responsible for any of those things? Shouldn't the fault be on the people who used fake chips?
Yes, this exactly. Most of the systems these chips are attached to are tiny embedded processors with very little RAM and no memory protection. It's almost a given that a non-negligible number of these systems will crash on this kind of input. The FTDI chip wouldn't even need to be in a critical signal path if it's spewing garbage all over memory.
What they are doing is allowing the driver to attach, and then sending arbitrary random crap down the line.
>>Shouldn't the fault be on the people who used fake chips?
It doesn't appear that the problem is people buying fake chips on purpose. All of the large chip distributors have unwittingly sent out fakes.
This approach punishes
- the end users, who likely had no role in this at all
- manufacturers of devices who thought they were buying legit chips
It is always interesting to see the mechanics at play too, people who get counterfeit chips are more often (but not always) people who have released all "quality" requirements in order to achieve the lowest possible price. As being price preferred they put themselves at risk of getting substandard parts, and then when they get parts that don't work or work anomalously, they frame that problem as someone else's problem rather than their own choice.
In the referenced forum post you have a person using "Chinese clone" Arduino nanos which happen to have chips on them that report as FTDI USB to serial converters but are in fact something else. So drop the vendor or have the vendor write their own USB driver for windows but why hate on FTDI for identifying the bogus chip and refusing to work with it?
Already a lot of counterfeit users of FTDI (i.e. knockoff Arduinos and cheap "VAG-COM KKL" auto diagnostic cables) are switching to CH340 instead of buying real FTDI.
I'm hoping we can train consumers to not buy things based on "lowest price" without understanding what was done to achieve that price.
The driver situation for CH340 seems a bit sketchy. Whenever I've considered buying cheap Arduino Uno R3 clones via aliexpress.com, but then first went searching for CH340 OS X drivers, all I've found have been drivers on random sites whose provenance seems to be "I found this somewhere". Often these are unsigned drivers so I'd have to disable driver signing to use them, although last time I looked there was a set of signed drivers floating around.
For Arduino knockoffs, I prefer something that uses the same hardware that a genuine Arduino would use, or something that works with the CDC driver that comes with the OS. For Uno R3, this is the clone I'm using for development [1]. It uses an ATmega16u2 to handle the USB, which is what a genuine Uno R3 uses.
[1] http://www.amazon.com/gp/product/B00P2FX9WY?psc=1&redirect=t...
The only thing the counterfeiters are losing is one of the chips they are fabricating. They're fabbing other fakes, they'll move on. And they can always try to push their pile of fake FTDI parts (it's sunk cost, and you can always find a sucker).
FTDI is punishing everyone except the bad guys.
Why do you think that? A lot of players in the supply chain are enabling the counterfeiting. It's going to be very difficult for any of them to move inventory on those counterfeit chips.
And I'm sorry, but I cannot see fit to blame FTDI for not wanting to talk to counterfeit chips.
We don't absolve people who buy diamond jewelry of all responsibility for buying 'blood diamonds' - we say that consumers have to be aware of where diamonds come from and hold jewelers responsible for sourcing diamonds carefully.
I think the really unfortunate lesson for small parts suppliers like FTDI is that if they really want to protect their IP from Chinese counterfeiters free-riding on their driver development work, they need to begin building designs that require software uploads, binary blobs, and key exchanging, none of which are good for open hardware development and open source software.
Then there is no innocent person in existence and the term becomes meaningless. So, to avoid having to fully deprecate the term, we veto the above definition.
I now have to test the Flow control and the parity/frame... signals so I hope I wont have to buy one.
Before the 1st FTDIGate, as a guy who has implemented user-space drivers for the most common USB to serial converters my opinions about the FTDI were quite good (from an engineering standpoint I really like the solution they use to send the CTS,Parity status, Break... in a two bytes packet every 40ms which it is a good simulation of a serial port instead of having to poll sending control commands) but now I would recommend to avoid them.
From my humble experience I would recommend CP2102, they work fine (and have a nice documentation for driver developers). The CH340/CH341 is real pain.