Teensyduino 1.42 Beta #5

Status
Not open for further replies.
Paul

Paul

Administrator
Staff member
Here is a fifth beta test for Teensyduino 1.42.

The main new feature is a "Teensy" section in the Tools > Ports menu
which tries to show Teensy in all modes, not just Serial. New native
(no Java serial library) serial monitor code is also with these ports.


Old beta download links removed. Please use the latest version:
https://www.pjrc.com/teensy/td_download.html


Changes since Teensyduino 1.42-beta4

Fix Teensy 3.5 stack address (thanks Frank)
Better detection of Teensy model in Ports menu
Audio: fix WM8731 input select
 
This beta puts info about which chip was used in the USB BCD version number, so the Ports menu can show which Teensy you're using even if it hasn't yet seen the board go into bootloader mode.

sc.png
 
I have been using beta 5 yesterday and today and can tell you that have the chip id on the com port (yes I am using Windows10) is such a pleasure. I have an LC and 3.5 attached and upload different sketches to each. As long as I remember to select the right chip and com port :) it uploads to correct board with no problems.
 
I installed the version, tried some hacking which I think I have logically removed.

But am having issues uploading. That is the board is not going into program mode... Windows 10, current update...

Verbose Info:
Code: 
11:08:39.869 (ports 2): nothing new, skipping HID & Ports enum
11:09:16.041 (ports 2): got command: "list"
11:09:16.042 (ports 2): nothing new, skipping HID & Ports enum
11:09:23.078 (post_compile 1): Begin, version=1.42-beta5, high-res time
11:09:23.215 (loader): Teensy Loader 1.42-beta5, begin program
11:09:23.259 (loader): File "Blink.ino.hex". 9984 bytes, 1% used
11:09:23.269 (loader): Listening for remote control on port 3149
11:09:23.269 (loader): initialized, showing main window
11:09:23.366 (loader): remote connection 1192 opened
11:09:23.366 (loader): remote cmd from 1192: "comment: Teensyduino 1.42-beta5 - WINDOWS (teensy_post_compile)"
11:09:23.366 (post_compile 1): Sending command: comment: Teensyduino 1.42-beta5 - WINDOWS (teensy_post_compile)
11:09:23.367 (loader): remote cmd from 1192: "status"
11:09:23.369 (loader): HID/win32:  vid:045E pid:07A5 ver:0797
11:09:23.369 (loader): HID/win32:  vid:045E pid:07A5 ver:0797
11:09:23.369 (loader): HID/win32:  vid:045E pid:07A5 ver:0797
11:09:23.369 (loader): HID/win32:  vid:045E pid:07A5 ver:0797
11:09:23.370 (post_compile 1): Status: 1, 0, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:23.370 (post_compile 1): Sending command: dir:C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\
11:09:23.370 (loader): remote cmd from 1192: "dir:C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\"
11:09:23.370 (loader): remote cmd from 1192: "file:Blink.ino.hex"
11:09:23.370 (post_compile 1): Sending command: file:Blink.ino.hex
11:09:23.373 (loader): File "Blink.ino.hex". 9984 bytes, 1% used
11:09:23.376 (loader): remote cmd from 1192: "status"
11:09:23.378 (post_compile 1): Status: 1, 0, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:23.378 (post_compile 1): Sending command: auto:on
11:09:23.378 (loader): remote cmd from 1192: "auto:on"
11:09:23.378 (post_compile 1): Disconnect
11:09:23.389 (loader): remote connection 1192 closed
11:09:23.538 (loader): remote connection 1284 opened
11:09:23.542 (ports 2): got command: "list"
11:09:23.543 (ports 2): nothing new, skipping HID & Ports enum
11:09:23.544 (ports 2): got command: "list"
11:09:23.544 (ports 2): nothing new, skipping HID & Ports enum
11:09:23.554 (loader): remote connection 1324 opened
11:09:23.554 (loader): remote cmd from 1324: "comment: Teensyduino 1.42-beta5 - WINDOWS (teensy_post_compile)"
11:09:23.568 (post_compile 3): Begin, version=1.42-beta5, high-res time
11:09:23.569 (post_compile 3): Sending command: comment: Teensyduino 1.42-beta5 - WINDOWS (teensy_post_compile)
11:09:23.569 (loader): remote cmd from 1324: "status"
11:09:23.569 (loader): remote cmd from 1324: "dir:C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\"
11:09:23.569 (loader): remote cmd from 1324: "file:Blink.ino.hex"
11:09:23.569 (loader): File "Blink.ino.hex". 9984 bytes, 1% used
11:09:23.569 (loader): remote cmd from 1324: "status"
11:09:23.571 (post_compile 3): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:23.571 (post_compile 3): Sending command: dir:C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\
11:09:23.571 (post_compile 3): Sending command: file:Blink.ino.hex
11:09:23.578 (post_compile 3): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:23.578 (post_compile 3): Disconnect
11:09:23.601 (loader): remote connection 1324 closed
11:09:23.601 (loader): remote connection 1324 opened
11:09:23.601 (post_compile 4): Running teensy_reboot: "D:\arduino-1.8.5\hardware\teensy\..\tools\teensy_reboot.exe" teensy_reboot.exe "-board=TEENSY36" "-port=usb:0/140000/0/2/1" "-portlabel=COM15 (Teensy 3.6) Serial" "-portprotocol=Teensy"
11:09:23.609 (reboot 5): Begin, version=1.42-beta5, high-res time
11:09:23.609 (reboot 5): location = usb:0/140000/0/2/1
11:09:23.609 (reboot 5): portlabel = COM15 (Teensy 3.6) Serial
11:09:23.609 (reboot 5): portprotocol = Teensy
11:09:23.609 (reboot 5): Only location usb:0/140000/0/2/1 will be tried
11:09:23.609 (reboot 5): LoadLibrary cfgmgr32 ok
11:09:23.609 (reboot 5): LoadLibrary ntdll ok
11:09:23.610 (reboot 5): found_usb_device, id=\\?\usb#vid_16c0&pid_0483#2272310#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
11:09:23.610 (reboot 5): found_usb_device, loc=usb:0/140000/0/2/1    Port_#0001.Hub_#0003
11:09:23.610 (reboot 5): found_usb_device, hwid=USB\VID_16C0&PID_0483&REV_0277
11:09:23.610 (reboot 5): found_usb_device, devinst=00000005
11:09:23.610 (reboot 5): add: loc=usb:0/140000/0/2/1, class=Ports, vid=16C0, pid=0483, ver=0277, serial=227, dev=\\?\usb#vid_16c0&pid_0483#2272310#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
11:09:23.610 (reboot 5):   comport_from_devinst_list attempt
11:09:23.610 (reboot 5):   found Ports in classguid_list at index=0
11:09:23.610 (reboot 5):   port COM15 found from devnode
11:09:23.610 (reboot 5): found_usb_device complete
11:09:23.612 (loader): remote connection 1348 opened
11:09:23.612 (loader): remote cmd from 1348: "show:arduino_attempt_reboot"
11:09:23.612 (loader): got request to show arduino rebooting message
11:09:23.612 (loader): remote cmd from 1348: "comment: Teensyduino 1.42-beta5 - WINDOWS (teensy_reboot)"
11:09:23.612 (loader): remote cmd from 1348: "status"
11:09:23.612 (loader): remote cmd from 1348: "status"
11:09:23.612 (reboot 5): found Teensy Loader, version 1.42
11:09:23.612 (reboot 5): Sending command: show:arduino_attempt_reboot
11:09:23.614 (reboot 5): Sending command: comment: Teensyduino 1.42-beta5 - WINDOWS (teensy_reboot)
11:09:23.615 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:23.615 (reboot 5): do_reset (serial) COM15
11:09:23.616 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:23.616 (reboot 5): status read, retry 0
11:09:23.717 (loader): remote cmd from 1348: "status"
11:09:23.720 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:23.720 (reboot 5): status read, retry 1
11:09:23.833 (loader): remote cmd from 1348: "status"
11:09:23.837 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:23.837 (reboot 5): status read, retry 2
11:09:23.949 (loader): remote cmd from 1348: "status"
11:09:23.950 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:23.950 (reboot 5): status read, retry 3
11:09:24.064 (loader): remote cmd from 1348: "status"
11:09:24.069 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:24.069 (reboot 5): status read, retry 4
11:09:24.180 (loader): remote cmd from 1348: "status"
11:09:24.184 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:24.184 (reboot 5): status read, retry 5
11:09:24.295 (loader): remote cmd from 1348: "status"
11:09:24.297 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:24.297 (reboot 5): status read, retry 6
11:09:24.411 (loader): remote cmd from 1348: "status"
11:09:24.415 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:24.415 (reboot 5): status read, retry 7
11:09:24.533 (loader): remote cmd from 1348: "status"
11:09:24.537 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:24.537 (reboot 5): status read, retry 8
11:09:24.649 (loader): remote cmd from 1348: "status"
11:09:24.653 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:24.653 (reboot 5): status read, retry 9
11:09:24.765 (loader): remote cmd from 1348: "status"
11:09:24.770 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:24.770 (reboot 5): status read, retry 10
11:09:24.881 (loader): remote cmd from 1348: "status"
11:09:24.884 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:24.884 (reboot 5): status read, retry 11
11:09:24.997 (loader): remote cmd from 1348: "status"
11:09:25.000 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:25.000 (reboot 5): status read, retry 12
11:09:25.112 (loader): remote cmd from 1348: "status"
11:09:25.115 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:25.115 (reboot 5): status read, retry 13
11:09:25.234 (loader): remote cmd from 1348: "status"
11:09:25.238 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:25.238 (reboot 5): status read, retry 14
11:09:25.350 (loader): remote cmd from 1348: "status"
11:09:25.351 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:25.351 (reboot 5): status read, retry 15
11:09:25.465 (loader): remote cmd from 1348: "status"
11:09:25.469 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:25.469 (reboot 5): status read, retry 16
11:09:25.581 (loader): remote cmd from 1348: "status"
11:09:25.585 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:25.585 (reboot 5): status read, retry 17
11:09:25.697 (loader): remote cmd from 1348: "status"
11:09:25.700 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:25.700 (reboot 5): status read, retry 18
11:09:25.812 (loader): remote cmd from 1348: "status"
11:09:25.816 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:25.816 (reboot 5): status read, retry 19
11:09:25.935 (loader): remote cmd from 1348: "status"
11:09:25.939 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:25.939 (reboot 5): status read, retry 20
11:09:26.048 (loader): remote cmd from 1348: "status"
11:09:26.052 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:26.052 (reboot 5): status read, retry 21
11:09:26.164 (loader): remote cmd from 1348: "status"
11:09:26.167 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:26.167 (reboot 5): status read, retry 22
11:09:26.279 (loader): remote cmd from 1348: "status"
11:09:26.283 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:26.283 (reboot 5): status read, retry 23
11:09:26.395 (loader): remote cmd from 1348: "status"
11:09:26.397 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:26.397 (reboot 5): status read, retry 24
11:09:26.511 (loader): remote cmd from 1348: "status"
11:09:26.517 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:26.517 (reboot 5): status read, retry 25
11:09:26.627 (loader): remote cmd from 1348: "status"
11:09:26.630 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:26.630 (reboot 5): status read, retry 26
11:09:26.749 (loader): remote cmd from 1348: "status"
11:09:26.752 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:26.752 (reboot 5): status read, retry 27
11:09:26.864 (loader): remote cmd from 1348: "status"
11:09:26.868 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:26.868 (reboot 5): status read, retry 28
11:09:26.980 (loader): remote cmd from 1348: "status"
11:09:26.984 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:26.984 (reboot 5): status read, retry 29
11:09:27.096 (loader): remote cmd from 1348: "status"
11:09:27.100 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:27.100 (reboot 5): status read, retry 30
11:09:27.211 (loader): remote cmd from 1348: "status"
11:09:27.216 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:27.216 (reboot 5): status read, retry 31
11:09:27.327 (loader): remote cmd from 1348: "status"
11:09:27.331 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:27.331 (reboot 5): status read, retry 32
11:09:27.449 (loader): remote cmd from 1348: "status"
11:09:27.451 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:27.451 (reboot 5): status read, retry 33
11:09:27.565 (loader): remote cmd from 1348: "status"
11:09:27.569 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:27.569 (reboot 5): status read, retry 34
11:09:27.681 (loader): remote cmd from 1348: "status"
11:09:27.685 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:27.685 (reboot 5): status read, retry 35
11:09:27.797 (loader): remote cmd from 1348: "status"
11:09:27.800 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:27.800 (reboot 5): status read, retry 36
11:09:27.913 (loader): remote cmd from 1348: "status"
11:09:27.916 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:27.916 (reboot 5): status read, retry 37
11:09:28.028 (loader): remote cmd from 1348: "status"
11:09:28.032 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:28.032 (reboot 5): status read, retry 38
11:09:28.132 (loader): remote cmd from 1348: "status"
11:09:28.136 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:28.136 (reboot 5): status read, retry 39
11:09:28.236 (loader): remote cmd from 1348: "status"
11:09:28.240 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:28.240 (reboot 5): status read, retry 40
11:09:28.341 (loader): remote cmd from 1348: "status"
11:09:28.344 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:28.344 (reboot 5): status read, retry 41
11:09:28.452 (loader): remote cmd from 1348: "status"
11:09:28.456 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:28.456 (reboot 5): status read, retry 42
11:09:28.568 (loader): remote cmd from 1348: "status"
11:09:28.569 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:28.569 (reboot 5): status read, retry 43
11:09:28.684 (loader): remote cmd from 1348: "status"
11:09:28.688 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:28.688 (reboot 5): status read, retry 44
11:09:28.800 (loader): remote cmd from 1348: "status"
11:09:28.804 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:28.804 (reboot 5): status read, retry 45
11:09:28.904 (loader): remote cmd from 1348: "status"
11:09:28.908 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:28.908 (reboot 5): status read, retry 46
11:09:29.020 (loader): remote cmd from 1348: "status"
11:09:29.023 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:29.023 (reboot 5): status read, retry 47
11:09:29.135 (loader): remote cmd from 1348: "status"
11:09:29.138 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:29.138 (reboot 5): status read, retry 48
11:09:29.257 (loader): remote cmd from 1348: "status"
11:09:29.263 (reboot 5): Status: 1, 1, 0, 0, 0, 0, C:\Users\kurte\AppData\Local\Temp\arduino_build_286696\, Blink.ino.hex
11:09:29.263 (reboot 5): status read, retry 49
11:09:29.373 (loader): remote connection 1348 closed
11:09:29.373 (loader): remote connection 1324 closed
11:09:29.374 (reboot 5): Teensy did not respond to a USB-based request to automatically reboot.
11:09:29.383 (ports 2): got command: "list"
11:09:29.384 (ports 2): nothing new, skipping HID & Ports enum
11:09:29.384 (ports 2): got command: "list"
11:09:47.081 (loader): Verbose Info event
Got to run...
 
