Teensyduino 1.59 Beta #6

Put a T_3.5 on IDE 2.3 here and it was recognized and uploaded okay - w/tycomm

But that WINDOW won't MOVE with title bar? Has NO Title bar - only menu bar on top. IDE is odd?

Got that restart dialog again - it only restarted one sketch window and it won't move with title bar (only menu bar there) either - though resize edge works
Win11 PRO here - computer only up 4 days 20 hrs ...

Closed IDE 2.3 and it seems to have opened to work - only 1 of 3 sketches opened - opened ablink to T_3.5 and it built and title bars and UI okay.
SO nothing odd - will restart without localplatform to tycomm on T_3.5

<edit> Restarted IDE 2.3 - opened IDE TeensyPort SerMon - Upload worked and went back to SerMon as desired/expected
{ T_MM DevBoard still online and TyComm closed }

<edit 2> formatted an SD card and dumped on files and T_3.5 listfiles built in second IDE window and worked for upload to pause SerMon in first Window and then activated no problem to shows files as expected - once changed to CS of BUILTIN_SDCARD
> Closed SerMon and First other sketch and rebuilt and SerMon found and displayed
 
Last edited:
defragster said:
But that WINDOW won't MOVE with title bar? Has NO Title bar - only menu bar on top. IDE is odd?

Got that restart dialog again - it only restarted one sketch window and it won't move with title bar (only menu bar there) either - though resize edge works
Click to expand...
That phenomenon is not typical for Arduino 2.3.0 - I have seen that more times with 2.2.1 than I like. And it always happens after that restart dialog you mentioned in post #38.

Paul
 
kd5rxt-mark said:
So, maybe their download mechanism is not really verifying the checksum ?? Or not handling an invalid checksum correctly ??
Click to expand...

Yeah, sure seems like Arduino IDE / CLI isn't even verifying the size after download, let alone the checksum. Both are definitely given in the platform index JSON. My gut feeling is they probably are checking these in some cases. I know it catches certain type of errors, like when I put the wrong numbers into the JSON. Maybe they only properly check this stuff when the download completes successfully?
 
PaulStoffregen said:
Oh believe me, I really want to wrap up 1.59 release!

But first I want to try investigating @BriComp's issue reported in msg #30 (even though it lacks the specific code I'm supposed to run on Teensy 3.5... hint.. hint...)

I also recently saw a case where Windows got very confused while using an externally powered Teensy, even caused other USB devices like an ordinary Logitech mouse to stop working, and Windows took forever to shut down and ultimately decided to send some sort of crash report to Microsoft (or course without asking for my consent). Maybe these are unrelated. Maybe something else went wrong on that test PC. But perhaps something isn't quite right and perhaps has been that way for a long time but we've just never been able to reproduce it?
Click to expand...
I had switched to 1.59b4 last night and it was rock solid no problems.
Just switched back to 1.59b6 and so far (1/2 hr) been unable to repeat the problem.
 
Now I see the memory used stuff:
Code: 
/Users/raine001/Documents - MacBook Pro/Arduino/TeensyEyes_copy_20240205/audio.ino: In function 'void loopAudio()':
/Users/raine001/Documents - MacBook Pro/Arduino/TeensyEyes_copy_20240205/audio.ino:103:12: warning: unused variable 'touchSample1' [-Wunused-variable]
  103 |   uint32_t touchSample1 = micros();
      |            ^~~~~~~~~~~~
In file included from /Users/raine001/Documents - MacBook Pro/Arduino/TeensyEyes_copy_20240205/config.h:30,
                 from /Users/raine001/Documents - MacBook Pro/Arduino/TeensyEyes_copy_20240205/TeensyEyes_copy_20240205.ino:61:
/Users/raine001/Documents - MacBook Pro/Arduino/TeensyEyes_copy_20240205/src/EyeController.h: In instantiation of 'std::pair<float, float> EyeController<numEyes, Disp>::computeEyelids(Eye<Disp>&) const [with unsigned int numEyes = 2; Disp = GC9A01A_Display]':
/Users/raine001/Documents - MacBook Pro/Arduino/TeensyEyes_copy_20240205/src/EyeController.h:685:43:   required from 'bool EyeController<numEyes, Disp>::renderFrame() [with unsigned int numEyes = 2; Disp = GC9A01A_Display]'
/Users/raine001/Documents - MacBook Pro/Arduino/TeensyEyes_copy_20240205/TeensyEyes_copy_20240205.ino:206:20:   required from here
/Users/raine001/Documents - MacBook Pro/Arduino/TeensyEyes_copy_20240205/src/EyeController.h:255:27: note: parameter passing for argument of type 'std::pair<float, float>' when C++17 is enabled changed to match C++14 in GCC 10.1
  255 |   std::pair<float, float> computeEyelids(Eye<Disp> &eye) const {
      |                           ^~~~~~~~~~~~~~
Memory Usage on Teensy 4.1:
  FLASH: code:151216, data:2816816, headers:8732   free for files:5149700
   RAM1: variables:26272, code:145892, padding:17948   free for local variables:334176
   RAM2: variables:15552  free for malloc/new:508736
 EXTRAM: variables:16777216

looks great!
 
shawn said:
Yes, it seems to work. What was the fix?
Click to expand...

Thanks for checking. This fix will be in the final release.

It seems Apple made another subtle change to /usr/bin/open, or to something deeper within MacOS which it uses. This isn't the first time. We had a similar problem when Monterey came out.

Along the way, I also discovered Apple seems to have tightened security regarding checks on digital signatures and Apple notarization. Previously if you changed one of the internal utilities like teensy_post_compile or teensy_reboot, MacOS would only take notice if you hadn't previously run the IDE at all, or if you moved it somewhere else (eg, from Downloads to Applicatons). Now they catch it on the next run. Not sure how they're doing it, as I can't really notice a lag in launching the app. Maybe these new M1 machines and soldered-down SSDs are just crazy fast? Maybe they have super fast crypto accelerators in all these new machines? Or maybe they put some sort of file modification monitoring deeper inside MacOS? However they're doing it, that's why I had to rebuild the whole 300+MB package and put it through Apple notarization.
 
Last edited:
BriComp said:
I had switched to 1.59b4 last night and it was rock solid no problems.
Just switched back to 1.59b6 and so far (1/2 hr) been unable to repeat the problem.
Click to expand...
Still can't repeat the problem(s) of yesterday, perhaps treat it as a computer aberration....though it WAS rock solid on 1.59b4....and so far back on 1.59b6 still is.
 
My experience here too. I'm pretty sure we do indeed have some elusive problem (which I suspect is really Microsoft's drivers handling certain cases badly, as I've never seen this with Linux or MacOS). I'll try again later today, but I'm afraid if I can't find a way to reproduce it the only realistic option is looking like releasing 1.59 now and hope we later find a way to reproduce it before 1.60.
 
PaulStoffregen said:
My experience here too. I'm pretty sure we do indeed have some elusive problem (which I suspect is really Microsoft's drivers handling certain cases badly, as I've never seen this with Linux or MacOS). I'll try again later today, but I'm afraid if I can't find a way to reproduce it the only realistic option is looking like releasing 1.59 now and hope we later find a way to reproduce it before 1.60.
Click to expand...
Agreed.
 
I don't know if this is anything to worry about at this late date, but Arduino IDE 2.3.0 (along with TD 0.59.6, running under Windows 11pro, but I don't think either of these are pertinent) reports a build failure when initiating CTRL-ALT-S (I'm not at my computer, but I believe it's called Save BinariesExport Compiled Binary). I believe the build actually succeeds, as both hex & ehex files are built, & both work. Note that Arduino IDE 2.2.1 also showed the same unexpected behavior.

Mark J Culross
KD5RXT

EDIT: Sorry, since I was away from my computer, I was not previously able to attach any detailed info. Now that I'm back at my computer, here are the details (using Blink.ino):

Output window:

Code: 
Opening Teensy Loader...
Memory Usage on Teensy 4.0:
  FLASH: code:8036, data:3016, headers:8400   free for files:2012164
   RAM1: variables:3456, code:6256, padding:26512   free for local variables:488064
   RAM2: variables:12416  free for malloc/new:511872
