Too many USB ports?
Tracy Allen
Posts: 6,664
We have to program several hundred Propeller chips each with its own FT231X USB port. This on a PC running Windows XP, 7 or 8. It goes along smoothly for some time, but then suddenly no joy. New ones won't program.
Upon looking at device manager/USB/hidden devices, the list goes on and on, all not present. A couple hundred, as each new FT231 spawns a new one.
Could that be a problem and if so what to do about it? We can delete them but only one at a time, seemingly. Restarts and reloading the driver doesn't help.
For now we're using a Mac to flash the eeproms, because the PCs seem to be brain dead for the purpose.
Upon looking at device manager/USB/hidden devices, the list goes on and on, all not present. A couple hundred, as each new FT231 spawns a new one.
Could that be a problem and if so what to do about it? We can delete them but only one at a time, seemingly. Restarts and reloading the driver doesn't help.
For now we're using a Mac to flash the eeproms, because the PCs seem to be brain dead for the purpose.
Comments
This also happens with FT232RL (propplugs) so you can have multiple propplugs connected at the same time, and each can be individually addressed.
I cannot help you overcome this problem. Have you tried google?
Some wrote a macro or a bat file in the last two weeks to take care of it, but I can not find it right now.
Will check in the morning.
In a non-gui OS that is easy to fix though. Just bind the device vendor and and product identities to a particular device name by hacking a udev rules file. Then whenever you plug in the same USB/Serial adapter it appears as the same serial device name.
In a GUI OS it's harder of course but I believe possible: http://www.cypress.com/knowledge-base-article/binding-drivers-usb-serial-bridge-controller-custom-vidpid-kba92528 TL;DR
See if this helps:
http://forums.parallax.com/discussion/162301/removing-old-hidden-com-ports-in-windows
I can delete ports one by one, but it is a painstaking process. The highest number is 256. Is that a magic number?
There is a correspondingly long list under the Universal Serial Bus Controllers heading. "Currently this hardware device is not connected to the computer (Code 45). To fix the problem, reconnect this hardware device to the computer." Duh!
It seems like a macro would be a great help.
-Phil
On 'ix-based systems (Linux, Mac OS X, Unix), you indeed get a different device name, but a good GUI or command-line program should be able to discern a newly plugged-in device and either give the user an opportunity to choose or automagically pick the 'newest device' for uploading. The program could store device names and test against the list of known devices when a new device is plugged-in.
EDIT: There's an open-source variant of such a program inside SimpleIDE sources
On Windows, it appears that some indeterminate number of COM ports becomes unmanageable for app use (at least that's what I understand from reading posts on this forum)... So, some form of reset of devices is required.
dgately
Phil, One can indeed set the serial number on the FT231, using FT_PROG. Interesting idea to make them all the same. I'm not convinced I would want to do that, though. On the Mac, I like seeing the serial number appear in drop-down lists, especially in the scenario where more than one Prop is connected to the computer. What would happen if all the serial numbers are the same, is it cosmetic or substantive confusion?
for example HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\FTDIBUS\VID_0403+PID_6001+6&257edd14&0&4\0000\Device Parameters PortName=COM8
There will also be a related registry value under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB
for example: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_0403&PID_6001
The attached zip file contains an HTML application file called Enumports.hta which uses vbscript to enumerate ports - it also works on WIN7
It may help you find and delete the registry entries freeing up COM ports
One could use the same computer with a Linux Live CD to achieve the task and not have to deal with Microsoft's approach to ports. I suspect that a copy of Puppy Linux might make everything get done with less complexity.
There are situations where using Linux booted from CD or USB memory stick is an easier way to deploy a special task on your 'normally Windows' computer. People have been doing this for 3D printing for quite some time now. When you aren't doing 3D printing, the computer just boots from hard disk as a normal Windows machine.
I wouldn't call it clutter - those entries are what allows a device to use the same COM port each time it is connected.
NOTE: The enumports.hta I attached let's you add the descriptions like you see in the image. Clicking a description opens a dialog box which lets you store a description if you first manually add a registry key of HKEY_CURRENT_USER\Software\FTDI Devices
I poke around a lot in the workings of Windows 7. I have to admit, the more I find out about the registry, the more bizarre it seems. However, I'm almost certain there's nothing in there that should cause Linux users to go nuts.
-Tor
Why do so many developers make their software a pain to use by relying on the registry? I have lots of programs that run in "portable" mode. They do not need to be "installed" and don't reside on the C drive. I can completely reinstall Windows and they will continue to work properly.
Just to add to the confusion Windows seems to have an "etc" directory as well now a days.
"You can manage COM port numbering by uninstalling the drivers , running our Set Ignore Serial Number application, followed by reinstalling the drivers." (links provided) I'll give it a try and report back.
Interesting - found some info here: http://www.ftdichip.com/Support/Knowledgebase/index.html?ignorehardwareserialnumber.htm
I sometimes have more than one FTDI device connected at a time - not sure how that would work if they try to use the same COM port...
There are Microsoft tools for uninstalling device driver packages:
https://msdn.microsoft.com/en-us/library/windows/hardware/ff553525(v=vs.85).aspx
I usually just delete the files and registry entries manually rather than installing any of development tools mentioned in the above link.
I am attacking another html application which gives detailed info on installed drivers OEM and others as well
On a Win 7 machine their uninstall utility did in fact exorcise the ghosts in the registry listings for serial ports and usb controllers.
http://www.ftdichip.com/Support/Utilities.htm#CDMUninstaller
VID=0402, PID=blank
The nice thing is that it did it all at once, whereas doing it manually is verrrry slow
Then their IgnoreSerialNumber utility + reinstall of the vcp/d2xx driver did in fact make it so that new devices no longer materialize new ghosts.
http://www.ftdichip.com/Support/Utilities/IgnoreSerialNo.exe
http://www.ftdichip.com/Drivers/CDM/CDM v2.10.00 WHQL Certified.exe
The uninstall also worked on a Win8 machine, but so far it refuses to install IgnoreSerialNumber. The driver does reinstall though, with a fresh slate for ports, but each new device continues to add an entry for a port a USB controller.
One thing Cameron said was to avoid USB 3.0 ports. Not sure why.
Plug-in: P4,P5
Plug-in: P4,P5,P6
Unplug P5: P4,P6
Plug-in: P4,P5,P6
Thanks,
-Phil
unplug 5: 4,6
replug the same one, 4,5,6
but plug a new one, 4,6,7
There are no hidden devices shown on the ports or usb controllers list though.
The settings hold through resets. So, I have to wonder what is going to happen as the port number increases up into the hundreds? The hidden ghosts have been exorcised from the device manager, but all that history has to be stored somewhere.
Oddly, the FT232RL is a bit different. Each new one connected takes the lowest number previously used by an FT232RL and does not spawn a new one unless all the previous ones are currently in use. (prop plug, stamp/usb, my own FT232RL). That would seem to make more sense.
I haven't tried it yet with non-FTDI serial devices.
while the older ones are VID 0403 PID 6001(FT232R according to the IgnoreSerialNo.exe)
The old Parallax oscilloscope has it's own...
But if it's ignoring serial numbers, how does it know that the new one is a new one? I should think it would just fill in the gap that was left by the old one. Doesn't this put you right back where you started?
-Phil
While you are sitting there waiting for your Windows to start, you might ponder that most of the delay is likely due to having the Registry verify the integrity of the OS at start-up.
I suppose there are situations where a computer system might need to track the serial numbers of FTDI USB devices, but for most of us.. it is just a pile of trivial data -- bloat or clutter. The feature certainly go in the way of the OPs work.
It is almost as if NSA is trying to put a serial number on every bit of hardware that might assist breaking into a computer. Just use your BIOS to turn off a bootable USB device, or sell computers with a BIOS that won't support remote loading of OSes.
Being able to tie a particular USB/serial adapter to a particular device name "/dev/ttyUSB0" or "COM1:" or whatever is very useful if you have a bunch of devices and you are plugging them in and out now and then. It allows that you don't have to always plug the same device into the same USB port on your machine. It means you don't have to always go in and find the device name in your applications every time you use them.
Plug and play you know.
But it seems there is then the opposite problem. You may sequentially use a lot of different instances of a similar device. Which is the subject of this thread "We have to program several hundred Propeller chips each with its own FT231X USB port". In this case all those different devices would be better coming up as the same device name /dev/USB0" or "COM1:" or whatever.
Plug and pray
This is all easy to achieve under Linux with it's udev rules. I'm told it's much easier to do these things with a GUI based OS though
The Registry is a database consisting of several files, one of which actually only exists in memory. The Registry not an executable program, it cannot verify anything. It is used mostly to store settings for the the operating system and software used by the operating system. Its use by non-operating system software and applications is optional for the most part.