Teensyduino 1.42 Beta #5

Status
Not open for further replies.
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.
 
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: View attachment 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:
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.
 
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.
 
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:
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/A...ackages/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.
 
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?
 

Attachments

  • arduino-core.zip
    1.5 MB · Views: 289
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 …
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

"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.
Beta5_Pre6.PNG

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
 
Last edited:
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:
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,
 
Last edited:
Status
Not open for further replies.
Back
Top