Teensyduino USB issue

Status
Not open for further replies.
Windows 10. I checked that, Autodesk isn't in the Startup tab of Task Manager. It's not in msconfig > Services either, except for maybe a cryptic service called Print Manager with the manufacturer set to Unknown.
 
Hard to say... Sometimes I find startup apps, like defragster mentioned. Other times looks for a program group called startup...

If it were me, I might try seeing if maybe the Autodesk program is tied to some specific comm port. In the past I sometimes found issues with some COM port numbers < 10. So you might try finding the com port associated with your Teensy in the Device manager, I think it is then an advanced option, where you can set the actual Com port number. Try changing it to something like 10. Then reboot and see if that helps
 
USB Problem with T3.2 but not T3.6

I just got a new T3.2 and I can not get the Arduino IDE to recognize the Port. I have Windows 7 Home Premium, Arduino 1.8.3. At your suggestion I set the USB Type to MIDI. I was able to upload and print the Teensy example Print.

I also have T3.6 and I do not have this problem with the 3.6. Is there a difference in the USB interface between the T3.2 and T3.6 or is it going to be related to the first Teensy is ok but the second will experience this problem?

I have a sailboat autopilot project using two Arduino Megas that has been shared with many people. I want to upgrade this project to Teensy because of processor speed, 32 bit word and floating point co-processing (accuracy and speed). I would just as soon not have to deal with this problem both for myself and other users. If I stick to using the 3.6 should I be able to expect to not have this problem?
 
A brand new Teensy always appears as HID, not Serial. It only becomes Serial after you program it, and only if Tools > USB Type was set to one of the options that makes your Teensy into a serial device.

Windows 7 (and all pre-10 versions) have terrible USB serial drivers. Lots of things go wrong and leave bad state left over in the Windows registry, especially if you unplug the cable or press the button on Teensy while Windows is detecting things or using the port. Microsoft *finally* fixed these problems in Windows 10, but if you have version 7, the sad news is serial is always a bit flakey. Usually some combination of rebooting, updating the driver (run the Teensyduino installer and look for the button not-default button on the driver step), uninstalling or updating the driver in Windows Device Manager, and just dumb luck usually gets things to work. The best solution is to upgrade to Windows 10, or Linux or Macintosh.
 
I had this problem just now, and was able to solve it (for me, running Win10).

Some background that led me to my solution:
When you install a program in Win7+ (eg. install the Arduino IDE), and the installer launches the just-installed app, that app often runs in a "sandboxed" mode. This happens to me EVERY TIME I install a Notepad++ update. The NP++ updater closes NP++, runs the install, then reopens NP++. But when it reopens, none of my files get reopened. Why? Apparently because when the installer launches the new exe, Windows runs it under some limited-rights user, thus the file history is not available because those files are stored under "me" rather than "wierd other sandboxed user". If I close NP++ then reopen it as usual (i.e as "me"), my files reappear.

So when the COM port thing happened to me, I immediately suspected this may be similar. I had just today installed the latest Arduino IDE, and I *think* the IDE installer opened Arduino.exe for me, and I just used that. I had even opened other sketches *via the IDE* so therefore those new instances of Arduino have the same rights as the initial one opened by the installer.

This solved it for me:
1) Close EVERY open Arduino instance.
2) From the Start menu, find the Arduino app, *RIGHT CLICK* it, and choose "Run as administrator"
3) See if you can then access the COM port (I could; if you can't then your problem isn't the same as mine :).
4) Close EVERY open Arduino instance
5) From the Start menu, find the Arduino app, *LEFT CLICK* it to open it "as usual", i.e. whichever user you are currently logged in as.
6) See if you can then access the COM port (again, I could).

Step 2 is really just an "acid test", no need to do this every time. But if the Admin can't open it, then there's little hope that your regular user can.
 
Hey, this was the problem for me, too! I reported this as an issue with Autodesk.
It is strange, tho. I didn't have any problem with regular Arduino Uno clone boards, just the Teensy.
 
