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

Thread: Looking for some clues hard Linux crash using Ty Commander

  1. #26
    Senior Member
    Join Date
    May 2022
    Posts
    110
    Quote Originally Posted by defragster View Post
    With a saved .HEX file - restart the system.

    Open Teensy.exe the loader, and use the menu to open the hex file.

    Plug in the Teensy and push the Button.

    Perhaps open Help / Verbose info to watch Teensy captured traffic.

    Wait for crash ... or push button on some interval.

    This would be the minimal base upload interaction.
    Thanks, that is helpful. For Linux, where might the loader reside, and what is it called? There aren't any *.exe's in Linux. Need a clue where to find it!

    How could output be redirected to file? and saved often. These crashes are bear...

    Edit:
    I found: teensy at /arduino-1.8.19/hardware/tools, is that the one?
    What do you mean by restart the system? Exit Arduino and Teensyloader (or teensy?) or a good solid reboot?
    Last edited by clinker8; 08-05-2022 at 05:07 PM. Reason: Added questions

  2. #27
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    10,771
    Yes that is the executable

  3. #28
    Senior Member
    Join Date
    May 2022
    Posts
    110
    One more step figured out.

    In a linux based system (Ubuntu-like) where would the hex file be found? (The one we wish to burn to the Teensy.) Would that be in /tmp? I searched my whole drive and can't find this file. Does Arduino delete it after exit? Or does it persist until a reboot empties /tmp?

  4. #29
    Senior Member
    Join Date
    Apr 2020
    Location
    DFW area in Texas
    Posts
    416
    Quote Originally Posted by clinker8 View Post
    In a linux based system (Ubuntu-like) where would the hex file be found? (The one we wish to burn to the Teensy.)
    [ Knowledge from the Windows environment . . . hopefully this info is the same for linux ]

    Make sure that TeensyLoader is running. Enable "Verbose Info" under the "Help" menu of the TeensyLoader. When you build your sketch in the Arduino IDE, the TeensyLoader verbose log will report where the HEX file is stored. Note that the HEX file is only there until the IDE is closed. Use "Export compiled Binary" from the "Sketch" menu (also Ctrl+Alt+S) in the IDE to preserve your HEX.

    Hope that helps . . .

    Mark J Culross
    KD5RXT

  5. #30
    Senior Member
    Join Date
    May 2022
    Posts
    110
    Quote Originally Posted by kd5rxt-mark View Post
    [ Knowledge from the Windows environment . . . hopefully this info is the same for linux ]

    Make sure that TeensyLoader is running. Enable "Verbose Info" under the "Help" menu of the TeensyLoader. When you build your sketch in the Arduino IDE, the TeensyLoader verbose log will report where the HEX file is stored. Note that the HEX file is only there until the IDE is closed. Use "Export compiled Binary" from the "Sketch" menu (also Ctrl+Alt+S) in the IDE to preserve your HEX.

    Hope that helps . . .

    Mark J Culross
    KD5RXT
    Thank you very much! Yes, that is very helpful. Now to keep the computer running long enough to export the binary. Last time I had 10 minutes before the computer hard crashed. Maybe I will get lucky? again.

  6. #31
    Senior Member
    Join Date
    Apr 2020
    Location
    DFW area in Texas
    Posts
    416
    Quote Originally Posted by clinker8 View Post
    Now to keep the computer running long enough to export the binary. Last time I had 10 minutes before the computer hard crashed. Maybe I will get lucky? again.
    Glad I could provide some help.

    Now, from what you've described earlier, as long as you haven't tried to program/load your Teensy, you shouldn't have to worry about racing time against any impending linux crashes (10 minutes or otherwise), right ?!?

    Also, not sure if it was obvious and/or clear earlier, but if you have not initiated an Arduino "build" after opening the Arduino IDE, pressing the program button on the Teensy *will not* succeed in loading anything (as there is no HEX file for the TeensyLoader to load) !!

    Mark J Culross
    KD5RXT

  7. #32
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    16,217
    Quote Originally Posted by kd5rxt-mark View Post
    Glad I could provide some help.

    Now, from what you've described earlier, as long as you haven't tried to program/load your Teensy, you shouldn't have to worry about racing time against any impending linux crashes (10 minutes or otherwise), right ?!?

    Also, not sure if it was obvious and/or clear earlier, but if you have not initiated an Arduino "build" after opening the Arduino IDE, pressing the program button on the Teensy *will not* succeed in loading anything (as there is no HEX file for the TeensyLoader to load) !!

    Mark J Culross
    KD5RXT
    With the SAVED HEX file safe in a known location the Teensy Loader can 'File / Open HEX File' - that was the context of Post #25

    Sorry, did not document the IDE : 'Sketch / Export compiled Binary' { Ctrl + Alt + S } that places a copy of the compiled HEX in the Sketch Folder where it will survive IDE closure or machine restart.
    - Perhaps wrongly assumed linux user could locate and copy the HEX from a Verify or other build from the TEMP space. Usually during build if 'Verbose' console output is shown the location of the HEX is indicated. Though Ctrl+Alt+S {windows keys} would be quicker and save the HEX in one step before machine might crash.
    - Also, Ctrl+K will open 'Show sketch folder'

    >> This could be done in one step - then wait 10+ minutes to see if doing that IDE Build is what crashes the machine

    But, with that done Teensy pointed there will then be ready to upload that HEX on a button press.

    >> Then this could be done after machine does or does not crash and then wait 10+ minutes to see if this causes a crash

  8. #33
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    10,771
    Again as another reference you might try the teensy_loader_cli: https://github.com/PaulStoffregen/teensy_loader_cli

    Which you would need to build on your machine and see if it also causes you to crash or not.

  9. #34
    Senior Member
    Join Date
    May 2022
    Posts
    110
    Thanks for everyone's suggestions. Think I will try a virtual machine and the teensy loader. I'm hoping that the vm crashes, not my laptop. Ultimately, it would seem that using the cli would eliminate any gui as a possible issue. Using the cli would also make it easier to script.

    How many times can one program a Teensy? If I write a decent script, it would seem it is possible to exceed the max number of flashes.

    Is there a dummy interface that can respond to the teensy_loader_cli, rather than a real teensy? Guess another way to ask this is - is there a teensy emulator that the cli can talk to, and keep the cli happy?

    I am guessing that the issue is not in the Teensy, but more in my laptop hardware or the kernel driving my hardware.

  10. #35
    Senior Member
    Join Date
    May 2022
    Posts
    110
    Set up an Ubuntu 20.04 VM. Looking to attach the USB port. In $ lsusb, I see something showing up as Van Ooijen Technische Informatica Teensyduino Serial. Hoping that is the correct device to connect to.
    Code:
    $ lsusb
    Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
    Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 002 Device 004: ID 045b:0210 Hitachi, Ltd 
    Bus 002 Device 003: ID 045b:0210 Hitachi, Ltd 
    Bus 002 Device 002: ID 05e3:0617 Genesys Logic, Inc. USB3.0 Hub
    Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
    Bus 001 Device 007: ID 5986:9102 Acer, Inc BisonCam,NB Pro
    Bus 001 Device 005: ID 046d:c52b Logitech, Inc. Unifying Receiver
    Bus 001 Device 011: ID 16c0:0483 Van Ooijen Technische Informatica Teensyduino Serial
    Bus 001 Device 008: ID 8087:0026 Intel Corp. AX201 Bluetooth
    Bus 001 Device 010: ID 045b:0209 Hitachi, Ltd 
    Bus 001 Device 009: ID 045b:0209 Hitachi, Ltd 
    Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. Hub
    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
    Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    When I connected to that, (while in Arduino in the VM) both the VM and my laptop crashed. Same symptoms as before, mouse and keyboard freeze, then the power turns off. Man, what a mess! Like beating your head against the wall.

  11. #36
    Senior Member
    Join Date
    May 2022
    Posts
    110
    Can't get the usb to stay connected in the vm. The changing modes of usb during programming are confusing the QEMU/KVM. I keep seeing the usb device disappearing.

    Do I use a) Teensy Ports /dev/ttyACM0 Serial (Teensy 4.1) or
    b) Serial Ports /dev/ttyACM0 (Teensy) ? <-- think it is b)

    Jeepers this is confusing. Sometimes I get complaints from Arduino that the the rules are wrong (they aren't), or that modemmanager is interfering. Modemmanager has been removed. How can it be interfering if I did an apt remove?

    Here is a log file of the attempted programming.

    Code:
    16:36:39.725 (post_compile 1): Begin, version=1.57
    16:36:39.829 (loader): Teensy Loader 1.57, begin program
    16:36:39.835 (loader): Listening for remote control on port 3149
    16:36:39.835 (loader): initialized, showing main window
    16:36:39.926 (loader): remote connection 15 opened
    16:36:39.926 (post_compile 1): Sending command: comment: Teensyduino 1.57 - LINUX64 (teensy_post_compile)
    16:36:39.926 (loader): remote cmd from 15: "comment: Teensyduino 1.57 - LINUX64 (teensy_post_compile)"
    16:36:39.927 (loader): remote cmd from 15: "status"
    16:36:39.928 (post_compile 1): Status: 0, 0, 0, 0, 0, 0, /tmp/arduino_build_149777/, Blink.ino.hex
    16:36:39.928 (post_compile 1): Sending command: dir:/tmp/arduino_build_270787/
    16:36:39.928 (loader): remote cmd from 15: "dir:/tmp/arduino_build_270787/"
    16:36:39.928 (post_compile 1): Sending command: file:Blink.ino.hex
    16:36:39.928 (loader): remote cmd from 15: "file:Blink.ino.hex"
    16:36:39.964 (loader): File "/tmp/arduino_build_270787/Blink.ino.hex", 22528 bytes
    16:36:39.964 (loader): File "Blink.ino.hex". 22528 bytes
    16:36:39.976 (loader): remote cmd from 15: "status"
    16:36:39.976 (post_compile 1): Status: 1, 0, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:39.976 (post_compile 1): Sending command: auto:on
    16:36:39.976 (loader): remote cmd from 15: "auto:on"
    16:36:39.977 (post_compile 1): Disconnect
    16:36:39.988 (loader): remote connection 15 closed
    16:36:40.011 (post_compile 2): Begin, version=1.57
    16:36:40.011 (loader): remote connection 15 opened
    16:36:40.011 (post_compile 2): Sending command: comment: Teensyduino 1.57 - LINUX64 (teensy_post_compile)
    16:36:40.011 (loader): remote cmd from 15: "comment: Teensyduino 1.57 - LINUX64 (teensy_post_compile)"
    16:36:40.011 (loader): remote cmd from 15: "status"
    16:36:40.011 (post_compile 2): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:40.011 (post_compile 2): Disconnect
    16:36:40.025 (loader): remote connection 15 closed
    16:36:40.025 (post_compile 3): Running teensy_reboot: /home/bruce/Apps/arduino-1.8.19/hardware/teensy/../tools/teensy_reboot
    16:36:40.025 (loader): remote connection 15 opened
    16:36:40.025 (loader): remote connection 15 closed
    16:36:40.026 (reboot 4): Begin, version=1.57
    16:36:40.026 (reboot 4): location = /dev/ttyACM0
    16:36:40.026 (reboot 4): portlabel = /dev/ttyACM0
    16:36:40.026 (reboot 4): portprotocol = serial
    16:36:40.026 (reboot 4): Serial device /dev/ttyACM0 will be tried first
    16:36:40.032 (loader): remote connection 15 opened
    16:36:40.034 (reboot 4): add device: subsys=usb, type=usb_device, location=/sys/devices/pci0000:00/0000:00:02.2/0000:03:00.0/usb1/1-4
    16:36:40.034 (reboot 4):   devnode=/dev/bus/usb/001/012, subsystem=usb, ifacenum=-1
    16:36:40.034 (reboot 4): add child:  subsys=usb, type=usb_interface, location=/sys/devices/pci0000:00/0000:00:02.2/0000:03:00.0/usb1/1-4/1-4:1.0
    16:36:40.034 (reboot 4):   parent location=/sys/devices/pci0000:00/0000:00:02.2/0000:03:00.0/usb1/1-4
    16:36:40.034 (reboot 4):   model=37 (Teensy 4.1)
    16:36:40.034 (reboot 4): add child:  subsys=tty, type=(null), location=/sys/devices/pci0000:00/0000:00:02.2/0000:03:00.0/usb1/1-4/1-4:1.0/tty/ttyACM0
    16:36:40.034 (reboot 4):   parent location=/sys/devices/pci0000:00/0000:00:02.2/0000:03:00.0/usb1/1-4
    16:36:40.034 (reboot 4):   devnode=/dev/ttyACM0, subsystem=tty, ifacenum=0
    16:36:40.034 (reboot 4): add child:  subsys=usb, type=usb_interface, location=/sys/devices/pci0000:00/0000:00:02.2/0000:03:00.0/usb1/1-4/1-4:1.1
    16:36:40.034 (reboot 4):   parent location=/sys/devices/pci0000:00/0000:00:02.2/0000:03:00.0/usb1/1-4
    16:36:40.044 (reboot 4): usb scan found 1 devices
    16:36:40.044 (reboot 4): found Teensy Loader, version 1.57
    16:36:40.044 (reboot 4): Sending command: show:arduino_attempt_reboot
    16:36:40.044 (loader): remote cmd from 15: "show:arduino_attempt_reboot"
    16:36:40.044 (loader): got request to show arduino rebooting message
    16:36:40.048 (reboot 4): Sending command: comment: Teensyduino 1.57 - LINUX64 (teensy_reboot)
    16:36:40.048 (loader): remote cmd from 15: "comment: Teensyduino 1.57 - LINUX64 (teensy_reboot)"
    16:36:40.048 (loader): remote cmd from 15: "status"
    16:36:40.048 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:40.048 (reboot 4): do_reset (serial) /dev/ttyACM0
    16:36:40.050 (loader): remote cmd from 15: "status"
    16:36:40.050 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:40.050 (reboot 4): status read, retry 0
    16:36:40.151 (loader): remote cmd from 15: "status"
    16:36:40.151 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:40.151 (reboot 4): status read, retry 1
    16:36:40.252 (loader): remote cmd from 15: "status"
    16:36:40.252 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:40.252 (reboot 4): status read, retry 2
    16:36:40.353 (loader): remote cmd from 15: "status"
    16:36:40.353 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:40.353 (reboot 4): status read, retry 3
    16:36:40.454 (loader): remote cmd from 15: "status"
    16:36:40.454 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:40.454 (reboot 4): status read, retry 4
    16:36:40.555 (loader): remote cmd from 15: "status"
    16:36:40.555 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:40.555 (reboot 4): status read, retry 5
    16:36:40.655 (loader): remote cmd from 15: "status"
    16:36:40.655 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:40.655 (reboot 4): status read, retry 6
    16:36:40.756 (loader): remote cmd from 15: "status"
    16:36:40.756 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:40.756 (reboot 4): status read, retry 7
    16:36:40.856 (loader): remote cmd from 15: "status"
    16:36:40.857 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:40.857 (reboot 4): status read, retry 8
    16:36:40.957 (loader): remote cmd from 15: "status"
    16:36:40.958 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:40.958 (reboot 4): status read, retry 9
    16:36:41.058 (loader): remote cmd from 15: "status"
    16:36:41.059 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:41.059 (reboot 4): status read, retry 10
    16:36:41.159 (loader): remote cmd from 15: "status"
    16:36:41.160 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:41.160 (reboot 4): status read, retry 11
    16:36:41.260 (loader): remote cmd from 15: "status"
    16:36:41.261 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:41.261 (reboot 4): status read, retry 12
    16:36:41.361 (loader): remote cmd from 15: "status"
    16:36:41.362 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:41.362 (reboot 4): status read, retry 13
    16:36:41.462 (loader): remote cmd from 15: "status"
    16:36:41.463 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:41.463 (reboot 4): status read, retry 14
    16:36:41.563 (loader): remote cmd from 15: "status"
    16:36:41.564 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:41.564 (reboot 4): status read, retry 15
    16:36:41.664 (loader): remote cmd from 15: "status"
    16:36:41.665 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:41.665 (reboot 4): status read, retry 16
    16:36:41.765 (loader): remote cmd from 15: "status"
    16:36:41.766 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:41.766 (reboot 4): status read, retry 17
    16:36:41.866 (loader): remote cmd from 15: "status"
    16:36:41.867 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:41.867 (reboot 4): status read, retry 18
    16:36:41.968 (loader): remote cmd from 15: "status"
    16:36:41.968 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:41.968 (reboot 4): status read, retry 19
    16:36:42.069 (loader): remote cmd from 15: "status"
    16:36:42.069 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:42.069 (reboot 4): status read, retry 20
    16:36:42.170 (loader): remote cmd from 15: "status"
    16:36:42.170 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:42.170 (reboot 4): status read, retry 21
    16:36:42.271 (loader): remote cmd from 15: "status"
    16:36:42.271 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:42.271 (reboot 4): status read, retry 22
    16:36:42.372 (loader): remote cmd from 15: "status"
    16:36:42.372 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:42.372 (reboot 4): status read, retry 23
    16:36:42.473 (loader): remote cmd from 15: "status"
    16:36:42.473 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:42.473 (reboot 4): status read, retry 24
    16:36:42.574 (loader): remote cmd from 15: "status"
    16:36:42.574 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:42.574 (reboot 4): status read, retry 25
    16:36:42.675 (loader): remote cmd from 15: "status"
    16:36:42.675 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:42.675 (reboot 4): status read, retry 26
    16:36:42.776 (loader): remote cmd from 15: "status"
    16:36:42.776 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:42.776 (reboot 4): status read, retry 27
    16:36:42.877 (loader): remote cmd from 15: "status"
    16:36:42.877 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:42.877 (reboot 4): status read, retry 28
    16:36:42.978 (loader): remote cmd from 15: "status"
    16:36:42.978 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:42.978 (reboot 4): status read, retry 29
    16:36:43.079 (loader): remote cmd from 15: "status"
    16:36:43.079 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:43.079 (reboot 4): status read, retry 30
    16:36:43.180 (loader): remote cmd from 15: "status"
    16:36:43.180 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:43.180 (reboot 4): status read, retry 31
    16:36:43.281 (loader): remote cmd from 15: "status"
    16:36:43.282 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:43.282 (reboot 4): status read, retry 32
    16:36:43.382 (loader): remote cmd from 15: "status"
    16:36:43.383 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:43.383 (reboot 4): status read, retry 33
    16:36:43.483 (loader): remote cmd from 15: "status"
    16:36:43.484 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:43.484 (reboot 4): status read, retry 34
    16:36:43.584 (loader): remote cmd from 15: "status"
    16:36:43.585 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:43.585 (reboot 4): status read, retry 35
    16:36:43.685 (loader): remote cmd from 15: "status"
    16:36:43.686 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:43.686 (reboot 4): status read, retry 36
    16:36:43.786 (loader): remote cmd from 15: "status"
    16:36:43.787 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:43.787 (reboot 4): status read, retry 37
    16:36:43.887 (loader): remote cmd from 15: "status"
    16:36:43.887 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:43.887 (reboot 4): status read, retry 38
    16:36:43.988 (loader): remote cmd from 15: "status"
    16:36:43.988 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:43.988 (reboot 4): status read, retry 39
    16:36:44.089 (loader): remote cmd from 15: "status"
    16:36:44.089 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:44.089 (reboot 4): status read, retry 40
    16:36:44.190 (loader): remote cmd from 15: "status"
    16:36:44.190 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:44.190 (reboot 4): status read, retry 41
    16:36:44.291 (loader): remote cmd from 15: "status"
    16:36:44.291 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:44.291 (reboot 4): status read, retry 42
    16:36:44.392 (loader): remote cmd from 15: "status"
    16:36:44.392 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:44.392 (reboot 4): status read, retry 43
    16:36:44.493 (loader): remote cmd from 15: "status"
    16:36:44.493 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:44.493 (reboot 4): status read, retry 44
    16:36:44.594 (loader): remote cmd from 15: "status"
    16:36:44.594 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:44.594 (reboot 4): status read, retry 45
    16:36:44.695 (loader): remote cmd from 15: "status"
    16:36:44.695 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:44.695 (reboot 4): status read, retry 46
    16:36:44.796 (loader): remote cmd from 15: "status"
    16:36:44.796 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:44.796 (reboot 4): status read, retry 47
    16:36:44.897 (loader): remote cmd from 15: "status"
    16:36:44.897 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:44.897 (reboot 4): status read, retry 48
    16:36:44.998 (loader): remote cmd from 15: "status"
    16:36:44.998 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:44.998 (reboot 4): status read, retry 49
    16:36:45.099 (loader): remote cmd from 15: "status"
    16:36:45.099 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:45.099 (reboot 4): status read, retry 50
    16:36:45.200 (loader): remote cmd from 15: "status"
    16:36:45.200 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:45.200 (reboot 4): status read, retry 51
    16:36:45.301 (loader): remote cmd from 15: "status"
    16:36:45.301 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:45.301 (reboot 4): status read, retry 52
    16:36:45.402 (loader): remote cmd from 15: "status"
    16:36:45.402 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:45.402 (reboot 4): status read, retry 53
    16:36:45.503 (loader): remote cmd from 15: "status"
    16:36:45.503 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:45.503 (reboot 4): status read, retry 54
    16:36:45.604 (loader): remote cmd from 15: "status"
    16:36:45.605 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:45.605 (reboot 4): status read, retry 55
    16:36:45.705 (loader): remote cmd from 15: "status"
    16:36:45.706 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:45.706 (reboot 4): status read, retry 56
    16:36:45.806 (loader): remote cmd from 15: "status"
    16:36:45.807 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:45.807 (reboot 4): status read, retry 57
    16:36:45.908 (loader): remote cmd from 15: "status"
    16:36:45.908 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:45.908 (reboot 4): status read, retry 58
    16:36:46.009 (loader): remote cmd from 15: "status"
    16:36:46.009 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:46.009 (reboot 4): status read, retry 59
    16:36:46.109 (loader): remote cmd from 15: "status"
    16:36:46.110 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:46.110 (reboot 4): status read, retry 60
    16:36:46.210 (loader): remote cmd from 15: "status"
    16:36:46.211 (reboot 4): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_270787/, Blink.ino.hex
    16:36:46.211 (reboot 4): status read, retry 61
    16:36:46.311 (reboot 4): Teensy did not respond to a USB-based request to automatically reboot.
    16:36:46.317 (loader): remote connection 15 closed
    16:37:47.080 (loader): Verbose Info event
    16:38:34.042 (loader): Log saved to the file '/home/bruce/Documents/log2.txt'.
    Unless I power cycle the Teensy, it stays stuck in the bright RED light mode.

  12. #37
    Senior Member
    Join Date
    May 2022
    Posts
    110
    Built the teensy_loader_cli and not sure if I am quite invoking it correctly.
    Code:
    ./teensy_loader_cli --mcu=TEENSY41 -wv blink_slow_Teensy41.hex
    Unfortunately something is set up wrong in the vm. All I get is a continuous RED light after pressing the reset button.
    Code:
    ~/Apps/teensy_loader_cli-master$ ./prog_teensy41.sh 
    Teensy Loader, Command Line, Version 2.2
    Read "blink_slow_Teensy41.hex": 22528 bytes, 0.3% usage
    Waiting for Teensy device...
     (hint: press the reset button)
    Not encouraging at the moment... Running Ubuntu 20.04.2 in a VM. (virt-machine, which is QEMU/KVM) While the RED led is on, lsusb gives:
    Code:
    $ lsusb
    Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
    Bus 001 Device 013: ID 16c0:0483 Van Ooijen Technische Informatica Teensyduino Serial
    Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd QEMU USB Tablet
    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    But Teensy Loader CLI is just hanging there. It is not timing out, nor reporting errors. I pressed the reset button for a couple seconds, and lsusb no longer sees the usb device.

    I see something, but don't know if it is important. In teensy_open the device is called out as:
    Code:
    static usb_dev_handle *libusb_teensy_handle = NULL;
    
    int teensy_open(void)
    {
    	teensy_close();
    	libusb_teensy_handle = open_usb_device(0x16C0, 0x0478);
    	if (libusb_teensy_handle) return 1;
    	return 0;
    }
    But on my vm, the usb device is called:
    Code:
    Bus 001 Device 013: ID 16c0:0483 Van Ooijen Technische Informatica Teensyduino Serial
    Is this significant?

  13. #38
    Senior Member
    Join Date
    May 2022
    Posts
    110
    If I use 0x483, and recompile, Teensy Loader shows the following:
    Code:
    $ ./prog_teensy41.sh 
    Teensy Loader, Command Line, Version 2.2
    Read "blink_slow_Teensy41.hex": 22528 bytes, 0.3% usage
    Found HalfKay Bootloader
    Programming.error writing to Teensy
    So I will put it back to the original. In my case with the original value, in the vm, the loader never returns and the RED led stays on continuously.
    I tried a soft reset and that didn't work either.
    Not sure that usb devices work the same in a vm. I suspect this is an issue.

  14. #39
    Senior Member
    Join Date
    May 2022
    Posts
    110
    No version of programming a Teensy 4.1 seems to work under the vm. Rather disappointed. The gui method simply says there is an error.
    The cli version simply hangs in a loop. In both cases, I pressed the "reset" button.
    $ lsusb is still showing the Teensyduino Serial present.
    After 10 minutes, I am still waiting for the Teensy...

    Wish I knew what was happening.

  15. #40
    Senior Member
    Join Date
    May 2022
    Posts
    110
    I checked for modemmanager, which I had previously removed, and it was present in the vm. So I ran $ sudo apt remove --purge modemmanager. However, this did not change the behavior of the teensy loader. It still hangs and never programs the device. I will reboot the vm and try again. No difference, same hanging. Never programs the device. Can't even program the canned blink file "blink_slow_Teensy41.hex" in teensy_loader_cli.

    $ ./teensy_loader_cli --mcu=TEENSY41 -v -w blink_slow_Teensy41.hex doesn't work

    All I get is:
    $ ./teensy_loader_cli --mcu=TEENSY41 -v -w blink_slow_Teensy41.hex
    Teensy Loader, Command Line, Version 2.2
    Read "blink_slow_Teensy41.hex": 22528 bytes, 0.3% usage
    Waiting for Teensy device...
    (hint: press the reset button)

    Just a bright red led. The vm (or the cli sw) is not handling the usb transactions the same as a real machine. Dead in the water...

    I have tried almost everything at this point. Worked with the distribution, my laptop manufacturer, and tried a vm, This just plain stinks. I can't develop Teensy sw on my normal mainline computer because something about the programming sequence turns my computer off. I have found NO workable solutions.

  16. #41
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    26,563
    Virtual machines cause a lot of problems. They tend to work fine for "normal" software. But for hardware access, there is a pretty incredible amount of emulation code between you and the real hardware.

  17. #42
    Senior Member
    Join Date
    May 2022
    Posts
    110
    Quote Originally Posted by PaulStoffregen View Post
    Virtual machines cause a lot of problems. They tend to work fine for "normal" software. But for hardware access, there is a pretty incredible amount of emulation code between you and the real hardware.
    Was hoping to use a virtual machine to isolate me from system crashes. Programming my Teensy seems to cause system crashes which turn off my laptop power supply. The OS leaves no significant record of what happens during the crash. Just a usb transaction and some random time later the computer turns off. It is unacceptable for this to happen.

    I have to abandon something, either Teensy or my laptop, since they just aren't compatible anymore. Seems like a bad choice to have to make. I have spent (wasted) well over 100's of hours on this and am very discouraged. The Teensy is a great platform, but this puts a large damper on my enthusiasm.

  18. #43
    Senior Member
    Join Date
    May 2022
    Posts
    110
    Built the loader cli for the real machine. As expected, it seems to work fine. (This time.) I will try to figure out a way to get this into my work process. Compiling to hex seems to pop up the teensyloadergui. It interferes with the cli. Guess I need to kill the loadergui and then program with the cli. Don't know if this will help in the slightest.

    Can someone point me to how to build Teensy on Arduino using a make file? I don't know if Arduino is the issue (or its gui, or the teensyloadgui) but I can deal with editing in an external editor and compiling with a make file. Old school, but workable.

  19. #44
    Senior Member
    Join Date
    Apr 2020
    Location
    DFW area in Texas
    Posts
    416
    As yet another data point, eliminating all of the middle-man interference introduced by your VM environment, what about booting from a "live CD/DVD" & trying to program your Teensy from that, as the closest thing to your installed linux environment, without risking any consequences from a "crash" ?? By experimenting with the live CD/DVD environment, you should be removing the hard drive from the equation (as one possible source of your crashes). This might also help you to narrow down whether the problems you are experiencing are a result of hardware, software, or some unfortunate combo of the two . . .

    Mark J Culross
    KD5RXT

  20. #45
    Senior Member
    Join Date
    May 2022
    Posts
    110
    Made a script for the teensy_loader_cli with an argument for the file name. Makes it a little easier to use, instead of typing out all the arguments.
    Name of the script is progteensy. Make it executable.
    Code:
    ~/Apps/teensy_loader_cli-master/teensy_loader_cli --mcu=TEENSY41 -w -v $1
    This way, all you type is ./progteensy yourfile.hex Works in a non-virtual environment.

  21. #46
    Senior Member
    Join Date
    Feb 2015
    Location
    Finland
    Posts
    262
    I personally would suspect some kind of hardware issue, possibly related to a ground loop, or a very hardware-buggy USB controller chip (especially if early USB 3.0 one).
    (My bet is that the powered USB 3 hub draws a significant current spike when the device is reset, and this causes a brown-out in your computer, hard-crashing it. I'm not very lucky in betting, however.)

    Note that although you use an USB 3 port, Teensies actually use the USB 2 controller in it all USB 3.x ports have separate USB 3 and USB 2 controllers, albeit possibly integrated to the same chip.
    Early USB 3 implementations did have issues with USB 1.1 devices (like ATmega32u4 and AT90USB1286 on Teensy 2.0 and 2.0++) that were easiest to fix by using an USB 2 hub. I do not recall the exact details (and they don't really matter here), but it really was these USB 3 chips at fault, since I have not seen these issues in more recent USB 3 host controllers, with no changes in Teensies.

    Have you considered using a cheap ADuM3160-based USB isolator? The $10 eBay clones from China are fine, I use them myself, since they're direct implementations of the ADuM3160 datasheet; only check the isolated DC-DC converter used on them to see their maximum current capability. The commonly used B505S-1W only provides 200mA = 0.2A.

    Or, you can get the Olimex USB ISO, which is almost the same ADuM3160 implementation, except limited to full speed only (12 Mbit/s) no low/full speed switch as is on those eBay cheapies , but including an 8-15 VDC input that is regulated to 5 VDC for the Teensy/isolated device. You do need to use an isolated AC-DC converter/wall wart, like European two-pronged wall warts, since this DC input is isolated only from the host machine, but not from the Teensy/device.
    Mouser carries the Olimex, plus several others (all based on ADuM3160, I believe), but I'm not sure how much current they provide to the device.
    Digikey carries the Murata NMUSB202MC-R7 industrial module (a bit more expensive, around $30-40?) that works similarly, but does need 5V input for the Teensy/isolated device, for example from an isolated USB wall wart.

    These do not work as USB 3 isolators, but they do work in the sense that USB full speed (12 Mbit/s) does work across them, and that's what Teensies need. That is, these isolators "downgrade" the USB connection to USB 1.1/2.0, at low speed or full speed (12 Mbit/s); NOT at high speed (480 Mbit/s Teensy 4.x are capable of they do downgrade the speed automagically, though) or USB 3 speeds.

    I habitually use these, and can confirm that Teensy 2.0++, LC, 3.0, 3.1, 3.2, 4.0, and 4.1 all work fine and can be programmed using one (since I've done exactly that), and that 4.0 and 4.1 automatically limit to 12 Mbit/s ("full speed") without any user intervention. In other words, reprogramming them will work over the isolator, although it can take a bit longer on Teensy 4.x.

    (I am waiting for TI USBISO211 chips to become available, because when used with Teensy 4.0 and 4.1, they allow high-speed USB 2.0, 480 Mbit/s, at roughly the same price as ADuM3160. Darn chipageddon.. The reason I use these isolators is that although I'm a pretty good programmer, I'm very much an Uncle Bumblefinger wrt. electronics, and these isolators keep my computers safe from my, uh, bumbling experiments.)

  22. #47
    Senior Member
    Join Date
    May 2022
    Posts
    110
    Quote Originally Posted by kd5rxt-mark View Post
    As yet another data point, eliminating all of the middle-man interference introduced by your VM environment, what about booting from a "live CD/DVD" & trying to program your Teensy from that, as the closest thing to your installed linux environment, without risking any consequences from a "crash" ?? By experimenting with the live CD/DVD environment, you should be removing the hard drive from the equation (as one possible source of your crashes). This might also help you to narrow down whether the problems you are experiencing are a result of hardware, software, or some unfortunate combo of the two . . .

    Mark J Culross
    KD5RXT
    Can you install sw and run in a live system? I guess it would remove all other "rogue" software on the system... Kind of painful to go through all the configuration for a one shot deal, but maybe worth it.

    The cli sometimes fails programming Teensy. No idea why, but it (knocks on wood) hasn't crashed yet.

  23. #48
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    26,563
    Quote Originally Posted by clinker8 View Post
    Can someone point me to how to build Teensy on Arduino using a make file?
    Maybe try using Arduino CLI. It's not as lightweight as a makefile, but you do get excellent compatibility. Newest Teensyduino 1.57 packages for CLI / IDE2 are supposed to detect if you're running headless and avoid launching the GUI-based Teensy Loader.

  24. #49
    Senior Member
    Join Date
    May 2022
    Posts
    110
    Quote Originally Posted by Nominal Animal View Post
    I personally would suspect some kind of hardware issue, possibly related to a ground loop, or a very hardware-buggy USB controller chip (especially if early USB 3.0 one).
    (My bet is that the powered USB 3 hub draws a significant current spike when the device is reset, and this causes a brown-out in your computer, hard-crashing it. I'm not very lucky in betting, however.)
    I wouldn't be surprised if this were the case. I have seen the crash problem on both the active hub and a direct connect, so I think it might be the laptop USB controller chip. The hub is powered by a 4A power supply with no ground pin to the mains. The laptop and hub are both plugged into a common grounded power strip. The hub is isolated from the laptop by plugging the active hub into a small passive usb3 hub. I learned this trick from my Raspberry Pi 4 experiences, where current surges would disrupt the RPI4. The passive hub between the RPI4 and the active hub fixed that problem.

    I have never used USB isolators, that is an interesting concept. I have not measured the peak current, but the average current drawn by my Teensy, buffer board and ILI9341 display is 0.19A.

  25. #50
    Senior Member
    Join Date
    May 2022
    Posts
    110
    Quote Originally Posted by PaulStoffregen View Post
    Maybe try using Arduino CLI. It's not as lightweight as a makefile, but you do get excellent compatibility. Newest Teensyduino 1.57 packages for CLI / IDE2 are supposed to detect if you're running headless and avoid launching the GUI-based Teensy Loader.
    Oof, looks like a bit of work to get that going, but it's doable. One quick question, is it effectively a complete new install unto its own? (Independent of any existing installation?)

    When you originally worked on this Paul, how did you test for usb compatibility? This is multi-platform, so I am sure you had to go through a lot of work. Is there a usb3 compatibility test anywhere? I am wondering if I just have a bad usb controller, or one that is not fully compliant with the standards - or even a counterfeit device.

Posting Permissions

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