PDA

View Full Version : Teensyduino 1.42 Beta #5



Paul
05-17-2018, 03:38 PM
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 (https://forum.pjrc.com/threads/52090-Teensyduino-1-42-Beta-4)

Fix Teensy 3.5 stack address (thanks Frank)
Better detection of Teensy model in Ports menu
Audio: fix WM8731 input select

PaulStoffregen
05-17-2018, 11:17 PM
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.

13830

mjs513
05-18-2018, 01:14 PM
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.

KurtE
05-18-2018, 06:12 PM
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:

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_28 6696\, Blink.ino.hex
11:09:23.370 (post_compile 1): Sending command: dir:C:\Users\kurte\AppData\Local\Temp\arduino_buil d_286696\
11:09:23.370 (loader): remote cmd from 1192: "dir:C:\Users\kurte\AppData\Local\Temp\arduino_buil d_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_28 6696\, 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_buil d_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_28 6696\, Blink.ino.hex
11:09:23.571 (post_compile 3): Sending command: dir:C:\Users\kurte\AppData\Local\Temp\arduino_buil d_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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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_28 6696\, 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...

defragster
05-18-2018, 08:51 PM
It is Back!
13839

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.

13840

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.

13841

Now that Ide's and all are closed/killed I'll do it again.

defragster
05-18-2018, 09:54 PM
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\DebugTes t.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::13842

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.


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;
}
}

defragster
05-19-2018, 12:38 AM
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.

tonton81
05-19-2018, 01:53 AM
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 :)

defragster
05-19-2018, 02:39 AM
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

tonton81
05-19-2018, 03:07 AM
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

defragster
05-19-2018, 05:06 AM
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.

PaulStoffregen
05-19-2018, 12:38 PM
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.

KurtE
05-19-2018, 03:01 PM
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.

defragster
05-19-2018, 04:41 PM
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.
...

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.

tonton81
05-19-2018, 05:04 PM
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)

PaulStoffregen
05-20-2018, 08:24 AM
perhaps you could say - Should there be ideally ONLY be one instance of TeensyPorts among 2 IDE's? Or one per IDE?


Only 1 instance of teensy_ports.exe should exist, even if you launch 2 or more Arduino IDE instances.

defragster
05-21-2018, 12:34 AM
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
13860

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

Win 10 uptime 11 days 16 hours. IDE 1.85 w/TD_1.42b5.

Jantje
05-21-2018, 01:02 PM
Thanks for the explanation of how it should work.
IMHO I need that info to support teensy in the future with sloeber.

Theremingenieur
05-21-2018, 02:12 PM
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.

Jantje
05-21-2018, 02:45 PM
@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

Theremingenieur
05-21-2018, 02:50 PM
I don't know this TyCommander you are referring to. Do you have a good starting point?
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.
Yes, that is another way of manually triggering an indexing run... :)

Thierry

Jantje
05-22-2018, 09:58 AM
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

defragster
05-22-2018, 05:32 PM
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:: 13870
->> 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":

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

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

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.

vladn
05-23-2018, 02:32 AM
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.

defragster
05-23-2018, 03:03 AM
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.

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.

PaulStoffregen
05-23-2018, 12:02 PM
So far only Windows 10 and multi Teensy has shown trouble AFAIK.