I ran into this problem too, using a Teensy++2.0 (cannot access com port, access denied). Turns out it was the AutoDesk "Print Manager" causing some problems with the serial port. It probably tried to connect to the Teensy++2.0, failed, and crashed in some way that retained a handle to the Teensy.

Autodesk isn't in the Startup tab of Task Manager. It's not in msconfig > Services either, except for maybe a cryptic service called Print Manager with the manufacturer set to Unknown.

Nailed it - that's the offending service. Disabling this (using msconfig) fixed the problem, but only after reboot.

print-manager.png

Alternatively, it appears it's possible to stop the service using task manager. The COM port was accessible after stopping the service and disconnected/reconnecting the Teensy++2.0.

print-manager-service.png

Interestingly, this node.js code contains an Arduino sketch and associated node.js code to access a COM port (including a stress test designed to continuously send data to the port!). It's all under C:\Program Files\Autodesk\Autodesk Print Studio\PM\spark-print-mgr\node_modules\serialport. Some of this stuff looks like a copy+paste from node-serialport, hacked to perhaps do something useful (connect to a 3D printer directly?). It would be interesting to see what it's sending to the Teensy.
 
I realize this is a very old thread, but I'm still locking up with a T 4.1 running Win10. Oddly, some compiles do not lock up, but most do. I'm not sure where to look next.
 
I'm not sure where to look next.

Check if you have the Autodesk Print Manager running on your PC. If you do, disable it, as others have done in this thread.

If not, start a new thread. Begin that new thread by telling us very specifically the behavior you are actually observing. Just saying "some compiles do not lock up, but most do" gives us almost zero info. We can't see your screen. We don't know if you're compiling one of the known examples or some huge project. There's not even enough for bling guesswork. To get useful help, you will probably need to make screenshots or a short video (try to hold your cell phone still, then upload to youtube as unlisted and share the link).
 
Check if you have the Autodesk Print Manager running on your PC. If you do, disable it, as others have done in this thread.

If not, start a new thread. Begin that new thread by telling us very specifically the behavior you are actually observing. Just saying "some compiles do not lock up, but most do" gives us almost zero info. We can't see your screen. We don't know if you're compiling one of the known examples or some huge project. There's not even enough for bling guesswork. To get useful help, you will probably need to make screenshots or a short video (try to hold your cell phone still, then upload to youtube as unlisted and share the link).
I didn't mean for this go be a formal bug submission. I simply wanted to know if there was any additional information on other threads my search didn't turn up. I do not have the Autodesk Print Manager running. The code is 11000 lines of C code, stripped down from the Convolution SDR (ham radio) code Frank (and others) have written. We're only using about 2% of flash, but almost 45% of SRAM. The CPU load factor is low (13.8%) and the temp is 46C.There are no recursive calls, nor are we using the String class. I'll make a video and post it, but have no idea what value that will be, since this is on the upload and not actually with the execution of the code. Because this will end up being part of another book, all of the work is being developed in the Arduino IDE.
 
I simply wanted to know if there was any additional information on other threads my search didn't turn up.

Even if someone was personally familiar with every message on this forum, how would they know if it relates to "some compiles do not lock up, but most do"?

What does "lock up" really mean anyway? Since you said "some compiles", I'm imaging you clicked Arduino's Verify button. Then the black console panel goes blank, the blue bar above it changes to "Compiling sketch..." and the purple progress bar on the right hand side appears and partially fills in, then stops. Maybe? Arduino just getting stuck and not ending the compile process with an error would be highly unusual. But given only 9 words: "some compiles do not lock up, but most do", the most literal meaning would suggest the Arduino IDE is somehow not completing compilation of your code.

But this thread was about USB issues and interference by another program. Maybe "Done compiling" appears on your screen and then it gets hung up trying to upload? But it's supposed to ask your to press the button after about 5-6 seconds. Maybe that's appearing, or maybe not?

