FTDIgate 2.0?

[AlxDroidDev]

In addition, the recent blocking of Dave and others by FTDIChip on Twitter just further reinforces my opinion that their management is completely inept and out of touch.

That's completely childish, to say the least. FTDI has made a fool of itself and it continues to do so. They are even worse than the Fine Brothers!

I just wonder if someone from FTDI actually reads these forums. I suspect 1 or 2 members here might be FTDI employees, because of how adamant they are in defending FTDI and their crappy business.

[madires]

bricking my chip was a really bad move,

I am sure FTDI has a different perspective: they wrote a set of procedure that works flawlessly on the genuine chip. You happen to plug your fake chip there and ...

That's called computer sabotage and is an offence in several countries, in case you don't understand the implication of bricking someting on purpose.

[dannyf]

"Did a string search in their binary, the notorious "NON GENUINE DEVICE FOUND!" string still exists"

Would be interesting to see how it rracts to a knock off. Ie. The code may be there but it may not actually run.

I have quite a few arduino boards, mostly the Leonardo and the minis. The first thing I do with them is to wipe out the bootloader as I program them as avr boards.

[FrankBuss]

I've just discovered some of the Ti evaluation/dev boards with onboard JTAG programmer (USB), use a FTDI FT2232D as the device.
$8.53 each in FTDI's shop, or 100 for $633.08, plus crappy exchange rate and postage. Now I have to wonder if FTDI's 'special' drivers* will screw with JTAG programmers, looks like I'll have to ask Ti for help as I would like to have onboard JTAG to USB in my PCB designs.

I think this is very likely. JTAG is a feature of the D2XX driver. If I configure the D2XX driver with FT_Prog (you can use this program to read your configuration), then it uses the driver ftdibus.sys, which contains the string "NON GENUINE DEVICE FOUND!". Interestingly if I configure it as "Virtual COM Port", it uses ftser2k.sys, and ftcserco.dll and ftserui2.dll, which don't contain the string.

Looks like a mess for me with all the different drivers, but this might be a problem of Windows that you can't use just one driver, if you want a virtual COM port and then other special things.

[rrinker]

Has anybody here purchased any FTDI device from a legitimate distributor in the last, say, 6 months and received a fake?

Does anyone have an Arduino Nano that doesn't have a counterfeit FTDI?  There were hints that even the original (Gravitech-manufactured) boards might have had fakes - people who had bought full-price Nanos from trusted distributors were getting their chips bricked back in 2014...

 Mine's fairly well stuck in the breadboard I have it plugged in to so I can't see the bottom to see what brand the chip is marked as, but if it's a fake FTDI, it's still working perfectly fine and my system is a fully up to date Windows 10 machine - works on my laptop as well. I wouldn't be surprised if mine actually has a knockoff of a knockoff USB chip, considering I paid like $6 for this Nano from Amazon.

[boffin]

Maybe damage control is on the way.  There's an upcoming interview between FTDI and Adafruit
https://blog.adafruit.com/2016/02/04/comingsoon-an-interview-with-fred-dart-ceo-of-ftdi-ftdichip-ftdi/

[c4757p]

Given what I've seen before, I expect they'll use this interview as a chance not for damage control, but to dig their hole even deeper. They seem to have a thing for, ahem, deep holes.

[marcan]

BTW, regarding the quality of their IP: I just tested the SPI mode of the FT2232H with their sample application for the D2XX driver and the SPI_ReadWrite function (with SPI_TRANSFER_OPTIONS_CHIPSELECT_ENABLE and SPI_TRANSFER_OPTIONS_CHIPSELECT_DISABLE, the only modification I made is to transfer 2 bytes). This is how it looks like:

FT232R. That was supposed to be a square wave, in bitbang mode. Turns out their clocking is, well.... yeah.

I wonder if the clone chip supports bitbang mode, and if it does, if it works any better.

[marcan]

Oh, this is pure gold.

FT232R, clone vs. original, outputting a 38kHz square wave in bitbang mode, same exact code driving both.