Has the problem ever happened with multiple Teensy boards, but only 1 instance of the Arduino IDE running? (and the hassle of having to repeatedly switch which board you're using in the menus)

My understanding is this looks like a problem from running more than 1 instance of the Arduino software, rather than how many Teensy boards you have connected.

PaulStoffregen
05-23-2018, 12:23 PM
Recent activity on github looks like the Arduino devs may be preparing to release 1.8.6.

defragster
05-23-2018, 05:11 PM
Has the problem ever happened with multiple Teensy boards, but only 1 instance of the Arduino IDE running? (and the hassle of having to repeatedly switch which board you're using in the menus)

My understanding is this looks like a problem from running more than 1 instance of the Arduino software, rather than how many Teensy boards you have connected.

No, it is correct the problem is with 2nd IDE - those words were in my history and head - but not typed in that note. At one point it seemed hitting compile - then starting Tsermon caused trouble but not seeing that now, that may have been in the subset of 2nd IDE as well.

The trouble comes from 2nd IDE needed to get a second active Sermon to debug a pair of Teensys in any fashion. The consistent thing noted some time back is that the repeating message 'callback ####' message stops coming through into the log file - hoped that would point to where things could go wrong. **(1)

I just tried single IDE with TLoader and going back and forth between T_LC and T_3.6 is looking fine.

The only way I saw an issue just now was getting the Board and Port out of sync. TLoader takes it offline then complains it is the wrong device and leaves it in bootloader - then changing port won't upload to the changed device until that 'other bootloader' device resets or restarts or is removed. It seems knowing the device and having the hex should make TLoader not ever take the 'wrong' Teensy offline?

**(1)::
>> After the above testing and notes I opened a 2nd IDE and once loaded both JAVA_IDE's have a TPort, and 'callback ####' stops.
>> I put "telnet 127.0.0.1 28542" in my 'Start Run' and that would take 3-4 seconds to connect and I could type 'list'. In this state the telnet window opens - then fails to connect and EXITS!
- open of cmd window reports this:
Connecting To 127.0.0.1...Could not open connection to the host, on port 28542: Connect failed
>> Hitting: Tools at this point indeed gives 8 second pause and there is no 'Teensy' section in ports. Each hit on 'Tools' spawns a new Tports.
>> Just saved new log: 13882
>> Opps! I ran prior beta tports-v first but it said not running - but then running the Beta5 Version it shows this and telnet still aborts:

teensy_ports, verbose mode
LoadLibrary cfgmgr32 ok
LoadLibrary ntdll ok
callback 0024
callback 0081
callback 0083
hWnd = 401488
begin is_already_running check
GetTcpTable success, 73 rows
0 : 135
C0A8016C : 139
7F000001 : 3149
0 : 3389
0 : 5040
7F000001 : 5354
7F000001 : 27015
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

vladn
05-23-2018, 05:46 PM
I want to clarify my previous question. I frequently run 2 instances of the IDE to check examples but with a single Teensy connected. Would that still be a problem ? I am asking since I need to patch few system library files for my needs and switching revisions takes some time and attention - I always manually patch using a diff tool (in case something changed in these files between revisions).

And a question for Paul - is it possible to separate Teensyduino directory structure from the Arduino one ? I'd like to have a single install of Arduino and multiple installations of the Teensyduino. Not urgent, but perhaps in the future (if even possible) ?

defragster
05-23-2018, 05:58 PM
IIRC it was a MAC - no known problems there with Dual - it should work - if not PRJC needs to know to correct it. There are two methods - the new Teensy_sermon and the existing IDE Sermon. If the new improved Teensy version does need work the IDE version should have no issues, it just won't use the new features and will act like prior versions.


On my WIN PC I have multiple FULL Arduino 'unzip' installs - each with a version of TeensyDuino installed on it, I just start from the desired directory. TeensyDuino only installs on a valid supported Arduino directory - and makes all its edits in place on that directory.

PaulStoffregen
05-23-2018, 09:44 PM
I frequently run 2 instances of the IDE to check examples but with a single Teensy connected.

Just to be clear, having 2 or more windows open is not necessarily multiple instances. You can use File > Open or File > Examples as many times as you like for lots of open windows, but they're all the same program instance.

Multiple instances means you run Arduino again. Windows Task Manager, Macos Activity Monitor or Linux "top" will show you have 2 complete copies of the software and Java environment running. With a single instance, when you change Tools > Boards or Tools > Ports, the change happens for every open window. People like Defragster working with 2+ boards tend to run 2 completely separate copies of Arduino, so they can have each with different board settings. If you have only 1 board, there's really no reason to run multiple instances. It uses a *lot* more memory on your computer. You're probably just opening multiple windows from the same instance, if you have only 1 board.



Would that still be a problem ?


Look, if I understood this bug well enough to answer this question with any confidence, I would know enough to fix it once and for all. Of course that is my plan, but as you can see from this conversation the bug only happens under pretty unusual circumstances and (so far) we don't even know exactly what to do to reproduce it.

Should you be afraid to try beta5? Definitely not! This bug is rare, it only happens if you have 2+ boards & instances of the software, and even then it is elusive. When it does strike, the problem isn't anything severe like crashing or losing data, but merely an annoying lag that can be solved by restarting the software.

If you do encounter this bug (which seems to have nearly zero chance since you're using only 1 board) or any other bug, please do take the time to post here with the details.




And a question for Paul - is it possible to separate Teensyduino directory structure from the Arduino one ? I'd like to have a single install of Arduino and multiple installations of the Teensyduino. Not urgent, but perhaps in the future (if even possible) ?

You certainly can have more than one copy of Arduino, each with a different Teensyduino install. If using Windows, you need to get the ZIP file download rather than the installer. Of course you also need to maintain some awareness of where you put each copy and which is which. Obvious as that sounds, it can be a challenge on Windows sometimes.

Just to confirm again, the Teensyduino installer only installs stuff into 1 specific copy of Arduino. On pre-10 Windows, it also installs an INF (or "driver") for hardware, but only the first time. Other than that hardware INF on Windows 8 & earlier, all the install happens only within the Arduino folder you select. You can have as many separate Arduino folders as you like, each with its own different copy of Teensyduino. I recommend naming they so you can easily see which is which, but if you need to check, just use Help > About (or Arduino > About if using Mac) to get the Arduino & Teensyduino version info for the copy you're actually running.

As far as the installation of files within a copy of Arduino goes, the answer is "it's complicated". While most of the stuff goes into Arduino's hardware/teensy and hardware/tools folders, the installer also has to touch a couple java jar files and many of the examples. These details can vary with different versions of Arduino, and they're likely to change in the future as Arduino continues to develop. That's why the installer carefully checks which version of Arduino you have. I don't recommend messing around with these internal details... but if you *really* want to dig into this stuff (taking a *lot* of time), the source code for the jar file modifications is on my github account, and all the other stuff is new or replaced ordinary files which you can detect by comparing an installer versus original copy. If using a Mac, of course you would use "Show Package Contents" to look inside. On Linux & Windows the Arduino software is just ordinary folders & files.

defragster
05-23-2018, 11:13 PM
Recent activity on github looks like the Arduino devs may be preparing to release 1.8.6.

What fun! Seeing any noteworthy changes that affect general Teensy Usage? Adding the parallel build yet or other things?

PaulStoffregen
05-23-2018, 11:29 PM
Most significant change looks like Arduino is updating the gcc toolchain to 5.4, exactly the same as we've been using on Teensy for quite some time. I don't see any use of its new features like constexpr constructors, but maybe that'll come later?

The rest looks like fairly minor stuff, small GUI fixes, internal library manager features, extending translations to libs, fixing misc minor bugs. All the big things like parallel building, the new preprocessor, and editor changes are on the 1.9 branch.

tonton81
05-24-2018, 07:45 AM
Thanks for the explanation of how it should work.

#18

https://forum.pjrc.com/threads/52315-Teensyduino-1-42-Beta-5?p=179717&viewfull=1#post179717

I see alot of times bots copying portions of other posts :)

Theremingenieur
05-24-2018, 07:53 AM
I see alot of times bots copying portions of other posts :)

Not for long time. The spam hunters are everywhere! :)