Or perhaps "lock up" happens on Teensy? Usually people use those words to describe code that actually started running, but then appears to stop responding.

Can you understand how ambiguous and lacking specific visual detail your problem description is?
 
Yep, I wasn't very clear. The compiler and linker appear to have done their job. It's moving the code from the PC to the T41 that is locking up. Indeed, it's the error message that brought me to this thread. Since this is exactly the same behavior as the OP, I thought that it was understood that was the issue. If I do a reset of the T41 before being timed out, it usually finishes the upload, but not always. I don't have any other apps running in the background (other than the IDE and the standard Win10 stuff).

I'll see if there's anything else I can ferret out and, if so, I'll report it here.
 
By "exactly the same behavior as the OP", I'm guessing you mean you're seeing this on your screen:

Found serial '\\.\COM6', but unable to open for reboot request
Teensy did not respond to a USB-based request to automatically reboot.
Please press the PROGRAM MODE BUTTON on your Teensy to upload your sketch.


Maybe you're also seeing something like this?

Further, the Serial Monitor isn't working. I'm getting 'Port busy'.


Again, I want to emphasize how much these small details matter. Especially the exact appearance of "I'm getting 'Port busy'" is very important. A screenshot really is the only way to clearly communicate it. But as you can see on this thread, that can happen if other software on your PC is trying to also use the same USB port, as was the case with Autodesk's Print Manager. This is why you should show a screenshot if you have a message like that.


But to answer your original question, yes, in many other threads the cooperative nature of the "USB-based request to automatically reboot" has been discussed. Auto-reboot only works if your Teensy is still running properly with USB enabled and code able to hear the USB messages. It is the reason why every Teensy has a Program (not reset) button, because the USB port can be disabled or interfered with by the code running on your Teensy board.

Other than recommending screenshots and clearer description of what you actually see (even this latest message is your belief about what happened, not a direct account of the actual sequence of observed messages or visual cues), I would recommend testing with simpler code like File > Examples > 01.Basics > Blink. Or find some larger examples, but the point is to use known-good code. If you're able to reliably upload with known-good code, then you can be confident your hardware and USB system is good and start searching for whatever in your program might be messing up the USB communication. Of course if you get similar problems with known good code, then you would start looking at things like USB hubs & cables, or software on your PC which might be interfering.
 
Multiple Arduino IDEs Open

econjack, I wonder if you have more than one Arduino IDE open.

I occasionally see the following error with the link to this forum thread:
Sketch uses 18672 bytes (57%) of program storage space. Maximum is 32256 bytes.
Global variables use 820 bytes (32%) of dynamic memory, leaving 1740 bytes for local variables. Maximum is 2560 bytes.
Unable to open COM14 for reboot request
Windows Error Info: Access is denied.
more ideas... https://forum.pjrc.com/threads/40632?p=126667&viewfull=1#post126667
Teensy did not respond to a USB-based request to enter program mode.
Please press the PROGRAM MODE BUTTON on your Teensy to upload your sketch.

When this happens it is because I've opened more than one sketch from Windows File Explorer. If I open multiple sketches from one Arduino IDE, it is not a problem. Look at your taskbar. If you see two Arduino IDE icons, then most likely this is what happened. One will upload fine but the other one will require that you press the reset button on the Teensy.

Image1.jpg
Taskbar with two Arduino IDEs Open. One of the Arduino IDEs will have problems uploading to the Teensy and require the reset button to be pressed.

Image3.jpg
Taskbar showing multiple files open in one Arduino IDE, which is fine.

Image4.jpg
Error message shown in one of the Arduino IDEs when multiple Arduino IDEs are open.

Hope this helps you or someone else. :D
 
Thanks, richteel, for responding. No, I have seen that message, too, but that is not the case here. I have noticed that, if the app does not terminate normally (i.e., returning control to the IDE), a subsequent compile usually fails. Restrting the IDE usually (not always) fixes this issue.
 
Status
Not open for further replies.
Back
Top