It is Back!
MultiPort_b5.PNG

Had been running T_LC ... opened 2nd IDE … plugged in T_3.6 - hit TOOLS menu - … 8 seconds PAUSE! Never selected the Teensy and never hit Compile - so did not even open T_sermon.
View attachment MultiPort_b5_log.zip
Click to expand...

Win 10 not rebooted from prior post - now up 9 days 8 hours - both T_LC and T_3.6 are on same USB2 hub.

I am back to running my fault_isr code - not sure if that puts USB in odd state with the code I copied from core: \hardware\teensy\avr\cores\teensy3\mk20dx128.c :: void fault_isr(void). That is what I was running last time too in prior form - Though this is not what I was doing when first observed in prior Beta - now made it into a 'WIP' debug_t3 library I can post?

<edit>: I closed the second IDE - there are now 5 orphaned teensy_ports.exe not associated with an app. The open IDE still on T_LC has 3 associated.

Closed the second IDE - there is one orphaned teensy_serialmon and 3 teensy_ports in residence.

Here is the code I was running if it relates. I just pull out the (weak) fault_isr's and then it makes some memory faults and USB spits out the clues.
View attachment debug_t3.zip
Click to expand...

Now that Ide's and all are closed/killed I'll do it again.
 
Last edited:
Following above post #5:

Same T_LC and T_3.6 on USB2 hub.

Opened IDE #1 - uploaded - ran the : "...\libraries\debug_t3\examples\DebugTest\DebugTest.ino"

Opened IDE #2.

SAME picture as above - except the upper IDE only has 4 teensy_ports instead of 5. Tools Menu is Sluggish - ~8 seconds.

NOTE of Import? :: Each subsequent click of 'Tools' creates another instance of teensy_ports.exe during that 8 second delay!


Added Note: The primary T_LC is still responsive to UPLOAD! I cannot get T_sermon to open I have 6 and 14 teensy_ports.exe. the Tools/Ports no longer shows the newly added 'Teensy' subsection.
Just for diagnostic:: I started TyCommander as SerMon and it can connect and see the USB output of the T_LC - and confirms the TeensyLoader upload is new and current as it prints 'compile __TIME__' in the serial output.

IDE shows this in the 'Err' window: Board at usb:0/140000/0/8/1 is not available
log.txt needs zipped::View attachment MultiPort_b5_2nd_log.zip

If using above debug_t3 example - you'll find that sketch ends up here - ...\libraries\debug_t3\debug_t3.cpp - at line 65 where I was testing the assert_3() code in that sketch.
Code: 
void assert_3(const char *__file, int __lineno, const char *__sexp) {
  // transmit diagnostic informations through serial link.
  // Serial.println(__func);
  Serial.print(" ___ ASSERT FAILED ___ FILE >> ");
  Serial.println(__file);
  Serial.print(" LINE# >> ");
  Serial.println(__lineno, DEC);
  Serial.print(" Expression >> ");
  Serial.println(__sexp);
  Serial.flush();
  debug_fault( 20000 ); // call fault code to dump registers
  // abort program execution.
  Serial.println(" ___ ASSERT FAILED ___ STOPPING !!!!");
  Serial.flush();
  while ( 1 ) {
    if (SIM_SCGC4 & SIM_SCGC4_USBOTG) usb_isr();
    if (SIM_SCGC4 & SIM_SCGC4_UART0) uart0_status_isr();
    if (SIM_SCGC4 & SIM_SCGC4_UART1) uart1_status_isr();
    if (SIM_SCGC4 & SIM_SCGC4_UART2) uart2_status_isr();
    delayMicroseconds(100000);
    if ( _DoBlink ) GPIOC_PTOR = 32;
   }
}
 