PaulStoffregen
05-25-2018, 08:21 AM
Yesterday I redesigned the teensy_ports single instance check. It now happens very early, right after command line parsing, before pretty much anything really happens. Hopefully this will solve the problems with multiple Arduino instances on Windows.

At this moment I'm looking into 2 more issues on my bug list... a USB hub with USBHost_t36 and WAV file parsing in the audio lib. Planning to package up beta6 when these are resolved. With a little luck that should be later today. :)

defragster
05-25-2018, 08:50 AM
Can't tell if that would be in the IDE or where Tports would be checking cmd-line? If a simple .exe I could test a private build first thing in the morning.

Do either the 8-second (like clockwork) Tools delay or the loss of that callback msg come near or lead to that? The delay in telnet started to response is only like 3 secs from command line - so that doesn't cover 8 secs.

PaulStoffregen
05-25-2018, 09:25 AM
3 seconds seems likely to be the silly Windows 1 second can't-connect-to-localhost delay, times the 3 possible ports.

I don't know where the extra 5 seconds is happening, but it would seem likely on the Java side. I tried to write the connect function to give up after 50 ms. Here's the Java side.

https://github.com/PaulStoffregen/Arduino-1.8.5-Teensyduino/blob/master/arduino-core/src/cc/arduino/packages/discoverers/TeensyDiscovery.java#L165

