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)Originally Posted by defragster
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.
Recent activity on github looks like the Arduino devs may be preparing to release 1.8.6.
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:>> 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.Connecting To 127.0.0.1...Could not open connection to the host, on port 28542: Connect failed
>> Just saved new log: Single2DoubleIDE.zip
>> 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:
Code: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
Last edited by defragster; 05-23-2018 at 10:12 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) ?
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.
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.
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.Would that still be a problem ?
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.
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.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) ?
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.
What fun! Seeing any noteworthy changes that affect general Teensy Usage? Adding the parallel build yet or other things?
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.
Last edited by PaulStoffregen; 05-24-2018 at 12:47 AM.
#18
https://forum.pjrc.com/threads/52315...l=1#post179717
I see alot of times bots copying portions of other posts
Not for long time. The spam hunters are everywhere!I see alot of times bots copying portions of other posts
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.
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.
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/Ar...very.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.
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 …
"telnet 127.0.0.1 28542" - responds more quickly with 'teensy ports'.Code: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
… 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.
steps:
Test found in IDE #2 :: Generated 4 lines each click 'Tools' - Ports has no 'Teensy' section: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
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
Last edited by defragster; 05-25-2018 at 04:42 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};
What I see from CMDLINE matches your code in listDiscoveredBoards() - this worked with 'telnet' before open of 2nd IDE:
restarted at 9:18 … waited … got twin TportsC:\>telnet 127.0.0.1 28542
Connecting To 127.0.0.1...Could not open connection to the host, on port 28542: Connect failed
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,
Last edited by defragster; 05-25-2018 at 06:32 PM.
Posting Permissions