KurtE - I got my T_3.6 to program my sample code above - which is what I wanted to confirm when I saw your post.

Paul: After the prior posts I ended up with (4) orphaned teensy_ports I cannot 'end task' on and one is eating 15.5% CPU even when no Teensy was plugged in.

I did finally get an IDE to open and switch to T_3.6 to program and then it worked - I did 'end task' on the new one with the IDE - not sure if that was the trick? The other (4) T_ports have now disappeared - tab switch list refresh?

Minor Note: Paul - when I first plugged in my T_3.6 { not yet re-programmed with Beta 5 } and unplugged the Com11 T_LC { that was Beta5 programmed } - the Ports /Teensy identified the COM8 as T_LC - when that was the T_3.6.

TO CONTINUE - with the T_3.6 running and programmed twice I started IDE #2 and plugged in the T_LC and it was already Tools selected since the last closed IDE used the T_LC. I then programmed the T_LC from IDE #2 no issue. Looking at TaskMan I now see only one teensy_ports,exe across BOTH IDE Java Apps, before each always had at least one.


Machine still not rebooted at 9 days 12 hours uptime - and it generally seems to be working this time - running the same DebugTest for debug_t3 above. I unplugged each Teensy and replugged and it reconnected to T_sermon output. There is some other element involved - not sure what that might be.
 
