FTDI driver kills fake FTDI FT232??

[nctnico]

I am still fairly new to Electronic Engineering. I was going to make something using a FTDI part but with all of the conservancy I don't want to use them. What is a good alternative to FTDI?

CP210x from Silabs. I have used these in the past and they are actually more stable than the FT232 in a nasty electrical environment. An FT232 often stops when something at the UART side is switched on/off. In my experience a CP2102 is much less prone to this behaviour. Anyway, I need an RS485 board so I'm going to combine that into an existing FT232 design and use a CP2102 instead.

[Fungus]

I am still fairly new to Electronic Engineering. I was going to make something using a FTDI part but with all of the conservancy I don't want to use them. What is a good alternative to FTDI?

Ten seconds with google:

http://www.ti.com/product/tusb3410

http://www.microchip.com/wwwproducts/devices.aspx?dDocName=en546923

[Fungus]

well at least I spelt it right

What does dinkel wheat have to do with FTDI drivers?

Not sure how serious that comment was, but in case you are unaware, spelt is not a misspelling, but the preferred spelling of "spelled" in British English.

Hoist with my own petard...   

[amyk]

I don't understand what the fuss about this is other than their obviously poor/abysmal PR spin control.

Simple facts are that from now on its technically not very legal to use counterfeit chips with FTDI drivers (even old drivers). So any counterfeit product that relies on FTDI's default driver is doing so illegally and if using a modern driver will always not work. So end result they are all bricks, Linux/Windows/Mac's driver repositories would either not include the driver at all or would be crossing some legal lines by keeping the older driver around.

Apparently you haven't been reading the previous few dozen pages, but I've already posted this:

http://en.wikipedia.org/wiki/Semiconductor_Chip_Protection_Act_of_1984#Reverse_engineering_not_prohibited

The SCPA permits competitive emulation of a chip by means of reverse engineering.

FTDI might not like it but they don't have an exclusive right to the API their chips use. The only way around this is a patent, but I haven't seen them claiming anything about patents here...

And for this same reason the "FTDI-compatible" serial cables that use a COB package are completely legal since there is nothing in them branded FTDI. They may have FTDI's VID:PID but those are necessary for interoperability and those numbers cannot be copyrighted.

[janengelbrecht]

Then we face a situation where a massive amount of lawsuits is a real danger for the company.....and maybe Microsoft also are in danger. It could be a good thing to get the courts in play just to make sure noone else bricks peoples equipment in the future.

[Rufus]

Moving on it looks like flaky fakes have been causing problems with FTDI drivers long before they tried to detect them.

http://www.adafruit.com/blog/2014/02/18/ftdi-ft232rl-real-vs-fake/

You got that ass-backward.

According to your linked article FTDI drivers have deliberately been causing problems for users before when they detected fake chips.

Their drivers corrupted the data being transmitted so it looked like the chips weren't working properly. The chips were working fine, it was the driver deliberately altering the data so it looked like they weren't. I wonder how much money and debugging headaches that little trick cost the world?

Why the sneakiness? Why can't their drivers just come out and say "Your chip is fake!"...?

