You can connect it to a different or the same computer with an legacy driver with PID 0000 instead of PID xxxx this I believe is proven to work. You can either edit the .inf file, or force the driver to install in device manager, or use a GUI tool to do it, or use regedit, or use CLI tools, or use a linux tool, or... (So many things still work notice that the list is a massive list of options you have all of which are in my opinion a joke, my printer doesn't automatically install drivers and I have to use the force driver method in normal install anyways)
You can roll back the driver, you can force it to work with it even if the IDs don't match. You can as shown before connected to a different os and use completely FOSS tools to not only correct but even prevent it from being modified again afterwards.
FTDI did a bad/mean/evil DRM ala HDCP style detection and modification but the workaround/bypass is a joke.
If you need help fixing this particular issue I can help for free via remote desktop. (After I finish some work stuff of course)
Hence two writes, and the EEPROM retains its original values. Objections?
QuoteHence two writes, and the EEPROM retains its original values. Objections?Yes,objections : interrupting the sequence leaves the device with an incorrect checksum (probably bricked)
You can connect it to a different or the same computer with an legacy driver with PID 0000 instead of PID xxxx this I believe is proven to work. You can either edit the .inf file, or force the driver to install in device manager, or use a GUI tool to do it, or use regedit, or use CLI tools, or use a linux tool, or... (So many things still work notice that the list is a massive list of options you have all of which are in my opinion a joke, my printer doesn't automatically install drivers and I have to use the force driver method in normal install anyways)
You can roll back the driver, you can force it to work with it even if the IDs don't match. You can as shown before connected to a different os and use completely FOSS tools to not only correct but even prevent it from being modified again afterwards.
FTDI did a bad/mean/evil DRM ala HDCP style detection and modification but the workaround/bypass is a joke.
If you need help fixing this particular issue I can help for free via remote desktop. (After I finish some work stuff of course)
In all the above cases, what a210210200 means by "you" is the experimenter, hacker, hobbyist, programmer, developer, engineer, etc.
Alas, virtually no END USER of a commercial product who has the misfortune of using an appliance assembled with counterfeit chip will be in a position to mitigate the damage caused by FTDI.
It appears that FTDI has rather "queered the pitch" for USB to serial in general and "fouled their own nest" in particular.
If the detection is to write the PID, then check it is 0000 and then rewrite it to what it was, is that not also unauthorized modification of a users product without permission, this time twice, or many more times each time it is plugged in?
Don't forget that EEPROM wears out...
You will exceed the insertion spec of your USB connector before you wear out the EEPROM (provided the clone uses a real eeprom, some have suggested it could be some sort of OTP ROM by looking at the die shots? I'm no expert)
If its real eeprom it can be written a few million times.
If it is flash it can be written 100000 times.
If it is something else, who knows
If the detection is to write the PID, then check it is 0000 and then rewrite it to what it was, is that not also unauthorized modification of a users product without permission, this time twice, or many more times each time it is plugged in?
Don't forget that EEPROM wears out...
You will exceed the insertion spec of your USB connector before you wear out the EEPROM (provided the clone uses a real eeprom, some have suggested it could be some sort of OTP ROM by looking at the die shots? I'm no expert)
Not necessarily. Rebooting your PC with the device always attached will make the driver write the EEPROM every time.If its real eeprom it can be written a few million times.
If it is flash it can be written 100000 times.
If it is something else, who knows
Normal EEPROM would be around one to ten millions.
If it's Flash, i know some uC that only guaranteed one hundred times (a couple of PIC18FXJXX? can't remember the exact model). Others go up to ten to hundred thousands.
QuoteHence two writes, and the EEPROM retains its original values. Objections?Yes,objections : interrupting the sequence leaves the device with an incorrect checksum (probably bricked)
I wonder if the chips respond differently to read requests on odd and even addresses. I know that a similar means of detecting a clone is used in another product. In this case you don't need to do writes at all, resulting in identification without bricking.
If the detection is to write the PID, then check it is 0000 and then rewrite it to what it was, is that not also unauthorized modification of a users product without permission, this time twice, or many more times each time it is plugged in?
Don't forget that EEPROM wears out...
You will exceed the insertion spec of your USB connector before you wear out the EEPROM (provided the clone uses a real eeprom, some have suggested it could be some sort of OTP ROM by looking at the die shots? I'm no expert)
Not necessarily. Rebooting your PC with the device always attached will make the driver write the EEPROM every time.
I had probably 1000's of students all of them are certainly end users of an FTDI products (a box of USB>RS-232 adapter cables counts as a commercial product no?) know how to do something as simple as that, students that get development boards know even more about them and I don't see how this is so hard. (The com port numbers get screwy sometimes or some student made software had a dumb limitation of only allowing users to select 10 com port numbers when they could have auto-detected. but anyways people figured out how to fix that easily its just point click interface)
No user who doesn't know how to use google would be unaware of how to fix it. Also need help ask someone it works a lot of the time and for this problem most people should know how to figure it out.
No user who doesn't know how to use google would be unaware of how to fix it. Also need help ask someone it works a lot of the time and for this problem most people should know how to figure it out.
I had probably 1000's of students all of them are certainly end users of an FTDI products (a box of USB>RS-232 adapter cables counts as a commercial product no?) know how to do something as simple as that, students that get development boards know even more about them and I don't see how this is so hard. (The com port numbers get screwy sometimes or some student made software had a dumb limitation of only allowing users to select 10 com port numbers when they could have auto-detected. but anyways people figured out how to fix that easily its just point click interface)
No user who doesn't know how to use google would be unaware of how to fix it. Also need help ask someone it works a lot of the time and for this problem most people should know how to figure it out.Wow, you don't have much (any?) experience with Dumb End Users of appliances. They make your "1000's of students" look like geniuses. It might take you 30 minutes just to get the USB cable plugged back into the right place after the janitor accidentally pulled it out last night. (And that is after 10 minutes to identify which is the USB cable.)
No user who doesn't know how to use google would be unaware of how to fix it. Also need help ask someone it works a lot of the time and for this problem most people should know how to figure it out.
Really? Are you serious? Look around you and open your eyes. There are lots of everyday users who are very competent using their devices, but don't need to know (or wish to know) the insides and how it operates.
Let's not forget our customers/users/family members who didn't ask for their devices to be bricked. How much time has been wasted by the end user because the device doesn't work today, but used to work a few weeks ago.
How many devices have ended up on the trash heap because they just stopped working?
Just because members of this forum have an interest (and ability) in electronics/computing, we should never forget our customers/users/family members may not have that same ability/talent.
FTDI has the right to protect their IP, no argument there. However, a good corporate citizen that respects the final customer (the end user), would have merely notified of the suspect device - "Not an FTDI device - please contact your supplier/manufacturer for the correct driver."
FTDI does NOT have the right to vandalise my device.
Ozwolf
99% of the end users are not technical people.
They don't know what FTDI is or means.
They would not know to use that as a search term.
Most of them don't know jargon such as 'bricked' and so would not know where to start.
I 100% agree with ozwolf and Richard.
99% of the end users are not technical people.
They don't know what FTDI is or means.
They would not know to use that as a search term.
Most of them don't know jargon such as 'bricked' and so would not know where to start.
I 100% agree with ozwolf and Richard.
99% of the end users are not technical people.
They don't know what FTDI is or means.
They would not know to use that as a search term.
Most of them don't know jargon such as 'bricked' and so would not know where to start.
I 100% agree with ozwolf and Richard.
Also this entire point is moot, I think we all agree FTDI can have the driver refuse to work with a fake as long as it doesn't mess around with the PID. In the end a technically inclined user is still going to be required.
What we are talking about here is bypassing FTDI DRM which obviously should require a modicum of skill. (Like enough to install a printer with garbage drivers, very common)
99% is a totally inaccurate statement on my part and of course I can not prove it.
The point I am trying to make is that there will be a fairly large percentage of people who really only know how to use facebook and ebay, have purchased a widget from ebay that worked a couple of weeks ago and then suddenly does not.
They may choose to junk it.
They may choose to 'phone a friend'.
A lot of them don't have the skills to open and view the driver details, nor understand what it means.
Also this entire point is moot, I think we all agree FTDI can have the driver refuse to work with a fake as long as it doesn't mess around with the PID. In the end a technically inclined user is still going to be required.
What we are talking about here is bypassing FTDI DRM which obviously should require a modicum of skill. (Like enough to install a printer with garbage drivers, very common)
Agreed.
Oh, and printers are evil... Don't get me started on that subject...
i just saw this ... is it that easy to unbrick?
99% is a totally inaccurate statement on my part and of course I can not prove it.
The point I am trying to make is that there will be a fairly large percentage of people who really only know how to use facebook and ebay, have purchased a widget from ebay that worked a couple of weeks ago and then suddenly does not.
They may choose to junk it.
They may choose to 'phone a friend'.
A lot of them don't have the skills to open and view the driver details, nor understand what it means.
99% is a totally inaccurate statement on my part and of course I can not prove it.
The point I am trying to make is that there will be a fairly large percentage of people who really only know how to use facebook and ebay, have purchased a widget from ebay that worked a couple of weeks ago and then suddenly does not.
They may choose to junk it.
They may choose to 'phone a friend'.
A lot of them don't have the skills to open and view the driver details, nor understand what it means.
I agree 99% is probably a little low, should be 99.99943%.
Wow, that philosophy wouldn't last two minutes in a proper customer-support organization. How astonishingly clueless about the end-user support world.
Wow, that philosophy wouldn't last two minutes in a proper customer-support organization. How astonishingly clueless about the end-user support world.