Looking for some clues hard Linux crash using Ty Commander

[clinker8]

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?

 

[KurtE]

Yes that is the executable

 

[clinker8]

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?

 

[kd5rxt-mark]

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

 

[clinker8]

[ 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.

 

[kd5rxt-mark]

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

 

[defragster]

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

 

[KurtE]

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.

 

[clinker8]

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.

 

[clinker8]

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.

$ 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.

 

[clinker8]

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.

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.

 

[clinker8]

Built the teensy_loader_cli and not sure if I am quite invoking it correctly.

./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.

~/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:

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

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:

Bus 001 Device 013: ID 16c0:0483 Van Ooijen Technische Informatica Teensyduino Serial

Is this significant?

 

[clinker8]

If I use 0x483, and recompile, Teensy Loader shows the following:

$ ./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.

 

[clinker8]

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.

 

[clinker8]

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.

 

[PaulStoffregen]

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.

 

[clinker8]

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.

 

[clinker8]

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.

 

[kd5rxt-mark]

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

 

[clinker8]

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.

~/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.

 

[Nominal Animal]

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

 

[clinker8]

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.

 

[PaulStoffregen]

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.

 

[clinker8]

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.

 

[clinker8]

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.