I have 2 visual sermons open, but 4 sermon processes open supposedly (Win8.0 here)

one single teensy_ports.exe and one single teensy.exe

Err, Im on Beta4 still, just upgraded yesturday hehe

EDIT

I closed all IDE's and serial monitor, has to kill using task manager 2 sermons in order to install Beta5

This is funny, Tim, every time I open serial monitor it doesn't stop the SPI_MST but it does increment the OT once on master, opening the slave increments ~ 1-3.
Reproducable every time reopening serial monitor, I presume the DTR is taking priority over the SPI bus hehehe

Anyways
Now taskmanager shows 2 sermons which is good, so far so good :)
 
tonton81 - I had been seeing that behavior all along since SPI_MSTransfer got going - but could never be positive it wasn't from early work - I mentioned it once - when it seemed it was 1::1 for sure drop and restart SerMon/TyComm.

Paul - I left my machine sit since last post - no open/close - tried some uploads now IDE#1 has (14)_Console_Win_Host and (16)_teensy_ports, IDE #2 has (14)_Console_Win_Host and (15)_teensy_ports

It may be the Time left open running? Post #6 had T_LC open hours when it failed before getting started.

Tools menu - delayed - no Port/Teensy and when I compile T_3.6 it prints this - referring to T_LC COM11:
Unable to open COM11 for reboot request
Windows Error Info: Access is denied.
more ideas... https://forum.pjrc.com/threads/40632?p=126667&viewfull=1#post126667
Click to expand...
 
I got no delays in tools menu, I tried switching from LC to 3.2 board option as a test, theres a IDE freeze for about 4 seconds but that should be normal as I always see that when switching boards

For now, until the LC crashes or by morning I'd rather not try flashing T3.6/LC here, wanna see how long it runs :p
 
Device change has the IDE reset/scan for device appropriate libraries and fresh temp folders etc. - that is indeed a normal pause.

When the 'Tools' slows that seems to go along with the loss of the teensyports utility as a regular coincidence? Not sure if it waits or times out and then restarts or respawns. But that is also when new instances appear.

<edit> - I did save post #9's '3rd' log and screen shot if it might help.
 
Last edited:
I'm currently in San Mateo, California for Maker Faire this weekend. Writing this from my laptop in a hotel room.

Seems there's a bug in Windows version of teensy_ports. If it is still listening to the localhost port but unresponsive (or is responding but running slow), that would definitely explain the ports menu delay.

Here's a little explanation about how it's supposed to work. When the IDE starts up, it launches teensy_ports and opens a localhost connection. The default port number is 28542. Two other port numbers are used as backups, in case you happen to have some other random software on your machine using that port. The backups are ports 4985 and 18925.

That connection is supposed to remain open for as long as the Arduino IDE is still running. When you quit the IDE, the connection is automatically closed, and even if the IDE doesn't close it, Windows will automatically close the connection when the main Arduino process exits.

I wrote teensy_ports to be able to allow any number of simultaneous connections. If you want to experiment, you can manually connect to it. All you have to do is run "telnet 127.0.0.1 28542". Immediately after telnet connects, it will send "teensy ports" (with a space, not underscore) to tell you it is in fact the teensy_ports.exe program, not some other random software offering some service on that port. While connected, only one command is supported: "list". Just type list and press enter and teensy_ports should immediately print a list of every Teensy is has detected. You can't see it with the telnet connect, but after the list it sends a zero byte to mark the end of the list. There should never be any noticeable lag. The output of the list command depends only on data held in memory.

Every time you click the Ports menu in Arduino, it's supposed to send this "list" command on the already-open localhost connection. The reply is supposed to always come quickly, and gets used to populate the Port menu.

If you get into the state where the Ports menu is lagging for 8 seconds, maybe this manual telnet connection can help show whether teensy_ports is still listening. If you're able to connect, does the "teensy ports" welcome message appear instantly after connecting, or does it lag 8 seconds? If you type "list", do you get the response instantly, or after 8 seconds, or not at all?

