Cannot get serial port working on a Teensy LC with Windows 8.1

Status
Not open for further replies.
P

PierceNichols

Member
The subject line pretty much says it all.

  • Host is running Windows 8.1
  • Device is a new Teensy LC purchased from Mouser
  • I can program it with the TeensyLoader 1.32 from Arduino 1.6.11
  • I have (apparently) successfully run the serial driver installer

However, when I load the EchoBoth example, no serial port appears. Instead, I get two 'Unknown Device' entries in my hardware list. Both claim that the device driver is not installed, Code 28. Searching the entire computer for a driver, re-running the installer, trying a different port, and rebooting all have no apparent effect.

Any ideas on what might be going wrong or what to try next? Clues for the clueless?
 
Install Teensyduino 1.33, and try again.

If brand new do a verify command instead of upload. When Teensyduino loads press program button, which should hopefully succeed and create a serial port.

Better yet maybe try new beta ide as it has some comm port installer fixes
 
I tried installing the latest version of Teensyduino with no effect. Windows still refuses to recognize the serial devices. The IDE version appears to be irrelevant, since I am specifically having trouble with the Teensy Windows serial driver.
 
PierceNichols said:
When I re-run the Teensyduino installer, it claims the driver is installed and refuses to update it.
Click to expand...

When you say re-run the installer, are you running 1.33 again... the version with the known issue of not updating drivers on Windows 8. That would be kinda pointless.

This issue is fixed in 1.34-beta1. So if you're re-running the installer to fix things, make sure you are doing so with 1.34-beta1.

https://forum.pjrc.com/threads/40860-Teensyduino-1-34-Beta-1-(ARM-Toolchain-Update)

When you do this, unplug the USB cable. Look for the "Update driver" button. After you click this button, it should have a message about the number of driver instances it found to update.
 
If you don't want to actually install the beta version, of course you can click Cancel after the driver step, long before the step where installation of everything else begins.
 
While this updates the serial driver, it does not fix the problem -- my computer still shows two Unknown Device entries and no serial ports.
 
Here is one line from a post linked :: make sure : Tools / USB Type: is "Serial"

There are other various things that won't apply - but skimming that might get you to an answer - but there is a sample sketch that gives good blink feedback. I intended to update it for USB echo but didn't yet.

Seems like Windows is confused about the device to show 'Unknown'. With that sketch as noted it should have a stable USB sketch - if it won't show up unplug - move to a new/different USB port as noted - plug it in and allow it time to do device driver detect and install - it might show up in 10 seconds could take 30+ to complete . . .
 
I don't get far enough for the IDE to be relevant -- my computer refuses to recognize the Teensy as a serial device. It classifies its serial endpoints as unknown devices within seconds of being plugged in.
 
Ok, so I dug out an older Win7 box to test with it, and I can get it working on that, but that's somewhat inconvenient. Here's what's really weird: when I load your test code on my Teensy LC on the Win7 box, it shows up as a serial port on my Win8.1 box. When I compile and load from the Win8.1 box, I don't get a serial port on either box. The only difference is that the Win7 box is running Teensy 1.33 and the Win8.1 box is on Teensy 1.34-beta 1. Thoughts?
 
Are you using the same cable on both systems? Not seeing it as Serial - correct - but you are seeing it as HID/Programming mode. Try the p#8 linked sketch? Seems like the Win 8.1 box isn't getting it code complete to run usable USB - that sketch will blink to show it working. If it blinks USB should come online - if not blinking it isn't getting to setup() well.
 
Something to consider but possibly not related...

I was playing with Teensy_Loader_CLI on a Raspberry Pi and uploaded the demo file blink_slow_Teensy36.hex from the Teensy_Loader_CLI package.

The USB device compiled into that demo file is not recognized as a serial device by either Linux or Windows 10.

It shows up in the Windows Device Manager as a "USB Composite Device" but does not show up in the Windows Device Manager as a "Serial COM Port".

You can hear the beep as it connects and the Device Manager flashes but you never see a serial port. It took some hunting to find it being enumerated as "USB Composite Device"

If I recompile my own test program using either Arduino 1.6.12 with Teensyduino 1.31 or Arduino 1.6.13 with Teensyduino 1.34 and make sure that both compilers have Tools-USB Type-"Serial" selected then the Teensy shows up as a serial port on either Linux or Windows 10.

If I again upload the demo file blink_slow_Teensy36.hex from the Teensy_Loader_CLI package then the Teensy reboots without a recognizable serial port under either OS.

This also broke the Teensy_Loader_CLI program's soft reset as a soft reset requires a serial port that it can use to set the baud rate to 134 baud and trigger the HalfKey Bootloader. No Serial Port --> No Soft Reset.

This behavior threw me for a loop until I realized what was going on and made sure to only upload hex files that contained a USB Type-"Serial" component.
 
Last edited:
drmartin said:
This behavior threw me for a loop until I realized what was going on and made sure to only upload hex files that contained a USB Type-"Serial" component.
Click to expand...

Yes, that is important: USB Type-"Serial" must be set BEFORE compiling! It is not used for programming.
PJRC's test programs (especially the one pre-loaded on Teensy) are normally compiled WITHOUT USB-Type-"Serial".
 
defragster said:
Here is one line from a post linked :: make sure : Tools / USB Type: is "Serial"
Click to expand...

Indeed - not sure if above note from post #8 was read/tried or not . . .