However, this has never really been tested. On all my machines, it always manages to connect.

If the improvements in beta6 don't solve the problem, perhaps in beta7 I'll uncomment the debug printing at line #143 in that file. Or maybe I'll just make an arduino-core.jar file you can drop into your copy of Arduino with that code added.

But my hope is the improvements in beta6 will make this all a moot point. We'll see soon. First I do want to fix those 2 other problems and hopefully manage to get some feedback from users affected, if they're willing to give beta6 a try.

PaulStoffregen
05-25-2018, 09:38 AM
Actually... why not try it right now?!

Here's a jar file you can drop into lib folder of an Arduino with 1.42-beta5 installed. It will add all that extra debug printing. If you can still get the problem to happen, maybe that'll give us some more info?

defragster
05-25-2018, 03:26 PM
Actually... why not try it right now?!

Here's a jar file you can drop into lib folder of an Arduino with 1.42-beta5 installed. It will add all that extra debug printing. If you can still get the problem to happen, maybe that'll give us some more info?

'cause it was time for rest …

… .jar dropped … IDE#1 uploaded to T_LC … waiting a few minutes … callback running …


Using library debug_t3 in folder: t:\tcode\libraries\debug_t3 (legacy)
Sketch uses 10000 bytes (15%) of program storage space. Maximum is 63488 bytes.
Global variables use 2200 bytes (26%) of dynamic memory, leaving 5992 bytes for local variables. Maximum is 8192 bytes.
TeensyDiscovery: listDiscoveredBoards
TeensyDiscovery: got 89 bytes
TeensyDiscovery: last bytes is null term, good :)
TeensyDiscovery: found 2 lines
TeensyDiscovery: found 2 fields
TeensyDiscovery: found 2 fields
TeensyDiscovery: listDiscoveredBoards
TeensyDiscovery: got 89 bytes
TeensyDiscovery: last bytes is null term, good :)
TeensyDiscovery: found 2 lines
TeensyDiscovery: found 2 fields
TeensyDiscovery: found 2 fields
T:\arduino_1.8.5_142b4\hardware\teensy/../tools/teensy_post_compile -file=DebugTest.ino -path=T:\TEMP\arduino_build_751634 -tools=T:\arduino_1.8.5_142b4\hardware\teensy/../tools -board=TEENSYLC -reboot -port=usb:0/140000/0/8/2 -portlabel=COM11 (Teensy LC) Serial -portprotocol=Teensy
TeensyDiscovery: listDiscoveredBoards
TeensyDiscovery: got 169 bytes
TeensyDiscovery: last bytes is null term, good :)
TeensyDiscovery: found 2 lines
TeensyDiscovery: found 2 fields
TeensyDiscovery: found 2 fields
TeensyDiscovery: listDiscoveredBoards
TeensyDiscovery: got 169 bytes
TeensyDiscovery: last bytes is null term, good :)
TeensyDiscovery: found 2 lines
TeensyDiscovery: found 2 fields
TeensyDiscovery: found 2 fields
TeensyDiscovery: listDiscoveredBoards
TeensyDiscovery: got 89 bytes
TeensyDiscovery: last bytes is null term, good :)
TeensyDiscovery: found 2 lines
TeensyDiscovery: found 2 fields
TeensyDiscovery: found 2 fields
TeensyDiscovery: listDiscoveredBoards
TeensyDiscovery: got 89 bytes
TeensyDiscovery: last bytes is null term, good :)
TeensyDiscovery: found 2 lines
TeensyDiscovery: found 2 fields
TeensyDiscovery: found 2 fields