Original at the top, clone at the bottom.

Turns out the clone chips are actually better at following FTDI's own spec (and actually being useful in bitbang mode) than the original, buggy silicon.

Now where can I get a distributor that guarantees they will supply the superior clone chips? I don't want to give FTDI any money, and these things are actually useful in bitbang mode, unlike FTDI's junk.

[mtdoc]

Oh, this is pure gold.

FT232R, clone vs. original, outputting a 38kHz square wave in bitbang mode, same exact code driving both.



Original at the top, clone at the bottom.

Turns out the clone chips are actually better at following FTDI's own spec (and actually being useful in bitbang mode) than the original, buggy silicon.

Now where can I get a distributor that guarantees they will supply the superior clone chips? I don't want to give FTDI any money, and these things are actually useful in bitbang mode, unlike FTDI's junk.

That's funny.

Now their CEO is devoting time and energy doing interviews? - not a good sign.

I think it's becoming increasingly obvious that FTDI's problem is not cloners, it is FTDI.

Perhaps clone chip makers should just write their own driver and start marketing their chips as a cheaper, better, FTDI pin compatible alternative?  They could  brand them FDTI (at least that would be more honest and not illegal)....

[mikerj]

That's your opinion and the opinion of some others, mostly hobbyists who got burned by buying cheap (Chinese) products.
In a professional environment, this plays no role, apart from the fact that you have to check your sources, but a professional
already did that.

And what about the end user who has no choice in whether a genuine FTDI device was used or not?

Aim your anger to the counterfeiters, not to a a company that tries to protect their investment by not supporting
counterfeit chips with their driver. There's nothing wrong with sending the string "this is not a genuine chip" when counterfeit
is detected.

How can you possibly know that?  Can you personally guarantee that no device using an FTDI chip exists that doesn't do something bad or unexpected when that string is sent to it?  Of course you can't.  Sending that string back to the calling application at the PC end is one thing (though still stupid), but sending it to the embedded device using the FDTI chip shows a monumental level of stupidity.

[f4eru]

In a professional environment, this plays no role, apart from the fact that you have to check your sources, but a professional
already did that.

Wrong. Even professionals who check their sources get bitten. Why ? because often, they put high pressure on prices, so the source, or the source of the source of the source gets it where it's cheap. You get what you pay for, and this is the norm in Asia.

There's nothing wrong with sending the string "this is not a genuine chip" when counterfeit is detected.

Wrong and wrong.
1) They don't detect counterfeits. They detect non FTDI chips. It could be a legitimate compatible chip, a clone, a grey market FTDI silicon, or a counterfeit.
2) There's something wrong with corrupting user data. A driver should NEVER maliciously corrupt user data. If an error pops up, it should use the legitimate error channels instead (closing the port, popping up an error message, etc...).

[Karel]

That's your opinion and the opinion of some others, mostly hobbyists who got burned by buying cheap (Chinese) products.
In a professional environment, this plays no role, apart from the fact that you have to check your sources, but a professional
already did that.

And what about the end user who has no choice in whether a genuine FTDI device was used or not?

The end user puts a claim at the place where he bought it.

Aim your anger to the counterfeiters, not to a a company that tries to protect their investment by not supporting
counterfeit chips with their driver. There's nothing wrong with sending the string "this is not a genuine chip" when counterfeit
is detected.

How can you possibly know that?  Can you personally guarantee that no device using an FTDI chip exists that doesn't do something bad or unexpected when that string is sent to it?  Of course you can't.  Sending that string back to the calling application at the PC end is one thing (though still stupid), but sending it to the embedded device using the FDTI chip shows a monumental level of stupidity.

That's not the responsibility of FTDI. Every engineer that designs a possible dangerous device that uses a serial port without
any data checking protocol, is an idiot.

[Karel]

In a professional environment, this plays no role, apart from the fact that you have to check your sources, but a professional
already did that.

... because often, they put high pressure on prices, so the source, or the source of the source of the source gets it where it's cheap. You get what you pay for, and this is the norm in Asia.