That post linked to these steps:
...
make sure : Tools / USB Type: is "Serial"
Open and compile a sketch like below in the IDE.
When it fails to find the Teensy and says press button.
On the unplugged Teensy press and hold the button
Plug the Teensy in - Pause - release the button.
Wait and watch Teensy Loader - perhaps open the : Help / Verbose Info window.

{ allow 5-10 seconds for Windows(other) to see the device if it programmed - if it is installing the driver don't interrupt it }
Click to expand...
 
I think that it's related and it's a common rookie mistake to not check for the desired USB mode in the Arduino IDE menu settings BEFORE compiling and uploading whatever sketch. How else should the Teensy then know that it has to show up as a serial device after reprogramming and reboot?

That is not by default because, depending on the use case, developers prefer their Teensy to show up as a bare USBHID device, a USB Joystick, or a MIDI device or what ever. BTW: The bare USBHID mode allows the use of Serial.print() in sketches and the serial monitor, too, no need to blow up forcibly your HEX file by including the serial driver just for debugging purposes.

drmartin said:
Something to consider but possibly not related...

I was playing with Teensy_Loader_CLI on a Raspberry Pi and uploaded the demo file blink_slow_Teensy36.hex from the Teensy_Loader_CLI package.

The USB device compiled into that demo file is not recognized as a serial device by either Linux or Windows 10.

It shows up in the Windows Device Manager as a "USB Composite Device" but does not show up in the Windows Device Manager as a "Serial COM Port".

You can hear the beep as it connects and the Device Manager flashes but you never see a serial port. It took some hunting to find it being enumerated as "USB Composite Device"

If I recompile my own test program using either Arduino 1.6.12 with Teensyduino 1.31 or Arduino 1.6.13 with Teensyduino 1.34 and make sure that both compilers have Tools-USB Type-"Serial" selected then the Teensy shows up as a serial port on either Linux or Windows 10.

If I again upload the demo file blink_slow_Teensy36.hex from the Teensy_Loader_CLI package then the Teensy reboots without a recognizable serial port under either OS.

This also broke the Teensy_Loader_CLI program's soft reset as a soft reset requires a serial port that it can use to set the baud rate to 134 baud and trigger the HalfKey Bootloader. No Serial Port --> No Soft Reset.

This behavior threw me for a loop until I realized what was going on and made sure to only upload hex files that contained a USB Type-"Serial" component.
Click to expand...
 
PierceNichols said:
When I compile and load from the Win8.1 box, I don't get a serial port on either box. The only difference is that the Win7 box is running Teensy 1.33 and the Win8.1 box is on Teensy 1.34-beta 1. Thoughts?
Click to expand...

Maybe 1.34-beta1 is doing something wrong? It is somewhat experimental with gcc 5.4. Please please please, make a copy of the code you're compiling. Please also grab the .hex and .elf file it's building. They'll be in a build folder inside a hidden temp folder. You might get to it by typing "%temp%" in Windows Explorer. For full path info, turn on verbose info while compiling in Arduino's File > Preferences menu. Then it will print tons of info about the compiler commands, and in them you'll see the full pathnames of everything. You can also see the full path info of where Teensy Loader is getting the .hex file in Teensy Loader's Help > Verbose Info window. Please save a copy of the source code and the compiled files. I'd really like to try loading that code onto a board here to see if I can reproduce the problem.

Even if I can't recreate the problem, I can look at the contents of the .elf file and source code to try to figure out why it might be failing.

As another sanity check, you might grab the good .hex file created on your Windows 7 machine and bring it over to the Windows 8 computer. In the Teensy Loader window, you can use File > Open to read it, and then press the button on your Teensy to go into programming mode and manually use Teensy Loader to put the good code onto your board using Windows 8. That could help narrow down whether the problem is related to Windows 8 USB stuff, or if it's simply a matter of Arduino producing a bad .hex file.

Again, if this does turn out to be a bad .hex file, please please please save the source, the .hex, and the .elf file if you can - and post them all here.

In 1.34-beta1, there's a new Tools > Optimize menu. It offers 10 different ways your code can be optimized. In 1.33, the Tools > CPU Speed offered options that were basically "Fast" and "Smallest". The new ones, especially Fastest with LTO, are a bit experimental. So far most things have worked, but maybe you've found a case that needs to be investigated?
 
Last edited:
I just used the TD_1.34b1 code Teensy.exe to upload the code from linked post 8/14 to an LC with no problem. It worked with TYQT (my default) with and without LTO - then I closed TYQT and pointed TEENSY.exe at the HEX without LTO and it is up and running after uploads of that file.

This doesn't speak to the code you are getting stuck on as it fails - post per Paul.

But trying the above linked sketch for LC works on my Win 10 IDE 1.6.13 machine when compiled "Tools / USB type: Serial".
 
Theremingenieur said:
I think that it's related and it's a common rookie mistake to not check for the desired USB mode in the Arduino IDE menu settings BEFORE compiling and uploading whatever sketch. How else should the Teensy then know that it has to show up as a serial device after reprogramming and reboot?

That is not by default because, depending on the use case, developers prefer their Teensy to show up as a bare USBHID device, a USB Joystick, or a MIDI device or what ever. BTW: The bare USBHID mode allows the use of Serial.print() in sketches and the serial monitor, too, no need to blow up forcibly your HEX file by including the serial driver just for debugging purposes.
Click to expand...

So, after sleeping on it, I rebooted everything, double checked this... and now it just works. :D

Frustration and fatigue don't make me better at debugging. :/
 
Status
Not open for further replies.
Back
Top