exit status 1

Compilation error: exit status 1

Verbose TD build log:

Code: 
07:50:20.772 (loader): file changed
07:50:20.773 (post_compile 2): Begin, pid=7444, version=1.59-beta6, high-res time
07:50:20.776 (loader): File "C:\Users\mjcul\AppData\Local\Temp\arduino\sketches\10701F77C071D759B9977B1510C6D0EE\Blink.ino.hex", 19456 bytes
07:50:20.776 (loader): File "C:\Users\mjcul\AppData\Local\Temp\arduino\sketches\10701F77C071D759B9977B1510C6D0EE\Blink.ino.ehex", 19456 bytes, and 5536 loader utility
07:50:20.776 (loader): ehex is valid, key hash: C98CD607 4C9B5153 DFC66457 FAA47DC9 1C64826D AE55EE72 206786C5 8C3B1D26
07:50:20.776 (loader): File "Blink.ino.hex". 19456 bytes
07:50:20.790 (loader): remote connection 1436 opened
07:50:20.793 (post_compile 2): ARDUINO_USER_AGENT = "arduino-cli/0.35.2 arduino-ide/2.3.0 grpc-node-js/1.9.5"
07:50:20.793 (post_compile 2): Sending command: comment: Teensyduino 1.59-beta6 - WINDOWS (teensy_post_compile)
07:50:20.798 (loader): remote cmd from 1436: "comment: Teensyduino 1.59-beta6 - WINDOWS (teensy_post_compile)"
07:50:20.798 (loader): remote cmd from 1436: "status"
07:50:20.798 (loader): remote cmd from 1436: "dir:C:\Users\mjcul\AppData\Local\Temp\arduino\sketches\10701F77C071D759B9977B1510C6D0EE\"
07:50:20.798 (loader): remote cmd from 1436: "file:Blink.ino.hex"
07:50:20.802 (post_compile 2): Status: 1, 1, 0, 0, 0, 0, C:\Users\mjcul\AppData\Local\Temp\arduino\sketches\10701F77C071D759B9977B1510C6D0EE\, Blink.ino.hex
07:50:20.802 (post_compile 2): Sending command: dir:C:\Users\mjcul\AppData\Local\Temp\arduino\sketches\10701F77C071D759B9977B1510C6D0EE\
07:50:20.803 (post_compile 2): Sending command: file:Blink.ino.hex
07:50:20.806 (loader): File "C:\Users\mjcul\AppData\Local\Temp\arduino\sketches\10701F77C071D759B9977B1510C6D0EE\Blink.ino.hex", 19456 bytes
07:50:20.812 (loader): File "C:\Users\mjcul\AppData\Local\Temp\arduino\sketches\10701F77C071D759B9977B1510C6D0EE\Blink.ino.ehex", 19456 bytes, and 5536 loader utility
07:50:20.812 (loader): ehex is valid, key hash: C98CD607 4C9B5153 DFC66457 FAA47DC9 1C64826D AE55EE72 206786C5 8C3B1D26
07:50:20.815 (loader): File "Blink.ino.hex". 19456 bytes
07:50:20.815 (loader): remote cmd from 1436: "status"
07:50:20.825 (post_compile 2): Status: 1, 1, 0, 0, 0, 0, C:\Users\mjcul\AppData\Local\Temp\arduino\sketches\10701F77C071D759B9977B1510C6D0EE\, Blink.ino.hex
07:50:20.825 (post_compile 2): Disconnect
07:50:20.846 (loader): remote connection 1436 closed

And here's the verbose TD build log for a normal build for comparison:

Code: 
07:55:19.949 (loader): file changed
07:55:19.954 (loader): File "C:\Users\mjcul\AppData\Local\Temp\arduino\sketches\10701F77C071D759B9977B1510C6D0EE\Blink.ino.hex", 19456 bytes
07:55:19.954 (loader): File "C:\Users\mjcul\AppData\Local\Temp\arduino\sketches\10701F77C071D759B9977B1510C6D0EE\Blink.ino.ehex", 19456 bytes, and 5536 loader utility
07:55:19.954 (loader): ehex is valid, key hash: C98CD607 4C9B5153 DFC66457 FAA47DC9 1C64826D AE55EE72 206786C5 8C3B1D26
07:55:19.954 (loader): File "Blink.ino.hex". 19456 bytes
07:55:20.028 (post_compile 3): Begin, pid=3824, version=1.59-beta6, high-res time
07:55:20.030 (loader): remote connection 2016 opened
07:55:20.030 (loader): remote cmd from 2016: "comment: Teensyduino 1.59-beta6 - WINDOWS (teensy_post_compile)"
07:55:20.030 (loader): remote cmd from 2016: "status"
07:55:20.030 (loader): remote cmd from 2016: "dir:C:\Users\mjcul\AppData\Local\Temp\arduino\sketches\10701F77C071D759B9977B1510C6D0EE\"
07:55:20.030 (loader): remote cmd from 2016: "file:Blink.ino.hex"
07:55:20.030 (loader): File "C:\Users\mjcul\AppData\Local\Temp\arduino\sketches\10701F77C071D759B9977B1510C6D0EE\Blink.ino.hex", 19456 bytes
07:55:20.032 (post_compile 3): ARDUINO_USER_AGENT = "arduino-cli/0.35.2 arduino-ide/2.3.0 grpc-node-js/1.9.5"
07:55:20.032 (post_compile 3): Sending command: comment: Teensyduino 1.59-beta6 - WINDOWS (teensy_post_compile)
07:55:20.035 (post_compile 3): Status: 1, 1, 0, 0, 0, 0, C:\Users\mjcul\AppData\Local\Temp\arduino\sketches\10701F77C071D759B9977B1510C6D0EE\, Blink.ino.hex
07:55:20.035 (post_compile 3): Sending command: dir:C:\Users\mjcul\AppData\Local\Temp\arduino\sketches\10701F77C071D759B9977B1510C6D0EE\
07:55:20.036 (post_compile 3): Sending command: file:Blink.ino.hex
07:55:20.042 (loader): File "C:\Users\mjcul\AppData\Local\Temp\arduino\sketches\10701F77C071D759B9977B1510C6D0EE\Blink.ino.ehex", 19456 bytes, and 5536 loader utility
07:55:20.042 (loader): ehex is valid, key hash: C98CD607 4C9B5153 DFC66457 FAA47DC9 1C64826D AE55EE72 206786C5 8C3B1D26
07:55:20.042 (loader): File "Blink.ino.hex". 19456 bytes
07:55:20.042 (loader): remote cmd from 2016: "status"
07:55:20.059 (post_compile 3): Status: 1, 1, 0, 0, 0, 0, C:\Users\mjcul\AppData\Local\Temp\arduino\sketches\10701F77C071D759B9977B1510C6D0EE\, Blink.ino.hex
07:55:20.059 (post_compile 3): Disconnect
07:55:20.074 (loader): remote connection 2016 closed
 
Last edited:
I decided since I saw the Unexpected EOF on one of my board updates yesterday, to create an Arduino forum thread:
forum.arduino.cc

Arduino 2.3.0 "Unexpected EOF"

