Forum Rule: Always post complete source code & details to reproduce any issue!
Page 1 of 2 1 2 LastLast
Results 1 to 25 of 26

Thread: Teensy Loader Ubuntu problem

  1. #1
    Junior Member
    Join Date
    Jan 2018
    Posts
    16

    Teensy Loader Ubuntu problem

    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

  2. #2
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    2,385
    try to reinstall the Teensy udev rules?

  3. #3
    Junior Member
    Join Date
    Jan 2018
    Posts
    16
    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.

  4. #4
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,937
    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?

  5. #5
    Junior Member
    Join Date
    Jan 2018
    Posts
    16
    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: auton
    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: "auton"
    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

  6. #6
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,937
    Quote Originally Posted by adim View Post
    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)

  7. #7
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,937
    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.

  8. #8
    Junior Member
    Join Date
    Jan 2018
    Posts
    16
    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: Click image for larger version. 

Name:	Selection_001.jpg 
Views:	33 
Size:	111.6 KB 
ID:	12693

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

    Click image for larger version. 

Name:	Selection_006.jpg 
Views:	37 
Size:	120.2 KB 
ID:	12694

  9. #9
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,937
    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.

  10. #10
    Junior Member
    Join Date
    Jan 2018
    Posts
    16
    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

  11. #11
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,937
    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.

  12. #12
    Junior Member
    Join Date
    Jan 2018
    Posts
    16
    There is an extension usb cable, i will remove it and try again

  13. #13
    Junior Member
    Join Date
    Jan 2018
    Posts
    16
    Same problem...

  14. #14
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,931
    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

  15. #15
    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 <(")

  16. #16
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,937
    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.

  17. #17
    Just tried that on my MATE machine....same error, I did verify that AFTER error, THEN Teensy bootloader uploads sketch
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	Screenshot at 2018-01-22 14-10-01.jpg 
Views:	32 
Size:	98.6 KB 
ID:	12705  

  18. #18
    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

  19. #19
    Junior Member
    Join Date
    Apr 2019
    Posts
    1
    Quote Originally Posted by PaulStoffregen View Post
    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 by bomlee; 04-04-2019 at 01:31 PM.

  20. #20
    Member
    Join Date
    May 2018
    Location
    Land between two rivers
    Posts
    42
    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.

  21. #21
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,937
    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.

  22. #22
    Member
    Join Date
    May 2018
    Location
    Land between two rivers
    Posts
    42
    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.

    https://unix.stackexchange.com/quest...en-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.

  23. #23
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,937
    Quote Originally Posted by Eka View Post
    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.

  24. #24
    Member
    Join Date
    May 2018
    Location
    Land between two rivers
    Posts
    42
    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.

  25. #25
    Member
    Join Date
    May 2018
    Location
    Land between two rivers
    Posts
    42
    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?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •