This afternoon I was happily working away writing code and occasionally uploading it a few Moteinos. I was just getting used to the little “beep boop” noises Windows makes every time you plug/unplug a new USB device, when they stopped and my upload failed. Rather confused, I checked the available COM ports using the Arduino IDE. There weren’t any, but as many people can attest, this isn’t terribly uncommon. I quickly checked using device manager to see if the problem was the Arduino IDE getting itself in a bit of a mess. The device manager showed no COM ports. It did, however, show in the “Other Devices” category an “FT232R UART USB” device. I have to admit to being rather puzzled as this is usually what happens when you don’t have the driver installed.
I decided to go with the tried and tested “unplug it and plug it back in again” routine. Windows played it’s little tune, the Arduino IDE did some thinking but no COM port appeared. Tried it in a different USB socket, still no luck. Time for plan B, assume it’s broken. I went digging in my electronics box and found another 3 FTDIs to use instead. 15 minutes of plugging, unplugging, testing and puzzling and I now had 4 FTDIs that didn’t seem to work. At this point, I must admit, that I was getting quite cross, but I plowed ahead anyway as I really wanted to finish work for the day. Suspecting that Windows 8 may have gotten confused or broken itself somehow, I tried the FTDIs on my MacBook and a Windows 7 machine. Still no luck.
By now I had resigned myself to the fact that I’d probably broken 4 FTDIs, but I thought I’d re install the drivers just in case that helped. When that failed to make any dent in the problem I attempted a bit of Google-fu. I did find the odd hint, but the most helpful result was about a program called “usbview”. Made by the makers of the FTDI IC, it shows what’s connected to each USB port in a bit more detail. In this case it provided the key to the whole problem. When I examined an FTDI using usbview I discovered that while the VID (Vendor ID) was correct, “0403”, the PID (Product ID) was not. For the FTDI I had, the PID should have been “6001”, it wasn’t though, it was “0000”. Why would this make any difference you may ask? Well the FTDI driver needs to be able to recognize FTDI devices when they are plugged in and it uses the VID and PID to do so. The driver didn’t understand how to talk to product “0000”. Some more Googling, didn’t turn up people with the same problem but it did result in a few posts from people who wanted to change the PID of their FTDI for various reasons.
The program they had used was called “FT_prog” and again, was available from FTDI themselves. Installing FT_prog was very simple and required nothing other than clicking “Next” a few times. However when I tried to scan for devices, no luck just a dialog box saying that the devices may still be enumerating, try again later. So then I actually went and read the documentation. The readme for FT_prog states that the D2XX drivers needed to be installed, so I dutifully went and downloaded them from FTDI. Not so fast though, the PID of the FTDIs I’m using still doesn’t match what the driver expects, “6001”. So a bit of editing was required. In the driver download, there is a file called “ftdibus.inf”. Inside that file are a bunch of references to VID 0403 and PID 6001. So I replaced all instances of 6001 with 0000, saved it and tried to install the newly modified driver. But would Windows 8 let me install them? Nope, the security hash no longer matched (obviously as I’d changed the file) and Windows 8 is not a fan of such things. To install unsigned drivers you need to boot into a special mode…. I just decided to install the modified drivers on my Windows 7 desktop instead. If you really need to though, there are plenty of guides detailing how to force Windows 8 to let you install unsigned drivers. Now that the drivers were installed, FT_prog could find the attached FTDI device.
From here, it was all plain sailing really. I used FT_prog to rewrite the PID to 6001, which was simple and quick. I could then test the FTDI on my MacBook (I wasn’t going to connect it to my Windows laptop again!) and tada, it worked. In about 5 minutes I “fixed” all of my FTDIs and managed to finish my work for the day using my MacBook. How did it even happen in the first place? Absolutely no idea, I don’t know if it’s the fault of Windows, the Windows FTDI driver or the color of my office walls. For the moment I’m steering clear of using my FTDIs with Windows, which is a bit silly as they worked fine together for years, but I don’t feel like repeating this experience again.
For anyone in a similar position, here are some links:
- Both usbview and FT_prog are available from: http://www.ftdichip.com/Support/Utilities.htm
- FT_prog readme: http://www.ftdichip.com/Support/Utilities/FT_PROG_README.TXT
- D2XX drivers: http://www.ftdichip.com/Drivers/D2XX.htm