Teensy 3.2 not showing up on serial port already tried troubleshooting

Status
Not open for further replies.

kvasir

Member
I have three teensy 3.2's that have the same problem and one teensy lc that shows up correctly (comm7). Already went through the troubleshoot guide and reinstalled all software as well as trying solutions in the forums I could find, still nothing. Any and all help would be very appreciated.
 
First, please understand Teensy uses HID protocol for uploading. Brand new Teensys come with LED blink using RawHID, not serial. There is no COM port until you've uploaded a program, and only if Tools > USB Type has Serial selected when your program was compiled.

More info here:

https://www.pjrc.com/teensy/troubleshoot.html

When testing, watch the Teensy Loader window. Or if you look for devices in Windows, you must look for HID, not serial.

https://www.pjrc.com/teensy/check_halfkay_vista.html
 
I know, two teensy 3.2's I have been working with for a month now uploading programs to them as of an hour ago and the third is brand new. Now none will show up. I have already gone through the troubleshoot guide as well as quadruple checked I set the USB type correctly. Still all of my 3.2's will not show up but my LC will. Up until this morning it would always come up as COMM8 or COMM9 now I see the device as HID-compliant vendor-defined devices in Device Manager and nothing that has been suggested on the troubleshoot page or in any forum has helped. I can still upload programs, but no serial port which is pivotal to what I'm working on.
 
Last edited:
Maybe you're using an older version of Windows?

The sad reality is all pre-10 versions of Windows have terribly buggy USB serial (USBSER.SYS) support. That's why Teensy uses HID for uploading and why we ship all brand new boards programmed with a RawHID build.

From what you're written, all I know is you've tried everything and nothing worked. Can you understand how little info that is? All I can offer you is some pretty blind guesswork. Here goes...

First, have you cold rebooted your computer? Yeah, the answer should be yes, since you've "already gone through the troubleshoot guide". But over and over we hear these sorts of problems on Windows that are solved by rebooting....

Since you wrote "serial port which is pivotal to what I'm working on", maybe I can guess you're running some program on your PC other than Arduino, which opens the COM port? If using a pre-10 version of Windows, you must be very careful to close the port before uploading or even unplugging the USB cable. The Windows driver has a very confusing bug. I made this video years ago, which *finally* prompted Microsoft to fix it in Windows 10 (thanks to Phil Torrone of Adafruit who managed to find & pester the right people within Microsoft)

https://www.youtube.com/watch?v=DRmvUsa2xuU

One other very simple thing to double check is the Tools > USB Type menu in Arduino. If you've accidentally clicked this, perhaps it's simply been set to program Teensy as a non-Serial type.

Many other things might be wrong, especially if you've done a lot of fiddling with driver stuff on your machine while trying to solve this. Usually that makes everything much worse. Maybe there are some Windows experts who can solve such issues, but often the only viable solution is to move to another Windows machine that isn't messed up, or to reformat and reinstall Windows and all your software & data.
 
I am using windows 10 and went through every single last step in the troubleshoot guide as it is written. I think the issue is with my antivirus. Had an issue with compiling in which a file couldn't be overwritten, turned off active scanning and that fixed it, but then everything went downhill. I was finally able to get all of the teensy 3.2's working correctly on another machine. I'll do an OS reset later today. I didn't try to mess with the driver beyond reinstalling them.
 
Yeah I really miss working on my Linux machine. Ran into issues at work writing apps for windows on linux. Haven't taken the time to set up dual boot or virtual machine yet. It is quite finicky with dual boot, windows will overwrite GRUB every single last chance it gets.
 
Odd it went from working to not working - maybe some new 'protection' feature of the AV is getting in the way.

These are steps I found to work before windows 10 - not been having such issues with Win 10 - but there may be something there that helps? One thing is 'good cables go bad' - I suppose you've tried alternate cables?

The last item there is TyQt [ now TyCommnader ] - it will show a Teensy USB or not and that can be helpful if it sees it. If it doesn't see it then there is real trouble - cable or Windows.
 
I think i've figured out the cause of the issue. The serial port and / or the HID protocol for uploading is definitely buggy in that eventually it will hang and not upload or just crash the Arduino IDE. It will either give a timeout error of some sort or just show 0% of the program space was used after a "successful" upload. It will successfully upload under different usb types, but there won't be a serial port. Essentially the writing process for a serial usb type will cause the temporary build files under user/AppData/temp/ to get corrupted and all files inside of the temp folders need to be deleted before a successful serial usb type write of the program can be made and the serial port will come back up. Sometimes that is enough and other times the button on the board will need to be clicked before the serial port will come back up after a successful serial usb type upload. I would love to see the source code for this write process so that I could get closer to the specific cause since it has been a continues and major issue for me.
 
