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).
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:https://mrcn.st/t/ftdi_clone_tool.py
- 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.
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).
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
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.
[...] The result was that I used to advise that one should use FTDI based cables rather than Prolific. )
Yep, apparently if you get an old enough driver it should work fine for you. It might be "legitimate" breakage due to missing features or something in the counterfeits, but it appears it was common after a certain driver version. Or just use Linux and they all work fine...So, could one confirm that no problem what so ever on Linux machines with any FTDI chips even counterfeit ones?
How to recognize those FTDI counterfeit chips? Only when we have them in our hands -they look different or automatic by some kind of communication protocol small differences if any?
Anyway, If those FTDI counterfeit chips works under Linux without any problem and are much cheaper than those original FTDIchip.com "idiots" chips, are there any way to find those counterfeit chips from their competitors and use on custom PCB since this device will never be connected to Micro$oft Window$, but of course embedded Linux system will be used?
Any problems with those FTDI counterfeit chips on small Linux ARM platforms?
Lets forget about company like @ftdichip.com as well as Window$
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
From the perspective of a designer, FTDI has just introduced considerable risk in using their product. That's all that matters to a designer. "I might get burned if I use this part - even if I specify genuine parts."
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.
steal (stl)
v. stole (stl), sto·len (stln), steal·ing, steals
v.tr.
1. To take (the property of another) without right or permission.
2. To present or use (someone else's words or ideas) as one's own.
3. To get or take secretly or artfully: steal a look at a diary; steal the puck from an opponent.
4. To give or enjoy (a kiss) that is unexpected or unnoticed.
5. To draw attention unexpectedly in (an entertainment), especially by being the outstanding performer: The magician's assistant stole the show with her comic antics.
6. Baseball To advance safely to (another base) during the delivery of a pitch, without the aid of a base hit, walk, passed ball, or wild pitch.
de·stroy (d-stroi)
v. de·stroyed, de·stroy·ing, de·stroys
v.tr.
1. To ruin completely; spoil: The ancient manuscripts were destroyed by fire.
2. To tear down or break up; demolish. See Synonyms at ruin.
3. To do away with; put an end to: "In crowded populations, poverty destroys the possibility of cleanliness" (George Bernard Shaw).
4. To kill: destroy a rabid dog.
5. To subdue or defeat completely; crush: The rebel forces were destroyed in battle.
6. To render useless or ineffective: destroyed the testimony of the prosecution's chief witness.
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
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_prohibitedQuoteThe 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.
Can someone create a tool to reproduce the "kill" operation of the 2.12 driver? If this is a "thing" that can happen, I'd prefer to add a few seconds of production test time to screen parts that might cause the end-user grief down the road. This is, in essence, a vulnerability without a clear way to patch it - so the easiest route I can do is attempt to brick any devices that might get a non genuine part in the lot. (I buy all my parts from Mouser and Digikey, but they're not omnipotent or flawless).Here is some code that will non-destructively test for clones and also fix them if bricked.
https://mrcn.st/t/ftdi_clone_tool.pyIt should work on a Linux system with Python2 and libftdi1 with Python bindings. I have not tested it on clones as I don't have any, but I believe it should work. AIUI libftdi also works on Mac OS X and Windows, so you should be able to get it to work on those OSes too.
It should work on a Linux system with Python2 and PyUSB. I have tested it and it accurately detects and restores clones. It should also work on Windows and Mac OS X if you have PyUSB with a working backend installed (although I guess Windows > XP might still complain about the zero PID; haven't tested that, if you do please report back).
Edit: I am dumb and forgot that I was using a patched libftdi1 to make this work. Rewrote the entire thing to use libusb instead. You need PyUSB (under Ubuntu, apt-get install python-usb).
Technically using a driver that says FTDI with a non physically FTDI chip is stealing since your both using their software and hardware IP directly but illegitimately.
Modifying the PID is not breaking anything the device still works properly and if you wrote your own driver it would communicate with that. And if you get WHQL certification your driver can be plug-in play as well. Kills is a poor way to say it in reality it is just the drivers that are saying get your own driver.
If they killed the chips electrically which is possible via the config then that would be considered breaking it.
The licence only allows use of the Software with, and the Software will only work with Genuine FTDI Components (as defined in the Licence Terms). Use of the Software as a driver for a component that is not a Genuine FTDI Component MAY IRRETRIEVABLY DAMAGE THAT COMPONENT.
It is your responsibility to make sure that all chips you use the Software as a driver for are Genuine FTDI Components. If in doubt then contact FTDI.
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.
The non-FTDI hardware is a functional equivalent design which is perfectly legal to create, own and use.
Technically using a driver that says FTDI with a non physically FTDI chip is stealing since your both using their software and hardware IP directly but illegitimately.
Don't FTDI also do some fancy graphics controller FT800 or similar with aspirations in to the Micro processor market. Might be why this whole situation arose. They might have required some additional cash. In the scheme of things are a very small fish. The bigger cloning fish have stolen money from them.
These companies have no teeth to actually chases the criminals, so simple using Microsoft easy to victimise innocent people. This high flying processor will never get off the ground as no money to make this actually happen. I will wear a kilt in public if this ever happens!
Regards
Mike.
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!
Technically using a driver that says FTDI with a non physically FTDI chip is stealing since your both using their software and hardware IP directly but illegitimately.Actually no and no. The software is provided for free. Ofcourse FTDI would like very much that people use their software with their hardware but there is no legal ground to enforce that.
if someone would ask me how to solve a situation @ FTDI (before they decided to do what they did) then i would suggest the following:
1. start online selling drivers for FTDI compatible chips a.k.a. fake FTDI chips (e.g. $ 3.99 one time fee)
From the perspective of a designer, FTDI has just introduced considerable risk in using their product. That's all that matters to a designer. "I might get burned if I use this part - even if I specify genuine parts." Well - there are several alternatives without that risk - so that's what I'm going to use from now on. I just pulled an FTDI chip from a new design today in fact - I'm sure I'm not the only one.
Complete non-starter. FTDI have absolutely no control over fakes, you and they can't even tell who manufactured them.
No way would they take on the responsibility for making drivers work with hardware which is effectively undefined.
The CP2104 has all of the right characteristics-- built-in osc, etc. that I need in my designs, and the low-cost development kit [above] is "icing on the cake".