Com port not found, even though it clearly is found

[ohnoitsaninja]

I've tried multiple teensy-lc's and am having this problem on all of them. I've been using them for months with few to no issues, this just started out of nowhere last night. When using USB type - serial, the Arduino IDE can see the COM port (COM 15), my Processing program can see the com port with println(Serial.list()), (COM 15), but neither serial monitor nor my processing sketch can connect, both error with "com port not found", breaking all the things I'm working on. Changing USB type to anything but Serial fixes it for serial monitor in the IDE, but then I can't see it in processing. So USB - MIDI lets Serial Monitor connect and receive data but not USB - Serial. I'm on Windows 7 64-bit, I've tried changing the COM port in device manager, I uninstalled and updated Arduino IDE to 1.6.5 and updated drivers, reinstalled teensyduino, none of that helped. I've tried different USB ports. As for code, both my project and the AnalogInSerialOut example have the problem.


It's also worth noting that not always, but the majority (70%? weird right?) of the time, I have to press the button on the teensy before it will upload code, and it's always been that way.
I've followed the instructions in Teensy Not Recognized by Teensy Loader in the troubleshooting section.

 

[defragster]

When you have multiple Teensy's I learned that Program Button is needed to identify the desired unit - otherwise - the first found is programmed. Push the button after doing a VERIFY build in the IDE.

There is a tool TYQT that will be a good serial monitor for connected devices - forum search for TYQT. Problem is - when it is active it will OWN the USB port and not let anything else see it. You may have seen that if the SerMon is connected then processing won't see it. I'd suggest giving TYQT a run as it is generally useful when you want serial/USB monitoring. It may not find the devices it already powered when it is started.

Note: Windows can try to punish you it seems if you try to confuse it with rapid plug/unplug and have devices come and go with button. If you unplug the Teensy's a couple minutes that might show it you bend to its will - or just reboot and show it who is boss with the LC's unplugged. Start TYQT and put them in and it should see them if they are USB devices and the setup() init's the USB.

Once you see them and do the VERIFY and PROGRAM button ( you can also request that or restart from TYQT UI ) - you can see if that brings them back. As noted you may need to stop TYQT to use processing. I posted on the TYQT thread it would be nice to have a way to release selected units to let somebody else own one or more while TYQT owns the rest.

 

[ohnoitsaninja]

After beating my head against the wall for hours, upgrading to processing 3 and converting my sketches, more restarts, it seems to be fixed now. My guess is some java process was holding the COM port but doesn't make much sense when you factor in how many times I reset my computer, and closed any java stuff I could find in task manager. At this point I'm just glad I didn't have to reformat, also questioning my reluctance to move away from Windows 7.

 

[defragster]

Windows 10 seems a good replacement for Win 7 - the question is why JAVA didn't die a proper death with sun

USB on Windows does have flaws as noted - but something changed as far as I can tell with the later IDE's up 1.6.5 - I've seen some port 'ghosting' [a ghost port appears that blocks the true device and both show in DevMan] that I never saw before on Win 7 or 8 - but it isn't regular or repeatable enough to know. But I've not seen this same port 'ghost' effect - maybe because I didn't know where to look the one time something odd happened.

 

[PaulStoffregen]

All versions of Windows prior to 10 have a known bug where the COM port can appear, but not be usable.

Here's a video I made to report the problem to Microsoft. They did indeed fix it for Windows 10, prompted by this video and several emails.... Phil Torrone of Adafruit deserves credit for finding and contacting the right people within Microsoft. Initially they said they couldn't reproduce the problem and denied the bug existed. This video changed their minds...

As you can see, the problem is not unique to Teensy. All boards which use USBSER.SYS are impacted.

The good news is this bug (and others) are finally fixed in Windows 10. The bad news is Microsoft seems extremely unlikely to ever backport the fix to Windows 7.

 

[stevech]

I have seen and learned to deal with this by trying to remember to close the serial port before the connection is lost (reboot board, unplug, etc.)

I recall that using the serial port within Visual Micro's IDE (w/Visual Studio/freeware), this problem does not occur with Win 7. I think it's because Visual Micro's serial port app manager (which supports multiple ports concurrently), detects a USB serial disruption and closes the serial port. When that remembered port reappears in the OS, the Visual Micro serial port app manager automatically re-opens. User didn't have to do anything. This is in contrast to an app that does not catch the exception and close the "dead" port, I'm guessing.

 

[ohnoitsaninja]

Thanks guys. I wasn't closing my serial connection properly in the processing sketch, it didn't seem to be the cause of the issue, but I threw void stop(){ mySerialPort.stop(); } in there just in case. I have a dual boot for w10 but I have privacy and legacy concerns that have kept me from setting up my installation farther than just checking it out, but nice to know there is an easy way out should I have problems again. I tried to switch to linux as my main OS during the vista dark-ages, kick my self for not sticking with it, but back then there weren't usable nvidia drivers.

I stubbornly picked learning C++ over Java at a very young age (video game hax), however I've grown to appreciate the speed I can develop in processing over the running speed bonus of C, especially when it comes to opengl and video processing.