Here is code for a bash script to clear out those temp files. Now whenever I get a corrupt write to a teensy I can run this, recompile, and click the hard reset button and it comes up like a charm.

Code:
#!/bin/bash

for dir in ~/AppData/Local/Temp/arduino_*;
do
  echo "$dir"
  cd "$dir"
  rm -rf *
  cd ..
done
 
Essentially the writing process for a serial usb type will cause the temporary build files under user/AppData/temp/ to get corrupted and all files inside of the temp folders need to be deleted before a successful serial usb type write of the program can be made and the serial port will come back up.

I don't know what you mean by "the writing process".

Maybe if you understood the process a little better and where to find info, you could describe what's happening more clearly? I'll try to give you a little background info...

What commands Arduino runs is controlled by platform.txt and boards.txt. You'll see Teensy uses a program called "teensy_post_compile". This is the last step done after Arduino has written all the files to the temp folder. It's not open source, but you can find the program in hardware/tools and run it yourself if you want to experiment. It requires command line args for the file and directory where Arduino put the .hex file, and also the tools folder ({arduino}/hardware/tools). In that tools folder you'll also find "teensy" which is the Teensy Loader program, and "teensy_reboot".

The teensy_post_compile utility's main function is to launch Teensy Loader if it's not already running, and then communicate the filename and directory. It also puts Teensy Loader into auto mode. If you click Help > Verbose Info in Teensy Loader, you will see much more detail about what's happening. When it gets communication from teensy_post_compile, the commands are logged in that verbose info window.

As a last step, if you gave the -reboot option to teensy_post_compile, it will run teensy_reboot. Earlier versions of Arduino just ran both of these, but in the latest versions the process isn't so flexible to run more than 1 program, so teensy_post_compile takes care of running teensy_reboot.

This teensy_reboot utility is the part which actually tries to find any connected Teensy and send it the request to reboot.

Both of these programs log info about what they're actually doing to teensy_reboot_log.txt. Together with the Verbose Info inside Teensy Loader, you can get a pretty detailed picture of what they're really doing.

Once teensy_reboot finds a Teensy and manages to send it a request, it's done. That's all it does.

When Teensy reboots into bootloader mode, the upload happens because Teensy Loader was put into Auto mode. Teensy Loader always reads the HEX file right before actually uploading. It also looks at the .ELF file, if present, to check which Teensy you've used.

None of these programs should ever write to the HEX file or anything else Arduino created. Teensy Loader only reads it. The teensy_post_compile and teensy_reboot programs don't read or write the files Arduino created. They only writing they ever do is to teensy_reboot_log.txt.

Perhaps a good question is whether the files were originally created correctly by Arduino and were later messed up somehow, or if they were bad from the moment Arduino wrote them? You can use "show verbose info while compiling" from File > Preferences to get Arduino to print the actual compiler commands it used. Maybe if you try running the (huge) final linker command to create the .ELF file, and then the objcopy command to convert it to .HEX, you could see if they recreate good copies of the data?

I would very much like to know why this is going to wrong on your Windows machine. Hopefully this info can help you investigate and share anything you learn? I can tell you this absolutely does not happen when I run here on Windows 10. Something is really messed up....
 
turn off usb power management for the hubs your teensy is connected to in device manager

that solved issues i had with teensy on windows 10
 
turn off usb power management for the hubs your teensy is connected to in device manager

that solved issues i had with teensy on windows 10

Oh, good tip indeed. I didn't know Windows 10 had this.

I wonder if there's any way we could detect this setting and show a warning message?
 
after programming teensy 3.5 on the surface book with latest updates, teensy would reboot but the serial monitor wouldnt reattach, this would happen after every time i programmed the teensy, if i program it a second time it would return, 3rd time not attach, 4th time monitor opens etc, this occured with the most recent updates of win10

i never had issues after i turned off the power saving features of the hubs (teensy was directly connected too, no external hubs)

just keep in mind keeping them off affects power management of standby/sleep, so if your tablet is hibernating/sleeping, teensy is still being powered

this is fine for me cuz i can use the surface book's usb port while its hibernating to charge my phone ;)
 
Status
Not open for further replies.
Back
Top