Arduino FTDI driver issue with Windows update

I can't relate this thread to the problem aluded to in your earlier post. The Prolific thread is about them coding their driver to not work with the fake 2303 chips. That is not the same as ruining them and it doesn't make a problem for people with legitimate 2303 chips.

Is this just your observation or have others seen this as well? I'd be very surprised if it is true. It would be hard for TI to sell product to anyone with a demo board that only works for 10 minutes.

BTW, I have my manufacturers mixed up. The $4 board is from Cypress.

They still stop working.

It's my observation. I searched on the topic and couldn't confirm or refute it, I found no evidence that anyone had used the USB connection for extended periods.

I don't see how that is a problem with the driver supplier if that is a competing chip maker's chip. The dongles don't stop working, the driver stops supporting them. Prolific and FTDI are clearly free to not support other supplier's devices. It isn't the Prolific chips that have a problem, it is the fake devices that stop being supported with the Prolific driver. If you can find a driver from the maker of the dongle or the chip then your device will still work just fine unlike the chips that are bricked by the FTDI drivers.

Interesting. I will keep my eyes open for this one. I have one of the TI launchpads but have not used it much.

As the reality has shown, they are not "reverse engineered to work with the FTDI driver". They do not conform to the VID update procedure. :->

Bets regards, Piotr

Then how many bits does it have to have in order to be "ownable"? Is 128 bits enough? (most symmetric session keys) 1024? (RSA private key). HDCP master key?

You don't buy bits, but the promise that your bits are unique.

Best regards, Piotr

And that's the real issue. How is one going to prove that it has been done deliberately? Or if one can, then what then? Proactively ask "Judge, could you please debug my code in order to ensure that none of the non-conformant devices won't get broken?"

Best regards, Piotr

Depends on the situation. There may be a paper trail in the form of emails that shows that it was deliberate.

Remember, the issue is whether it was deliberate. If not, then the non-FTDI device owners have no redress, since FTDI certainly owed them no duty of care.

Sylvia.

Over in the eevblog forum, somebody used a USB protocol analyser to see what the driver was doing, and also disassembled part of the driver (yeah, quite possibly contrary to that licence "agreement" that they did not even see). When you understand exactly what FTDI did, which depends on a subtle difference between how their chip and the clone chip handle requests to write even and odd numbered 16 bit words to the EEPROM, you can come to no other conclusion than that it was done deliberately.