@ptillisch and others: Yesterday I updated my main Arduino IDE install to 2.3.0 (I have 2 IDE 2 installs: latest released, nightly. I also updated most of the updated boards as well (Did not update Teensy as running latest beta). On one of them, I waw a message about "Unexpected EOF" ...
forum.arduino.cc forum.arduino.cc

As maybe there is an issue they need to be aware of.
 
kd5rxt-mark said:
I don't know if this is anything to worry about at this late date, but Arduino IDE 2.3.0 reports a build failure when I do CTRL-ALT-S (I'm not at my computer, but I believe it's called Save Binaries). I believe the build actually succeeds, as both hex & ehex files are built, & both work.

Mark J Culross
KD5RXT
Click to expand...
I tried this on Linux first and it minimized the IDE window. Then I selected 'Export Binary' from the sketch folder and it succeeded. Then I tried it in windows and a info window for my HP Pavilion popped up. I was able to disable that popup and retried the CTRL-ALT-S and it worked as expected with the IDE. It looks like the OS's are processing the CTRL-ALT-S before the IDE is...
 
wwatson said:
I tried this on Linux first and it minimized the IDE window. Then I selected 'Export Binary' from the sketch folder and it succeeded. Then I tried it in windows and a info window for my HP Pavilion popped up. I was able to disable that popup and retried the CTRL-ALT-S and it worked as expected with the IDE. It looks like the OS's are processing the CTRL-ALT-S before the IDE is...
Click to expand...
@wwatson:

Thanks for your observations. It looks like my laptop is behaving differently. I don't have the CTRL-ALT-S shortcut defined as anything in Windows, so that keystroke combo is actually being processed by the Arduino IDE. In my case, it does not matter whether I use the CTRL-ALT-S keystroke combo, or if I select Sketch > Export Compiled Binary from the menu, I get the same build failure (see additional details that were added into my original post).

Mark J Culross
KD5RXT
 
I'm packaging up a final 1.59 release now. Going to run several tests and if everything looks good it'll be released this evening.
 
kd5rxt-mark said:
I don't know if this is anything to worry about at this late date, but Arduino IDE 2.3.0 (along with TD 0.59.6, running under Windows 11pro, but I don't think either of these are pertinent) reports a build failure when initiating CTRL-ALT-S (I'm not at my computer, but I believe it's called Save BinariesExport Compiled Binary). I believe the build actually succeeds, as both hex & ehex files are built, & both work. Note that Arduino IDE 2.2.1 also showed the same unexpected behavior.

Mark J Culross
KD5RXT
Click to expand...
After some more analysis, this problem also seems to be the result of a "partial/incomplete" download on my Win11pro laptop. When I start the Arduino IDE 2.3.0, I see a pop-up status window indicating that the "https://www.pjrc.com/teensy/package_teensy_159b6_index.json" is being downloaded. If/when I get a failed build using CTRL-ALT-S, I can simply close & re-open the IDE, then reattempt another CTRL-ALT-S build. I repeat this build-fail-close-reopen-build-etc. cycle until the build succeeds (which presumably corresponds to whenever the "https://www.pjrc.com/teensy/package_teensy_159b6_index.json" file downloaded correctly/completely).

Sorry for any wasted time & effort on this . . . Microsoft strikes again !!

Mark J Culross
KD5RXT
 
For a first-time install, where no prior downloads are cached in {AppData}/Local/Arduino15/staging/packages, installing any version of Teensy seems to skip downloading the tools package. The IDE says everything was installed successfully, but in fact no copy of the tools package ends up installed or in the staging/packages folder. This manifests as "file does not exist" for precompile_helper when attempting to compile any sketch. Remove and install again, or install any other version is successful.

I'm pretty sure this is a bug in Arduino CLI. So far I can only get it to happen on Windows. Will do more experiments soon and open an issue on github.

EDIT: doesn't happen every time. So far no idea why. :(
 
Last edited:
Looks like they may also have a timing bug with running the pre_uninstall script. Teensy Loader does exit, so they are running the script. But the end result is the teensy.exe file and its old folder remain. Everything else gets deleted. So it really looks like they're not waiting for the pre_uninstall script to complete before deleting files.
 
PaulStoffregen said:
IDE 2.3.0 adding this little refresh button when it has new info. Why it sometimes does this rather than showing the new info is beyond me. [...]

1707324182000.png
Click to expand...

The icon appears when the user has selected a board that is different from the board the port was identified as.

In the example of your screenshot, port "usb:0/140000/0/2" was identified as a "Teensy 4.1" board, but you have selected the "Teensy 3.2 / 3.1' board.

It would not be appropriate for Arduino IDE to automatically change the board name shown on this menu item to "Teensy 4.1" because the "Board Selector" menu item is communicating which board the user has selected. If it changed the name to "Teensy 4.1", that would either be misinformation, or it would mean the IDE overrode the user's intention of having the "Teensy 3.2 / 3.1' board selected, which would make it impossible to use alternative boards platforms that provide definitions for boards that produce identifiable ports.

