TL;DR: FTDI recently added a new driver to Windows update that detects counterfeit chips and bricks them by reprogramming the device's USB PID to 0000! This is exactly what has happened to both my Gamebuinos, as I've already reported:
All is not lost entirely, it is apparently possible to run the FTDI config utility under XP to reset the PID back to what it should be but if you ever run the new driver it will brick the chip again.
I know there are minors on this forum so I'll keep my language in tow but this is one of the most astonishing stunts I've ever seen a company pull. Punishing unknowing consumers for what is a manufacturing IP issue is incredibly unethical, and while I understand their need to curb what is a very serious problem I hope this backfires on them big time. This is yet another reason to do what the Arduino guys did, drop FTDI altogether and replace it with alternatives such as ATMega chips that have the added benefit of being easily reprogrammed as other device types.
This is what I suspected (see Lunar Lander thread) right after pin 26 no ground had been eliminated. Myndale's observation of PID and VID actually reprogrammed to zero was news to me as well. I'm sorry to say, but this can become a major issue.
Ok, I've been scouring threads all over the net about this and I was able to rescue both my devices under Win8.1 (i.e. without resorting to the XP config hack) by following the instructions on this page:
jonnection wrote:Myndale's observation of PID and VID actually reprogrammed to zero was news to me as well.
I knew from the data sheet that the PID and VID were stored in the FTDI chip's EEPROM but it didn't make sense that one would reset and not the other. I did what a few other people did and tried changing the INF file to match but it didn't work. The failure of both devices at the same time had me starting to seriously suspect that a Windows update was to blame but the fact they also didn't work on a freshly-formatted XP machine caused me to eventually conclude that there must have been something wrong with the devices themselves. The idea that the FTDI chips might be counterfeit and that a driver update had deliberately bricked them simply didn't occur to me.
This is all very reminiscent of the infamous DirecTV Black Saturday Hack, which is well worth the read if you're interested in this sort of thing. That case was completely different to this one though due to the fact that every single consumer who owned one of those cards knew it and were deliberately breaking the law.
The comments section in that HAD article also has someone listing the same chip reference (1403-C GN480661) who's also having problems, I saw one of his posts in another forum and he too has concluded those chips are fakes.
This has some pretty serious implications for crowd-funded projects like Gamebuino. There's absolutely no way for people like Rodot to guarantee that every single chip in a device sent off for manufacturing overseas is going to be genuine, now they have to worry about the IP holders not only disabling drivers but physically bricking devices that contain them? Not cool, not cool at all....
One more update from me....after installing the old driver I was able to run FT Prog (available on the FDTI Utilities page) to set the PID back to 6001. As far as I'm aware this should reset Gamebuino back to factory settings and re-enable it for use on other OS's as well. Specifically, run FT Prog, hit F5 (Devices -> Scan and Parse), go to the "USB Device Descriptor" section and set Product ID back to 6001; the "Custom VID/PID" drop-down should change to "FDTI Default". Hit Control-P (Devices -> Program) and everything should be back to normal.
I did actually manage to write a utility today that re-flashes the PID itself...Gamebuino worked fine for regular serial communication but sketches mysteriously wouldn't upload via the IDE. I suspect there are other flags the new driver nukes pertaining to the TXD/RXD etc that are needed to reset the device for programming.
Wow, that's really bad news. Thanks for all that information. Seem's that using an atmega instead of the FTDI chip in the next version of Gamebuino is a no brainer.
The problem is with the existing Gamebuino, we can't afford to have them all dying because of that... I guess I should write in bold in the instruction to install the old driver, or at least to block it's update in windows update. By the way do you know which version is installed by the Arduino IDE installer? Do you know the ID of the windows update to block?
Myndale, I followed that guide and now both of my 'buinos seem to work! I successfully uploaded an empty sketch to each one so I assume that means they're working. This should definitely go in the wiki, this clearly won't be the last case of this issue happening.
I have now read all the information on Eevblog and Hackaday & other sites and this really has been a weird episode. It appears the "killer driver" has now been removed from Windows Update.
I really don't know how Gamebuino could have avoided this. If I understood correctly, the SMD components on the PCB have been populated in China. No matter what Rodot would have specified, the supplier would have probably stuck fakes on in any case. There simply is no chain of trust in place in China. The counterfeit thing is totally out of hand in there (medicine, car parts, even bottled water). Whatever you buy at whatever price you won't know what you're getting.
I've gotten tired of FT232 already earlier precisely because I couldn't be sure whether I got fakes or not when ordering from Ebay. I really _tried_ to get real ones, but whether they are, difficult to say. Ordering from Digikey/Mouser has a 30€ shipping overhead so that was never an option.
I've been using Silicon Labs CP2012 converters for about a year and I've never had a single problem with them.
