Teensy Loader Ubuntu problem

Status
Not open for further replies.

adim

Member
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?

Thank you
 
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?
 
These are the last two connection attempts of the linux log file:

12:26:31.614 post_compile: Begin
12:26:31.614 post_compile: Connect attempt to port 3149
12:26:31.614 post_compile: Connect attempt to port 3149
12:26:31.715 post_compile: Connect attempt to port 3149
12:26:31.715 post_compile: Connected to port 3149
12:26:31.720 post_compile: Sending command: comment: Teensyduino 1.40 - LINUX64 (teensy_post_compile)
12:26:31.720 post_compile: Sending status request
12:26:31.724 post_compile: Receive status dir = /tmp/arduino_build_626899/
12:26:31.762 post_compile: Receive status file = ACCELGYROMAGSD.ino.hex
12:26:31.762 post_compile: Receive status readable = 1
12:26:31.762 post_compile: Receive status auto = 0
12:26:31.762 post_compile: Receive status online = 0
12:26:31.762 post_compile: Receive status online_count = 0
12:26:31.762 post_compile: Receive status offline_count = 0
12:26:31.762 post_compile: Receive status state = 0
12:26:31.762 post_compile: Receive status EOT
12:26:31.762 post_compile: Sending command: auto:eek:n
12:26:31.762 post_compile: Disconnect
12:26:31.783 post_compile: Begin
12:26:31.783 post_compile: Connect attempt to port 3149
12:26:31.783 post_compile: Connected to port 3149
12:26:31.783 post_compile: Sending command: comment: Teensyduino 1.40 - LINUX64 (teensy_post_compile)
12:26:31.784 post_compile: Sending status request
12:26:31.788 post_compile: Receive status dir = /tmp/arduino_build_626899/
12:26:31.826 post_compile: Receive status file = ACCELGYROMAGSD.ino.hex
12:26:31.826 post_compile: Receive status readable = 1
12:26:31.826 post_compile: Receive status auto = 1
12:26:31.826 post_compile: Receive status online = 0
12:26:31.826 post_compile: Receive status online_count = 0
12:26:31.826 post_compile: Receive status offline_count = 0
12:26:31.826 post_compile: Receive status state = 0
12:26:31.826 post_compile: Receive status EOT
12:26:31.826 post_compile: Disconnect


And this is from verbose when it managed to upload (after not responding, closing, opening again and uploading):