It is important to understand the difference between this "Board Selector' menu and the Tools > Port menu. The Tools > Port menu allows the user to select the port and only the port, with the board selection being made independently via the Tools > Board menu, so the Tools > Port menu only needs to communicate which port is selected. The "Board Selector" might appear at first glance to be just a list of ports, however, it has this hybrid nature of being used to select both the board and the port, so it must communicate both those things once the user has made a selection, and accommodate the fact that the user might have intentionally and correctly selected a different board than the one the port was identified as.
 
PaulStoffregen said:
Support for adding this sort of tool is still an open issue for the new IDE. Sadly, that issue is still open
Click to expand...
Note that full support for creating Arduino IDE 2.x extensions equivalent to the Arduino IDE 1.x Tools was completed by adding the previously missing capability for extensions to get the Arduino-specific state information from the IDE in arduino/arduino-ide#2110, which was released last summer in Arduino IDE 2.2.0 and is already in use by several 3rd party extensions.

As mentioned here, the only reason arduino/arduino-ide#2110 hasn't been closed as resolved is because documentation hasn't been produced for the feature:

from a technical standpoint we can close this issue as resolved. The outstanding task for Arduino is documenting:
  • The fact that adding additional capabilities to Arduino IDE by 3rd parties is possible through VS Code extensions.
  • The availability of Arduino state data to extensions via an API
Click to expand...
 
PaulStoffregen said:
Looks like they may also have a timing bug with running the pre_uninstall script.
Click to expand...

Indeed there was a timing problem with pre_uninstall.bat. But it's my fault, not Arduino's. The script was telling Teensy Loader to exit. But we had a race condition where Arduino IDE / CLI tries to delete the tools folder before Teensy Loader actually exits and the teensy.exe file becomes delete-able. Then on the next install, Arduino IDE / CLI doesn't try to install the tools, because it sees the leftover folder (and isn't smart enough to check if the folder's contents are correct). On the next compile, precompile_helper.exe is used first, so that's the error people see if the tools weren't installed.

I'm added a 0.8 second delay after asking Teensy Loader to quit, so Ardiuno IDE / CLI doesn't see the script finish until Teensy Loader has been given time to actually exist. The 4 versions we're currently publishing have been updated with this 0.8 second delay.

We'll probably continue to see people report "precompile_helper: file does not exist" for some time as people update from older versions with pre_uninstall.bat or the version with without this delay. But long term this problem should go away as everyone gets the new pre_uninstall script.
 
Not sure if this is related directly to the new core but every couple hours I have started getting the error: "internal error in mingw32_gt_pch_use_address, at config/i386/host-mingw32.c:190: MapViewOfFileEx" during compilation, fixed by deleting all Arduino IDE temporary files. just thought I would throw it out there. Might also be the new Arduino IDE 2.3.0 update that came out about the same time...
 
PCMaster2165 said:
getting the error: "internal error in mingw32_gt_pch_use_address, at config/i386/host-mingw32.c:190: MapViewOfFileEx" during compilation
Click to expand...

First I've heard of this error, though it appears to have been discussed on Arduino's forum.

forum.arduino.cc

Internal error in mingw32_gt_pch_use_address

Hi, I got that error while compiling using arduino IDE 2.0.4, I tried to reinstall it but w/o success. internal error in mingw32_gt_pch_use_address, at config/i386/host-mingw32.c:190: MapViewOfFileEx: Tentative d�acc�s � une adresse non valide. exit status 1 Compilation error: exit status 1...
forum.arduino.cc forum.arduino.cc

For several years Teensy has used a precompiled header for Arduino.h (which in turn includes a lot of other stuff) to try to speed up C++ compile times. As far as I know, we may be the only Arduino compatible board using a precompiled header.

Google search turns up a lot of cases that looks like traditional PC programing, not Arduino related.

Not sure what I can do about it, other than add it to my list of issues with unknown cause.
 
You must log in or register to reply here.
Back
Top