You take the risk to go for cheap. You take the fame when your business goes well. You take the blame when shit happens
because of your choice to go for cheap.

There's nothing wrong with sending the string "this is not a genuine chip" when counterfeit is detected.

Wrong and wrong.
1) They don't detect counterfeits. They detect non FTDI chips. It could be a legitimate compatible chip, a clone, a grey market FTDI silicon, or a counterfeit.
2) There's something wrong with corrupting user data. A driver should NEVER maliciously corrupt user data. If an error pops up, it should use the legitimate error channels instead (closing the port, popping up an error message, etc...).

Wrong and wrong.
They do detect counterfeit chips. Show me a link to a place where I can buy a legitimate, compatible non-FTDI
chip that gets harmed by the actions of FTDI.
There's nothing wrong with sending the string "this is not a genuine chip". Counterfeiters shouldn't use somebodies elses
USB VID in order to illegally use somebodies elses driver which they have no right to.

[Karel]

Perhaps clone chip makers should just write their own driver and start marketing their chips as a cheaper, better, FTDI pin compatible alternative?  They could  brand them FDTI (at least that would be more honest and not illegal)....

They should have done that in the first place.

But probably they are not capable to write a (stable) driver, or writing it costs too much money,
or probably both...

[pickle9000]

Perhaps clone chip makers should just write their own driver and start marketing their chips as a cheaper, better, FTDI pin compatible alternative?  They could  brand them FDTI (at least that would be more honest and not illegal)....

They should have done that in the first place.

But probably they are not capable to write a (stable) driver, or writing it costs too much money,
or probably both...

Less overhead, more profit. If a programming skill was needed it could be purchased. They choose items that are profitable to copy. That means low production cost, high selling cost, and they need to pass tests.

Think about the complexity of the task design and distribution. Just getting the things on the underground market is a massive undertaking. Remember we are talking massive numbers of devices.

[Karel]

Perhaps clone chip makers should just write their own driver and start marketing their chips as a cheaper, better, FTDI pin compatible alternative?  They could  brand them FDTI (at least that would be more honest and not illegal)....

They should have done that in the first place.

But probably they are not capable to write a (stable) driver, or writing it costs too much money,
or probably both...

Less overhead, more profit. If a programming skill was needed it could be purchased. They choose items that are profitable to copy. That means low production cost, high selling cost, and they need to pass tests.

Think about the complexity of the task design and distribution. Just getting the things on the underground market is a massive undertaking. Remember we are talking massive numbers of devices.

Exactly. And FTDI whent through all of this and invested a lot of money in their driver. They have all the right to brick or sabotage counterfeit chips that abuse their driver.

[Boomerang]

The driver cannot look at the marking of the chip. Only small number of specially trained people can look at the chip, make series of tests and say "This is counterfeit for sure."

[amyk]

Oh, this is pure gold.

FT232R, clone vs. original, outputting a 38kHz square wave in bitbang mode, same exact code driving both.



Original at the top, clone at the bottom.

Turns out the clone chips are actually better at following FTDI's own spec (and actually being useful in bitbang mode) than the original, buggy silicon.

Now where can I get a distributor that guarantees they will supply the superior clone chips? I don't want to give FTDI any money, and these things are actually useful in bitbang mode, unlike FTDI's junk.

Are you sure you didn't get the two mixed up? Or perhaps they're both actually clones, but one passes the test enough to identify as genuine?

AFAIK the clones use a microcontroller whereas the genuine ones are a full ASIC. If true, funny to see the former beating the latter in timing stability... it's usually the other way around.

Karel, you might want to look up the interoperability court cases I posted - it's perfectly legal to make a clone, especially one that's completely different in terms of implementation. Even using FTDI's VID:PID is fine because it's required for interoperability. The only thing that's not is marking it with the FTDI name, and that's not something the driver can determine. In the previous long thread there was mention of COB clones, which are completely unmarked, and this one. Perhaps you work for FTDI...?