"telnet 127.0.0.1 28542" - responds more quickly with 'teensy ports'.

… fail.
Open Ide #2 - both IDE have tports.exe and Tools menu 6.3 second delay (timed not counted)
telenet … opens … can't connect … closes.

13893
13894

steps:

8:21 AM 5/25/2018
Jar drop
IDE #1
debug test upload T_LC

... wait 8:29 AM 5/25/2018
re-upload ... callback active
open ide #2
!!!! > 2nd tports !!!! :: TL:verbose >> callback stopped

Test found in IDE #2 :: Generated 4 lines each click 'Tools' - Ports has no 'Teensy' section:

TeensyDiscovery: listDiscoveredBoards
TeensyDiscovery: sock try reconnect
TeensyDiscovery: sock try run program & reconnect
TeensyDiscovery: still can't connect
TeensyDiscovery: listDiscoveredBoards
TeensyDiscovery: sock try reconnect
TeensyDiscovery: sock try run program & reconnect
TeensyDiscovery: still can't connect

defragster
05-25-2018, 05:21 PM
Part #2 --- I repeated my breaking scenario - still using the above beta5++ .jar::
Open IDE #1 - Upload to T_LC - open Tsermon
… wait ...
>>> CLOSE TeensyLoader !!!! <<<
Open IDE #2 - upload to WRONG Teensy - Opps! < Board and Port did not match >
unplug T_3.6 allow upload to T_LC without Button.
Return to IDE and change over to T_3.6 : UPLOAD
>> ALL is Good single copy of Tports for both IDE instances. Is there some interaction with Teensy.exe having performed an Upload?

>> Going to repeat this again and see if it is correct/complete. FAIL:: IDE #1 opened to T_3.6 , changed to T_LC, Upload - wait ~7 minutes - TeensyLoader closed - open IDE #2 - Tools DELAYED - Multiple Tports :(

Part #1 --- was typed FIRST and it gave me the Idea that Teensy(Loader) was somehow causing trouble ...
What happens if you do this:: int[] addrlist = {28542,28542,4985,18925}; (https://github.com/PaulStoffregen/Arduino-1.8.5-Teensyduino/blob/master/arduino-core/src/cc/arduino/packages/discoverers/TeensyDiscovery.java#L152)

What I see from CMDLINE matches your code in listDiscoveredBoards() - this worked with 'telnet' before open of 2nd IDE:

C:\>telnet 127.0.0.1 28542
Connecting To 127.0.0.1...Could not open connection to the host, on port 28542: Connect failed

restarted at 9:18 … waited … got twin Tports

This repeated as I did it before:
in TaskMan close of ALL Tports when in this state causes a clean working restart of a SINGLE Tport for both IDE's. The 'callback' persists and both Tsermon's active and I can upload to them in turn.

>> It seems it is a startup of JAVA timing issue? Can this check for 'teensy ports' be put off? Is it done after IDE completes the 'lib scan for Active device'?
- wait IDE is established and until user selects: Upload or Tools or Verify ?

This does break when Tserialmon is opened out of order during compile - that is an odd race condition - but seems to relate to my first reported error on this feature,