When you're in the condition where the Ports menu lags, what happens if you try running another instance of "teensy_ports -v" in a command prompt? It's supposed to print a list of TCP connections running running on your machine. If it sees any of them are those 3 known port numbers, it's supposed to try connecting to them. If any returns the "teensy ports" welcome message, it's supposed to immediately exit.

At least that's how things are supposed to go. Obviously there's a bug. I must have got something wrong. The main loop in teensy_ports on Windows is using the WIN32 MsgWaitForMultipleObjects() function, with a list of winwock events (one listening for new connections, the rest for all currently open client connections - which should normally be 1 per Arduino IDE instance), and of course the Windows messages (where the 3 we want are DBT_DEVICEARRIVAL, DBT_DEVNODES_CHANGED, and DBT_DEVICEREMOVECOMPLETE).

When I get back Monday, I'm going to put some serious effort into trying to get this to happen on my Windows test machine. But as you saw in the video, so far I've been completely unable to reproduce it.

One possibility is perhaps the sending of messages to the Teensy Loader verbose info log. As you're using Arduino and Teensy Loader in Windows, maybe something with Teensy Loader is going wrong, causing that message logging to lag everything else? What's supposed to happen within teensy_ports, teensy_serialmon, teensy_post_compile and teensy_reboot is queuing of log messages in memory if Teensy Loader isn't running or able to accept the log messages. On Linux and Mac, when localhost connections aren't up the errors are instant (as you'd expect a networking error to be, since it's all virtual connections entirely inside your PC that don't depend on any real network access), but Windows has an approx 1 sec lag for some types of errors. While it's entirely possible I got some of those WIN32 functions wrong, this 1 second delay in Windows is a likely culprit. I've tried to work around it everywhere with GetTcpTable(), but maybe there some case I didn't consider?

Anyway, when I get back this Windows issue is my top priority. I really appreciate all your help in testing and tracking this down. I'm not a Windows user. I pretty much use Linux (even for cross compiling Windows programs) and Mac for video. I really, really want to make a first-class user experience with Teensy for all Windows users with 1.42. Thanks for all your help so far, and hopefully next week we'll get this solved or at least add more info that leads to figuring it out.
 
Quick update: I reinstalled latest beta TD... And today the 3.5 and 3.6 were able to be programmed. Not sure if anything actually changed as I verified earlier my changes to boards.txt and platform.txt were no longer there... Maybe it was the reboot...

May again try adding a Update Method menu to maybe allow me to easily shift between using the standard way, TyCommander, and a remote install option, but that will be part of a different conversation.
 
PaulStoffregen said:
I'm currently in San Mateo, California for Maker Faire this weekend. Writing this from my laptop in a hotel room.

Seems there's a bug in Windows version of teensy_ports.
...
Click to expand...

Busy weekend here too - will read and do as I can with extended info. One answer I'll read for - perhaps you could say - Should there be ideally ONLY be one instance of TeensyPorts among 2 IDE's? Or one per IDE? I usually see 1 each - but yesterday I saw a single for two and it worked at that point. Though it may have been a TaskMan 'refresh list' issue - like when it shows only one IDE.

Something does go awry - works well when it works - but something triggers LOSS of port detection or connection and it cascades new ones.

Indeed once Ports/Teensy is gone, and/or 8 second delay, things are all wrong - it auto respawns. Will try a manual 'TP -v', etc as noted.

Your Video steps were 'mechanically correct' but you did it clean and fast. - Like I did when I followed along and it worked. As noted yesterday it seems there is some effect from prior connect or 'run time' and accumulated 'damage/garbage/confusion'.

Working within the IDE is binding your hands and altering the view it seems? If a single instance of TLoader could externally handle Tports/TSermon I expect the connects could be better managed. That would be more like TyComm's view of the world and just for reference info - TyComm does all of this without IDE contention or issues - I expect because it is removed from the IDE and whatever Windows/JAVA and is doing to make it seem yet another instance of TPorts is needed. I noted or 'felt' some builds back it appeared like with two TeensyPorts - one would put the connect on hold during compile and then perhaps the other TeensyPorts was consuming that port when it scanned in some fashion.

When I get back I'll read and see how that world view goes along with Post #12 text.
 
After restarting the IDE and programming both LC and T3.5 I don't seem to be seeing any issues here with beta5 so far (Win8.0)
 
Issue update - problem occurs with time

Not gotten back to this yet - but IIRC - I was regularly seeing one instance of Tports per IDE. I just opened both - properly in turn with T_Sermon - hit Button on both before TLoader was open - Tloader programmed the T_LC - then complained about the T_3.6 and turned off Auto.

I ended up with a second T_sermon - that shows as orphaned when I closed that IDE. I only got one Tports.

Will leave T_LC active with IDE and get back to this after some home tasks.

<edit>: left it sit 5:30 to ~10pm with #1 IDE to T_LC as above ... opened IDE #2 and 2nd IDE got a unique Tports.exe - First thing> Tools takes LONG time to display - each redraw of Tools menu items starts another Tports
TlcThen2nd.PNG

You have timestamps in the log file so time open will be there before things go odd.

Earlier I saved the TLoader log when it made 2nd Tsermon {OrphTsermonlog} and that was 'clear'ed. It sat this time with fresh log to this 10 PM edit - you can see transitions in the log in {ReturnOrphTsermonlog}.
Big file both zipped here:View attachment ReturnOrphTsermonlog.zip

Win 10 uptime 11 days 16 hours. IDE 1.85 w/TD_1.42b5.
 
Last edited:
Thanks for the explanation of how it should work.
IMHO I need that info to support teensy in the future with sloeber.
 
BTW, Sloeber works also very well with TyCommander. The only thing is that Sloeber seems to cache somewhere the configuration, so after activating TyCommander (which patches boards.txt or platform.txt, don‘t remember which one), you have to restart Sloeber and to manually index your project in order to make it work. But then, everything is fine.
 
@Theremingenieur
I don't know this TyCommander you are referring to. Do you have a good starting point?
If TyCommander changes the boards.txt and or the platform.txt you should do project properties->arduino->apply and ok. This will make sloeber to see these changes.
Jantje
 
I don't know this TyCommander you are referring to. Do you have a good starting point?
Click to expand...
TyCommander is an alternative Teensy uploader with integrated Serial monitor and a few more functions for convenience. The project and the description can be found here: https://github.com/Koromix/tytools
If TyCommander changes the boards.txt and or the platform.txt you should do project properties->arduino->apply and ok. This will make sloeber to see these changes.
Click to expand...

Yes, that is another way of manually triggering an indexing run... :)