12:31:49.425: Teensy Loader 1.40, begin program
12:31:49.440: File "ACCELGYROMAGSD.ino.hex". 30628 bytes, 3% used
12:31:49.440: Listening for remote control on port 3149
12:31:49.440: initialized, showing main window
12:31:49.484: remote connection opened
12:31:49.486: remote cmd: "comment: Teensyduino 1.40 - LINUX64 (teensy_post_compile)"
12:31:49.487: remote cmd: "status"
12:31:49.496: Device came online, code_size = 1048576
12:31:49.496: Board is: Teensy 3.6 (MK66FX1M0), version 1.03
12:31:49.507: File "ACCELGYROMAGSD.ino.hex". 30628 bytes, 3% used
12:31:49.507: set background IMG_ONLINE
12:31:49.510: status data sent
12:31:49.556: remote connection closed
12:31:49.563: remote connection opened
12:31:49.563: remote cmd: "comment: Teensyduino 1.40 - LINUX64 (teensy_post_compile)"
12:31:49.564: remote cmd: "status"
12:31:49.564: status data sent
12:31:49.612: remote connection closed
12:31:49.615: remote connection opened
12:31:49.616: remote cmd: "show:arduino_attempt_reboot"
12:31:49.616: got request to show arduino rebooting message
12:31:49.618: remote cmd: "comment: Teensyduino 1.40 - LINUX64 (teensy_reboot)"
12:31:49.618: remote cmd: "status"
12:31:49.618: status data sent
12:31:49.658: remote cmd: "auto:eek:n"
12:31:49.664: File "ACCELGYROMAGSD.ino.hex". 30628 bytes, 3% used
12:31:49.665: elf size appears to be 1048576
12:31:49.665: elf binary data matches hex file
12:31:49.665: Code size from .elf file = 1048576
12:31:49.665: begin operation
12:31:49.667: flash, block=0, bs=1024, auto=1
12:31:49.674: remote connection closed
12:31:49.674: flash, block=1, bs=1024, auto=1
12:31:49.678: flash, block=2, bs=1024, auto=1
12:31:49.680: flash, block=3, bs=1024, auto=1
12:31:49.956: flash, block=4, bs=1024, auto=1
12:31:49.958: flash, block=5, bs=1024, auto=1
12:31:49.975: flash, block=6, bs=1024, auto=1
12:31:49.977: flash, block=7, bs=1024, auto=1
12:31:49.994: flash, block=8, bs=1024, auto=1
12:31:49.996: flash, block=9, bs=1024, auto=1
12:31:50.013: flash, block=10, bs=1024, auto=1
12:31:50.015: flash, block=11, bs=1024, auto=1
12:31:50.017: flash, block=12, bs=1024, auto=1
12:31:50.034: flash, block=13, bs=1024, auto=1
12:31:50.036: flash, block=14, bs=1024, auto=1
12:31:50.053: flash, block=15, bs=1024, auto=1
12:31:50.055: flash, block=16, bs=1024, auto=1
12:31:50.072: flash, block=17, bs=1024, auto=1
12:31:50.073: flash, block=18, bs=1024, auto=1
12:31:50.091: flash, block=19, bs=1024, auto=1
12:31:50.093: flash, block=20, bs=1024, auto=1
12:31:50.095: flash, block=21, bs=1024, auto=1
12:31:50.112: flash, block=22, bs=1024, auto=1
12:31:50.113: flash, block=23, bs=1024, auto=1
12:31:50.131: flash, block=24, bs=1024, auto=1
12:31:50.132: flash, block=25, bs=1024, auto=1
12:31:50.149: flash, block=26, bs=1024, auto=1
12:31:50.151: flash, block=27, bs=1024, auto=1
12:31:50.168: flash, block=28, bs=1024, auto=1
12:31:50.170: flash, block=29, bs=1024, auto=1
12:31:50.173: sending reboot
12:31:50.190: begin wait_until_offline
12:31:50.290: HID/linux: something changed, try reading a descriptor
12:31:50.291: HID/linux: Device was just disconnected
12:31:50.291: offline, waited 2
12:31:50.291: end operation, total time = 0.626 seconds
12:31:50.291: set background IMG_REBOOT_OK
12:31:50.294: redraw timer set, image 14 to show for 1200 ms
12:31:51.494: redraw, image 9
12:31:56.942: Verbose Info event
 
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: Selection_001.jpg

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 ):

Selection_006.jpg
 
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 really appreciate your help,

Ubuntu 16.04 Lts
uname -a:
4.4.0-104-generic #127-Ubuntu SMP Mon Dec 11 12:16:42 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
 
Is there a hub between Teensy and your PC?

Really, gotta admit, I'm guessing here. This just doesn't make much sense, and not sure there's anything I could do about it.
 
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.
 
Just tried that on my MATE machine....same error, I did verify that AFTER error, THEN Teensy bootloader uploads sketch
 

Attachments

  • Screenshot at 2018-01-22 14-10-01.jpg
    Screenshot at 2018-01-22 14-10-01.jpg
    98.6 KB · Views: 140
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 :(
 
Last edited:
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. :mad: Stupid regression if this is the issue.

https://unix.stackexchange.com/questions/446088/how-to-prevent-dtr-on-open-for-cdc-acm
Does the Teensy do this too?
Code:
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.
 
As far as I know it is a real Teensy 3.6. I ran across that message when tracing down the dtr/rts error message in the kernel dmesg output.
 
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?
 
Status
Not open for further replies.
Back
Top