[nctnico]

Exactly. And FTDI whent through all of this and invested a lot of money in their driver. They have all the right to brick or sabotage counterfeit chips that abuse their driver.

Please seek legal counsil because your statement is wrong on so many levels!

[Karel]

Exactly. And FTDI whent through all of this and invested a lot of money in their driver. They have all the right to brick or sabotage counterfeit chips that abuse their driver.

Please seek legal counsil because your statement is wrong on so many levels!

So, soon we will see courtcases or a classaction suit against FTDI and FTDI will loose?
Go ahead and surprise me.

[rs20]

So, soon we will see courtcases or a classaction suit against FTDI and FTDI will loose?
Go ahead and surprise me.

  The victims of FTDI's vandalism can't afford legal action.

FTDI whent through all of this and invested a lot of money in their driver. They have all the right to brick or sabotage counterfeit chips that abuse their driver.

The way you think a company being the victim of counterfeiting* gives them cart blanche to do whatever petty vandalism they want is just astonishing. Schoolyard eye-for-an-eye rubbish, and not even directed at the people who did "the crime"* anyway.

* Given that you're so excited about hard evidence for everything, where is the evidence that FTDI is suffering from a significant, unusual amount of counterfeiting? A company that is perpetually out of stock doesn't really sound like it's actually struggling and maybe should be focussing on production... It's interesting to consider how many second-source (what an idiot would call "counterfeit") ICs exist out there... do you think the world would be a better place if the inventor of the first quad NAND gate started designing chips that bricked any connected quad NAND gates from second-source manufacturers? The fact that the counterfeit FTDI chips use real FTDI drivers is of zero relevance, FTDI wears zero marginal cost for having those drivers distributed by Windows Update. It seems more likely FTDI is a company dying of obsolescence (thank goodness) grasping at excuses and being petty little children about it?

[AlxDroidDev]

(...) it's perfectly legal to make a clone, especially one that's completely different in terms of implementation. Even using FTDI's VID:PID is fine because it's required for interoperability. The only thing that's not is marking it with the FTDI name, and that's not something the driver can determine. In the previous long thread there was mention of COB clones, which are completely unmarked, and this one. Perhaps you work for FTDI...?

That's exactly what I think too. If the guys making "second source" FT232s  (to use rs20's term!) hadn't branded them FTDI FT232RL, then they would be in the clear with possibly a better product and since they have a lower price, they'd have a huge demand for their chips.

It is possibly just a coincidence, but the CH340G chips appeared just around the time of FTDI Gate 1.0. I wonder if the manufacturer of the "second source" FT232 and CH are related. Neverthless, the CH340G chips possibly are taking a lot of market share of the FT232RL, since it is cheaper and as easy to implement (although it requires external crystal, which the FTDI part doesn't). I believe 99% of the Arduino clones are being shipped with the CH340G nowadays. 

And, for the FTDI fanboys out there, WCH (the manufacturer of the CH340G) also has working drivers (for Win, Linux and Mac), so that isn't a big deal. It's not like creating serial drivers for Windows requires an investment of millions of dollars.

[c4757p]

Karel, you might want to look up the interoperability court cases I posted - it's perfectly legal to make a clone, especially one that's completely different in terms of implementation. Even using FTDI's VID:PID is fine because it's required for interoperability. The only thing that's not is marking it with the FTDI name, and that's not something the driver can determine. In the previous long thread there was mention of COB clones, which are completely unmarked, and this one. Perhaps you work for FTDI...?

The fact that this will interfere with things that aren't FTDI counterfeits, just FTDI-compatibles, because, y'know, it can't read the markings on the chip, really should end this whole bloody argument. But clearly we have more sleazy businesspeople than real engineers here. Anything in the pursuit of profit...

[madires]

That's not the responsibility of FTDI. Every engineer that designs a possible dangerous device that uses a serial port without
any data checking protocol, is an idiot.

I agree on the latter, but the reality is that there are a lot of products with serial interfaces and no input validation. So it's not a non-issue.