Thierry
 
It looks like those tytools behave very much the same as what paul implemented.

project properties->arduino->apply and ok does not guarantee the indexer will rerun. It copies the info from the boards.txt and platform.txt to the environment variables used by CDT. If change is detected (either by cdt or Sloeber) that the indexer or the makefiles need to be rebuild they may trigger that.
So if you want to be sure the whole sloeber environment is up to date do following actions
1) project properties->arduino->apply and ok
2) delete the build folder in the project (normally release) (may be deleted as a result of step 1)
3) rebuild the indexer
Note that step 3 is not affecting the build and is purely for the gui experience and has failed in the past to update properly.
Jantje
 
Update on multi Win10 Tports. Decided to do a restart … repeated the step below after restart 0nce before restart and I got the same result before restart and after::

<Restarted Win 10 - first thing opened was IDE #1 to LC
> check Tools/Ports to LC, open Tsermon
> Compile ( post #5 debug_t3 example )
> wait ~7 mins - you can see the time measure in this log file:: View attachment RestartLC10Min.txt
->> Open IDE #2
> Check TaskMan - each IDE had one Tports.
> Save and Clear TLoader Verbose log.

->> hit Menu Tools … 8 sec delay and another Tports is spawned and PORTS has no Teensy Section
> Closed both IDE's - 3 orphaned Tports.
>> Copied new TLoader Verbose text and appended to end of prior log file attached above.

<edit>:
To confirm my 'normal' environment works - I integrated the updated TyCommander {TYC} on a copy of the IDE with TD1.42b5.
Started IDE#1_TYC with T_LC
Programmed 'DebugTest' same sketch
Did other things . . .
Started IDE #2_TYC with T_3.6
Programmed 'DebugTest' same sketch

Both are up and running - I did see a horrible STALL on reprogramming T_LC once. Opening TaskMan I see IDE#1 and #2 each have a PILE of teensy_ports.exe one with 7 copies the other has 9 Tports. I have not used Tsermon, only hit Tools once to change IDE #2 to T_3.6.

Here is output from "Tports -v":
Code: 
T:\arduino_1.8.5_142b4_TYC\hardware\tools>teensy_ports.exe -v
teensy_ports, verbose mode
LoadLibrary cfgmgr32 ok
LoadLibrary ntdll ok
callback 0024
callback 0081
callback 0083
hWnd = 267216
begin is_already_running check
GetTcpTable success, 76 rows
0 : 135
C0A8016C : 139
0 : 3389
0 : 5040
7F000001 : 5354
7F000001 : 27015
7F000001 : 28542
7F000001 : 28542
7F000001 : 28542
7F000001 : 28542
7F000001 : 28542
7F000001 : 28542
7F000001 : 28542
7F000001 : 28542
7F000001 : 28542
7F000001 : 28542
7F000001 : 28542
7F000001 : 28542
7F000001 : 28542
7F000001 : 28542
7F000001 : 28542
7F000001 : 28542
7F000001 : 43227
0 : 49664
0 : 49665
0 : 49666
0 : 49670
0 : 49674
0 : 49718
0 : 49734
7F000001 : 49916
7F000001 : 65000
7F000001 : 65001
0 : 445
0 : 2869
0 : 5357
0 : 7680
end is_already_running, ret=0
not already running
socket created
bound to port 28542
found_usb_device, id=\\?\usb#vid_16c0&pid_0483#2056390#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
found_usb_device, loc=usb:0/140000/0/8/1    Port_#0001.Hub_#0005
found_usb_device, hwid=USB\VID_16C0&PID_0483&REV_0277
found_usb_device, devinst=00000002
add: loc=usb:0/140000/0/8/1, class=Ports, vid=16C0, pid=0483, ver=0277, serial=205, dev=\\?\usb#vid_16c0&pid_0483#2056390#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
      00000002, class=Ports, portname=COM8, id=USB\VID_16C0&PID_0483\2056390
  comport_from_devinst_list attempt
  found Ports in classguid_list at index=0
  port COM8 found from devnode
found_usb_device complete
found_usb_device, id=\\?\usb#vid_16c0&pid_0483#1113960#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
found_usb_device, loc=usb:0/140000/0/8/2    Port_#0002.Hub_#0005
found_usb_device, hwid=USB\VID_16C0&PID_0483&REV_0273
found_usb_device, devinst=00000005
add: loc=usb:0/140000/0/8/2, class=Ports, vid=16C0, pid=0483, ver=0273, serial=111, dev=\\?\usb#vid_16c0&pid_0483#1113960#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
      00000005, class=Ports, portname=COM11, id=USB\VID_16C0&PID_0483\1113960
  comport_from_devinst_list attempt
  found Ports in classguid_list at index=0
  port COM11 found from devnode
found_usb_device complete
usb_add: usb:0/140000/0/8/2  COM11 (Teensy LC) Serial
usb_add: usb:0/140000/0/8/1  COM8 (Teensy 3.6) Serial

After enabling Win 10 telnet - with 17 copies of Tports open. Same results for the alternate port #'s:
T:\arduino_1.8.5_142b4_TYC\hardware\tools>telnet 127.0.0.1 28542
Connecting To 127.0.0.1...Could not open connection to the host, on port 28542: Connect failed
Click to expand...

<<EDIT 2> :: I'm doing this with TYC because I know it works and is my normal environment. In doing this it shows Tports still active from IDE and still triggering the Tports issues as noted.

Manually 'end task' on all Tports. Went to IDE#2_TYC and selected T_3.6 - that spawned a Tports. List in telnet responded:
usb:0/140000/0/8/2 COM11 (Teensy LC) Serial
usb:0/140000/0/8/1 COM8 (Teensy 3.6) Serial
Click to expand...
Doing 'list' twice more worked - and many times since.

Taskman shows only a SINGLE Tports.exe between both open IDE's_TYC.

Doing IDE Uploads to both through TYC has not caused any new Tports, and telnet 'list' gives valid output.

Still no extra Tports in this scenario with IDE using TyCommander - Windows seems to be working with the one copy of Tports. Seems like something in the IDE with TeensyLoader/Tsermon?

Hopefully the TLoader verbose log gives you breadcrumbs about what happens in the IDE to cause Tport respawn?

<edit #3> : 5 hours later - both IDE_TYC's still open - IDE Upload w/TyCommander works - single copy of Teeny Ports active.
Run: 'telnet 127.0.0.1 28542' and list shows both devices no problem.
Tools / Ports works fast/properly. What I have not used it Tsermon or TeensyLoader.

<Edit #4> : IDE System untouched another few hours. All seems fine. Decided to stop TyComm Serial connect and use TSermon through IDE_TYC. TyComm can talk to Teensy when in Bootloader when Serial disabled. So a button push then using the TyComm GUI RESET button restarts and a TSermon to both T_LC and T_3.6. The linked sketch results in faults to a halted while(1) state when complete. So a Button push allows TyComm to Upload the prior HEX or then again hit Gui Reset - in both cases Tsermon picks up both Teensys and displays expected output. In doing this a couple times each Each IDE_TYC now shows a T_sermon and only one JAVA_IDE_TYC shows a Tports. Doing telnet/list works as described. None of this and over 12 hours uptime has caused an issue. Menu Tools / Ports still comes up instantly. Trying to use TLoader in this same way could almost work - but not from IDE Upload as it spawns TyComm - so it may not trigger the issue.
 
Last edited:
Quick question - for those of us that connect only one Teensy at a time (although of different types) does the issue above have any consequences ? Platforms - Windows 10, Mac, Linux.
 
vladn said:
Quick question - for those of us that connect only one Teensy at a time (although of different types) does the issue above have any consequences ? Platforms - Windows 10, Mac, Linux.
Click to expand...

So far only Windows 10 and multi Teensy has shown trouble AFAIK. Don't hesitate to use it and prove it works well for you.
 
Status
Not open for further replies.
Back
Top