But if the driver sticks in random bad data for detecting a fake chip and uses clever obfuscation techniques it can require extensive reverse engineering to find it if ever. (This along with any in text stream isn't very nice and is potentially dangerous)

The much more plausible explanation is the fakes were flakey and didn't work with some driver improvement. The article I linked said "The guy at FTDI seemed truly excited to get samples of chips from the same lot that both worked and failed".

How could the FTDI driver choose to corrupt operation of some fake chips and not others and do the same thing every time for the same chip? Why would they choose to ignore some fakes even if they could. They would have to keep a database of fake chip serial numbers that they had chosen to ignore or base it on some property of the chip serial number.

[zapta]

CP210x from Silabs. I have used these in the past and they are actually more stable than the FT232 in a nasty electrical environment. An FT232 often stops when something at the UART side is switched on/off. In my experience a CP2102 is much less prone to this behaviour. Anyway, I need an RS485 board so I'm going to combine that into an existing FT232 design and use a CP2102 instead.

Do they run on OSX, Linux and Windows without having to install drivers?

[Rufus]

If a machine was working yesterday and stopped working today because of something FTDI knowingly planned/did then they broke some laws.

The machine was working yesterday because you were stealing FTDI drivers. The machine is not working today because FTDI stopped you stealing their drivers.

Why don't you try stealing something from a shop and see how far you get accusing a cop taking back that something of theft?

[rolycat]

If a machine was working yesterday and stopped working today because of something FTDI knowingly planned/did then they broke some laws.

The machine was working yesterday because you were stealing FTDI drivers. The machine is not working today because FTDI stopped you stealing their drivers.

Why don't you try stealing something from a shop and see how far you get accusing a cop taking back that something of theft?

Why don't you stop trolling this thread with ludicrous assertions and terminally flawed analogies?

[nctnico]

CP210x from Silabs. I have used these in the past and they are actually more stable than the FT232 in a nasty electrical environment. An FT232 often stops when something at the UART side is switched on/off. In my experience a CP2102 is much less prone to this behaviour. Anyway, I need an RS485 board so I'm going to combine that into an existing FT232 design and use a CP2102 instead.

Do they run on OSX, Linux and Windows without having to install drivers?

They run on Linux for sure. The Linux driver is from 2005. On Windows you have to install a driver but that is true fro any USB-to-serial device. Actually installing a driver manually is quicker than waiting several minutes before Windows finds the driver by itself. You can download a driver for OSX from Silabs if it doesn't work out of the box. The CP210x devices are used a lot and have been around for over a decade.

[Simon]

If a machine was working yesterday and stopped working today because of something FTDI knowingly planned/did then they broke some laws.

The machine was working yesterday because you were stealing FTDI drivers. The machine is not working today because FTDI stopped you stealing their drivers.

Why don't you try stealing something from a shop and see how far you get accusing a cop taking back that something of theft?

Again a silly analogy, but as you insist: it's like when my grandmother moved to the UK from italy in 1945. At that time us britts were a bit more ignorant and stupid than we are now regarding food and her local fish monger was happy  to give her all the squid she wanted "for the dogs". What she didn't know my grandmother was actually cooking it for the family. Then her sister in law who was a nasty bitch went and told the fish monger that she was feeding it to the family not the dogs. So next time my grandmother wanted squid "for the dogs" (which incidentally the fish monger usually threw away) she charged my grandmother for them. However because my grandmother had eaten loads of the free squid the fish monger did not shoot my grandmother.............

[MikeGTN]

Hi,

A slight debacle, but seems FTDI might not be quite dead in the water just yet. Have this wizard new processor will be announcing sometime soonish!
http://www.mikroe.com/forum/viewtopic.php?f=185&t=61797

Hopefully my fake FT232RL will be able to talk to it!?

Mike.

[nctnico]

Why don't you try stealing something from a shop and see how far you get accusing a cop taking back that something of theft?

I love to see the reaction if I take a free piece of saucage from the butcher shop and feed it to my dog  What is the butcher going to do legally even if he puts up a sign saying 'don't give free saucage samples to your pets' ? Remember FTDI gives the drivers away for free!

[zapta]

The machine was working yesterday because you were stealing FTDI drivers. The machine is not working today because FTDI stopped you stealing their drivers.

Why don't you try stealing something from a shop and see how far you get accusing a cop taking back that something of theft?

Bad analogy again, the board is not 'stolen' but FTDI damaged it anyway. With your analogy, FTDI should delete their driver from your computer to 'take it back'.

Anyway, it's clear now that designing with FTDI is a risky choice.

[Rufus]

I love to see the reaction if I take a free piece of saucage from the butcher shop and feed it to my dog  What is the butcher going to do legally even if he puts up a sign saying 'don't give free saucage samples to your pets' ? Remember FTDI gives the drivers away for free!

"FTDI drivers may be used only in conjunction with products based on FTDI parts"

Free and only licensed for use with FTDI parts not with fakes and clones of FTDI parts.

Bad analogy again, the board is not 'stolen' but FTDI damaged it anyway. With your analogy, FTDI should delete their driver from your computer to 'take it back'.

Correcting an invalid PID isn't damage. The 'board' still works under Linux with a driver update so it clearly isn't damaged. The machine is not working today because you don't have any driver for the fake chip.

[Rigby]

The machine was working yesterday because you were stealing FTDI drivers. The machine is not working today because FTDI stopped you stealing their drivers.

Why don't you try stealing something from a shop and see how far you get accusing a cop taking back that something of theft?

Bad analogy again, the board is not 'stolen' but FTDI damaged it anyway. With your analogy, FTDI should delete their driver from your computer to 'take it back'.

Anyway, it's clear now that designing with FTDI is a risky choice.

I'm with Zapta.

AT WORST it is a trademark violation of the cloning fabs, since FTDI IP wasn't used in creating the chips, and the chips were labeled FTDI.  It's the labeling that's the issue, unless FTDI have some patents on USB<->Serial conversion which were infringed. 

There's no excuse for them to have rendered hardware inoperable.  Warn the end-user?  PLEASE.  Disable, for all intents and purposes, end-user hardware?  NO, no no NO NO NO NO NO.

[zapta]

Correcting an invalid PID isn't damage. The 'board' still works under Linux with a driver update so it clearly isn't damaged. The machine is not working today because you don't have any driver for the fake chip.

Damage:  "physical harm caused to something in such a way as to impair its value, usefulness, or normal function."

[Simon]

Hi,

A slight debacle, but seems FTDI might not be quite dead in the water just yet. Have this wizard new processor will be announcing sometime soonish!
http://www.mikroe.com/forum/viewtopic.php?f=185&t=61797

Hopefully my fake FT232RL will be able to talk to it!?

Mike.

Exactly, with products like that why do they need to be so stupid over such a small thing ? they have just damaged their reputation for use of their more expensive and cutting edge technology..........

[ziq8tsi]

The machine was working yesterday because you were stealing FTDI drivers. The machine is not working today because FTDI stopped you stealing their drivers.

"Stealing" is theft, the taking of property with intent to permanently deprive the owner.  Using a software driver without consent of the copyright holder is more akin to pillage and murder on the high seas, so we prefer to call it "piracy" or "terrorism".

Most people do not demand that FTDI's precious drivers work with counterfeit chips, just that they not intentionally destroy them.

Apparently you are sure that you never have and never will obtain a device containing a fake FT232.  Apparently you think that anyone who has obtained such a device is a cheapskate who thoroughly deserves to have their hardware bricked, possibly long after it is out of warranty,

Even disregarding how wrong you are about that, you ignore the effects on FTDI's reputation.  They quickly back-tracked, but you continue to defend their original, malicious, behavior.  Previously it was suggested you were an FTDI shill, but I think you are more likely an anti-FTDI shill, defending a policy long discontinued in order to sow further doubt.

[benSTmax]

I tried the new counterfeit-crippling driver with my pool of FTDI-based cables, boards ...
It seems I got 3 counterfeit chips after all. Anyway, using the FTDI chips might be a risky business even in the future. 
I have a couple of CP210x and they're fine however they seem hard to get sometimes. Has anyone tried the MCP2221 from Microchip?

[German_EE]

On the subject of currency copying that was discussed earlier. I was once I.T. Manager at a company that had a high-end Xerox color copier installed in the Advertizing and Sales Department. The handbook warned us that internal software would prevent making copies of bank notes so with the installation engineer present I tested this with a brand new 20 Euro note.

The machine printed a copy of the note but with the Xerox logo in the center, it then shut down and would not restart until the installation engineer reset an internal flag (could have been an EEPROM or flash) using his laptop. The machine did NOT phone home but the particular internal flag was only set after attempting to copy currency.

Now back to our regular programming 

[joshhunsaker]

"FTDI drivers may be used only in conjunction with products based on FTDI parts"

That's like saying Microsoft Office telling people in the EULA that they aren't allowed to write hate mail with it.  It's both silly and useless.

[orin]

I could be wrong (it's happened before) but I thought part of the WHQL process was that your drivers have to undergo a code review at Microsoft. That's why WHQL certification costs so much money.

For the USB drivers I've had WHQL certified, you create the driver, sign it with your own certificate and run the WHQL test suite on it on your own computers.  The results get wrapped up along with the signed driver and sent to Microsoft.  Assuming the driver passed the test suite, your driver then gets signed by Microsoft with the WHQL certificate and you download it.  That's it.

OK ... maybe USB is different because it can't really destabilize Windows (it's just a data transfer device).

A kernel mode USB driver sure can destabilize any operating system and cause panics/BSODs/whatever your OS calls it.  The WHQL test suite makes (most?) all the calls to the driver that every USB driver/device must support, but as I said, the driver can make vendor specific calls that the WHQL tests cannot validate.

As for deliberate BSODs, that is the absolute worst thing they could do.  Bricking the device is bad enough, but potentially trashing my filesystem is much worse.  Besides, if I get A BSOD, I run WinDbg on the dump and look for the cause.  If I were to see an FTDI driver as the cause, I would think that FTDI write crappy drivers and it is yet another reason to avoid them like the plague, just like I avoid Prolific chips now.  (I have a most-likely-counterfeit 'Prolific' USB-serial cable.  New drivers refuse to load; old drivers BSOD as soon as you transfer any reasonable amount of data.  That the BSOD was deliberate was news to me... I had assumed bad drivers or bad chip.  The result was that I used to advise that one should use FTDI based cables rather than Prolific.  )

[GaryM]

So I'm dumb and the clone detector tool that I linked before relied on a patched libftdi (which I hacked up when this saga started and then forgot about...)

So instead I rewrote it to use libusb and made it a lot more useful. Now it can:

• Tell you if you have a clone chip
• Fix bricked clones (by undoing exactly what the FTDI driver did, restoring the PID to 6001 but also reverting the value at 0x3e - this might fix string data corruption if your strings area was full when the FTDI driver did its dirty work, or if user data was in use)
• NEW: immunize clone chips against the evil driver by deliberately breaking the EEPROM checksum. This reverts all settings to defaults (and loses the serial number), but if those work for you, then FTDI's driver will not brick your device and will happily work with it. You can also revert this change.
  

https://mrcn.st/t/ftdi_clone_tool.py

Tested on both real devices (where it refuses to do anything) and on clones (where all of the above works; I tested it against FTDI's driver too).

A big thanks to marcan for this script. I have a couple of devices that came from unknown sources in China and which I suspected may contain fake FTDI chips. marcan's script has confirmed that both devices actually contain genuine FTDI chips which came as a bit of a surprise.

One thing to note is that when running the script I was getting the following timeout error:-

Detecting device...
Found FTDI FT232R device (0403:6001)
Traceback (most recent call last):
  File "ftdi_clone_tool.py", line 234, in <module>
    sys.exit(main())
  File "ftdi_clone_tool.py", line 106, in main
    dev.unlock_eeprom()
  File "ftdi_clone_tool.py", line 68, in unlock_eeprom
    timeout=self.timeout)
  File "/usr/local/lib/python2.7/site-packages/usb/legacy.py", line 205, in controlMsg
    timeout = timeout)
  File "/usr/local/lib/python2.7/site-packages/usb/core.py", line 971, in ctrl_transfer
    self.__get_timeout(timeout))
  File "/usr/local/lib/python2.7/site-packages/usb/backend/libusb0.py", line 528, in ctrl_transfer
    timeout
  File "/usr/local/lib/python2.7/site-packages/usb/backend/libusb0.py", line 380, in _check
    raise USBError(errmsg, ret)
usb.core.USBError: [Errno None] error sending control message: Connection timed out

To resolve this I needed to update the self.timeout value on line 60 to something higher than 100. An extended timeout may have been needed because my Linux distro is running under a VM within Windows so it might well take the VM longer to talk to the USB port devices (I'm not sure) but after a few unsuccessful attempts at slightly larger values I eventually found that a value of 2000 worked successfully under my setup.

[Rufus]

The machine was working yesterday because you were stealing FTDI drivers. The machine is not working today because FTDI stopped you stealing their drivers.

"Stealing" is theft, the taking of property with intent to permanently deprive the owner.  Using a software driver without consent of the copyright holder is more akin to pillage and murder on the high seas, so we prefer to call it "piracy" or "terrorism".

Most people do not demand that FTDI's precious drivers work with counterfeit chips, just that they not intentionally destroy them.

Yawn - I shall continue to call unlicensed use of software stealing for as long as other call modifying a USB device PID destroying.