Hello,
I have been working with teensy 3.6 for three weeks now and recently teensy loader started to have issues. Every time it starts to load it turns grey (doesnt respond) and i have to close it, wait for the teensduino to return an issue, reload it, and after that it works. Any ideas?
Just did that, did't work, but i just noticed that this happens only when i plug and unplug the teensy board, and i upload something after that.If it is constantly plugged i can upload many sketches without a problem, maybe it has something to do with the ports.
Teensy Loader has a Verbose Info window, hidden in the Help menu (a place nobody would ever look...)
Maybe it will show useful info? Even if the program locks up and stops responding, maybe you could get a screenshot of whatever the final info appeared in the Verbose Info window before the lockup? If the window is still responding, it has a Log menu which lets you save all the info to a text file, which you could post here.
There's also a log file from the utilities running on the Arduino side. On Linux it's /tmp/teensy_reboot_log.txt. Can you show us that log file, and whatever you're able to capture of the Verbose Info on Teensy Loader?
And this is from verbose when it managed to upload (after not responding, closing, opening again and uploading):
Well, nice as this is to see everything *later* works, the question is whether you can capture any of the Verbose Info log *when* the problem happens. The /tmp/teensy_reboot_log.txt shows activity at 12:26. Then you're showing us the Verbose Info from 5 minutes later, at 12:31. We need to see the Verbose Info that happened at 12:26 when the problem occurred!
Even if Teensy Loader is completely locked up, if you have opened the Verbose Info window before the problem occurs, can it still be seen on the screen? Can you capture the screen and post a JPG image of the Verbose Info that's visible? (there are many screen capture programs for Linux... I personally use the Gimp image editor and click File > Create > Screenshot)
If anything is going wrong at the Linux kernel level (a real possibility for a lockup... something that almost never happens on Linux), perhaps the kernel will log useful info in syslog. Most distros save this in /var/log/syslog. When you try again, please also look at that log file and if there's anything logged in the same time range at the Verbose Info and /tmp/teensy_reboot_log.txt, please post that too.
Linux problems are tough because there's so much variance between distros, and even installs of the same distro. But if there's any hope of figuring out what's going wrong here, it'll be in those log files.
So something strange happened, when i had verbose open the loader was uploading without "not responding". The IDE was reporting that "an error occured while uploading the sketch" but the sketch had been uploaded (i know because i chose the blink example). I tried to make it not respond and i succeed, (same message at the IDE) this is the screenshot with the verbose open:
This is the syslog at that time (it continues if that will help):
Jan 22 13:17:35 Bomba kernel: [11077.212236] usb 2-2: USB disconnect, device number 112
Jan 22 13:18:05 Bomba kernel: [11107.111610] cdc_acm 2-2:1.0: failed to set dtr/rts
Jan 22 13:18:05 Bomba kernel: [11107.351608] usb 2-2: new full-speed USB device number 113 using xhci_hcd
Jan 22 13:18:05 Bomba kernel: [11107.480027] usb 2-2: New USB device found, idVendor=16c0, idProduct=0478
Jan 22 13:18:05 Bomba kernel: [11107.480030] usb 2-2: New USB device strings: Mfr=0, Product=0, SerialNumber=1
Jan 22 13:18:05 Bomba kernel: [11107.480031] usb 2-2: SerialNumber: 0004AE96
Jan 22 13:18:05 Bomba kernel: [11107.480865] hid-generic 0003:16C0:0478.0022: hidraw2: USB HID v1.11 Device [HID 16c0:0478] on usb-0000:00:14.0-2/input0
Jan 22 13:18:06 Bomba kernel: [11108.106811] usb 2-2: USB disconnect, device number 113
Jan 22 13:18:06 Bomba kernel: [11108.407648] usb 2-2: new full-speed USB device number 114 using xhci_hcd
Jan 22 13:18:06 Bomba kernel: [11108.536215] usb 2-2: New USB device found, idVendor=16c0, idProduct=0483
Jan 22 13:18:06 Bomba kernel: [11108.536218] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 22 13:18:06 Bomba kernel: [11108.536219] usb 2-2: Product: USB Serial
Jan 22 13:18:06 Bomba kernel: [11108.536220] usb 2-2: Manufacturer: Teensyduino
Jan 22 13:18:06 Bomba kernel: [11108.536221] usb 2-2: SerialNumber: 3068380
Jan 22 13:18:06 Bomba kernel: [11108.536668] cdc_acm 2-2:1.0: ttyACM0: USB ACM device
Jan 22 13:18:53 Bomba wpa_supplicant[1252]: wlan0: WPA: EAPOL-Key Replay Counter did not increase - dropping packet
Jan 22 13:18:53 Bomba kernel: [11154.906650] ------------[ cut here ]------------
Jan 22 13:18:53 Bomba kernel: [11154.906677] WARNING: CPU: 1 PID: 514 at /build/linux-SwhOyu/linux-4.4.0/net/wireless/sme.c:864 cfg80211_roamed+0x86/0xa0 [cfg80211]()
And the teensy log (it stops there,it does go after 13:17:35.270 ):
My best guess from this log info is your PC sent the request to Teensy to reboot around 13:17:35, and Teensy did indeed reboot to bootloader mode.
However, it seems the Linux kernel cdc_acm driver was still trying to use the disconnected device. This line is the really suspicious part...
Code:
Jan 22 13:18:05 Bomba kernel: [11107.111610] cdc_acm 2-2:1.0: failed to set dtr/rts
...partly because the cdc_acm driver should not have continued trying to set dtr/rts on a disconnected device, and partly because it happened exactly 30 seconds after the disconnect. That's almost certainly some sort of things-have-gone-very-wrong timeout within the Linux kernel. Then the kernel detects Teensy has appeared again as the bootloader HID IDs (16C0/0478), but right after the cdc_acm driver finally gives up an operation it should have aborted 29.9x seconds earlier!
I can tell you with confidence Teensy didn't take 30 seconds to reboot into bootloader mode. It was almost certainly sitting there from 13:17:36 to 13:18:05 just waiting for your PC to start the "usb enumeration" process. The kernel really should have detected new device arrival and HID 16C0/0478 much sooner, like around 13:17:36.
Something certainly looks messed up with how your kernel is handling USB disconnect and alerting its drivers. Which distro and which kernel version is this? I have used Linux quite extensively for USB over the last 10 years. I've found a few kernel bugs (especially in the early days of the hidraw driver), but this is unlike anything I've seen before.
I have a 16.04 system, (but i don't use it a lot) :
Ubuntu 16.04.3 LTS
Linux u64 4.4.0-109-generic #132-Ubuntu SMP Tue Jan 9 19:52:39 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
i did some tests with T3.6 (1.8.4/1.40), building, plugging, unplugging, rebuilding etc. .... no problems.
How about if you use different USB port on linux box? or the "windows solution", reboot linux
I'm using Ubuntu 16.04 LTS, and Mint Mate 18.2. I do get the error uploading message, but then it goes ahead and uploads the sketch everytime with no problem right after the error message. It SEEMS to fail during the first attempt, and then promptly succeeds in the second attempt. It works so I just ignore the error, but the devs should probably know about it. I have a similar issue with the bootloader for the Uno board. I had been using UNO with Unojoy before I got Teensy. It also gives me an error when changing the Uno back n forth from Uno to Joystick, but again it works everytime so I have just learned to ignore the error.....Oh and Thank you for supporting Linux with the TeensyDuino/Arduino softeware :-D <(")
For everyone seeing this issue, please try editing usb_dev.c. Look for this, around line 596:
Code:
if (usb_cdc_line_coding[0] == 134) usb_reboot_timer = 15;
What happens if you lengthen this reboot timer from 15 ms to something like 100 ms? It's only 8 bits, so don't go higher than 255.
If this turns out to make a difference, maybe I'll lengthen it for the next release? Or maybe I'l try to come up with a better why than just a simple timer.
Hmm, Ubuntu 16.04 machine is fine now..no errors. Didn't do anything. Mint Mate still errors but loads anyway. I have been getting intel microcode and kernal updates every couple days lately, presumably because of Spectre and Meltdown...wonder if this has something to do with it
For everyone seeing this issue, please try editing usb_dev.c. Look for this, around line 596:
Code:
if (usb_cdc_line_coding[0] == 134) usb_reboot_timer = 15;
What happens if you lengthen this reboot timer from 15 ms to something like 100 ms? It's only 8 bits, so don't go higher than 255.
If this turns out to make a difference, maybe I'll lengthen it for the next release? Or maybe I'l try to come up with a better why than just a simple timer.
I just upgraded my Ubuntu from 18.04 to 18.10 and I was not able to uploade anymore to the teensy.
This minor change in the configuration file helped solve the problem.
Thanks PaulStoffregen
edit: hmm, only for a short period of time...
Problem: I am allowed to upload as long as I press the "Button" on the teensy. If I do not the arduino IDE will throw an error.
Through matlab I can see that the teensy port is instantly occupied when connected to my laptop
Code:
Unable to open /dev/ttyACM0 for reboot request
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.
An error occurred while uploading the sketch
This problem stated when I upgrade my Ubuntu version
I'm also getting bit by this. Same error messages. I must press the prog button for it to program the Teensy 3.6. System was loaded with Ubuntu 18.10 last December and kept up to date software wise.
Exact same set of cables works fine using a Raspberry Pi running raspbian.
First thing to understand is your Teensy is working. The hardware is definitely good. This "did not respond to a USB-based request" issue is entirely a software problem, when you are able to upload by pressing the pushbutton.
The first step is to get some idea whether the software problem is on the Teensy side or your PC. The easiest way is to upload the Arduino's blink example, from File > Examples > 01.Basics > Blink. Obviously the first upload is still going to require a button press. Upload it a few times. If uploads start working without press the button, that's a sure sign everything is fine on your PC.
If the problem turns out to be software on the Teensy side, start looking for stuff you're doing that may be interfering with interrupts or the USB port. One simple idea is to add 5 to 10 seconds of delay in various places as your program initializes stuff. If you're able to upload automatically during those 5-10 seconds, that's a good sign everything you did before the delay was ok, something after the delay started interfering with your Teensy's ability to hear the auto-reboot request. Move the delay around in your program until you get a good idea of what's causing the trouble.
If the problem is on you PC, well, that's harder. But it's very likely to be some other software, not Arduino, is opening the port in a way that interferes with Arduino being able to get access to the port to send that auto-reboot request. On Linux, the Gnome Modem Manager has historically caused a lot of trouble. The udev rules file you installed is supposed to tell Modem Manager to leave Teensy alone. On Windows, there's a 3D printer manager from Autodesk which sometimes mistakes Teensy for a 3D printer and hogs the port.
One other thing you can try on the PC side is using a different setting in Tools > USB Type. Try MIDI or RawHID. Those don't have any serial device at all. The serial monitor works using a HID interface, and the auto-reboot request is sent to that HID interface... so it's using a completely different driver as far as your PC is concerned, even through it looks the same in Arduino.
That pesky rts/cts error is where I'm at right now. I've been looking into how to disable modem control on the usb serial handling driver cdc_acm. Ideally with an option at module load. I don't know if it will fix it, Seams we aren't the only one with the issue. Stupid regression if this is the issue.
The convention for the Arduino's serial interface is for the DTR signal to be used for a reset signal—when using the integrated serial-to-USB adapter, the DTR/RTS/DSR/CTS signal; or, when using an RS-232 cable, pins 4 or 5 (and possibly 6 or 8) are wired to the RESET pin.
That pesky rts/cts error is where I'm at right now
.....
Does the Teensy do this too?
No, Teensy doesn't use DTR or RTS for auto-reboot.
Are you using some other board? Really confusing when questions about non-Teensy boards get mixed into this sort of thread that's specifically about using Teensy Loader.
Real frustration... Removed ModemManager, no change. Removed cups, no change, but now my syslog fills with a few hundred colord messages every time I plug in or remove a USB device. ??? Why did removing cups break colord?
n
Originally Posted by adim
Stupid regression if this is the issue.
Posting Permissions
Reply With Quote