Teensyduino 1.54 Beta #9

[Paul]

Here is a ninth beta test for Teensyduino 1.54.

Digital signatures have changed on Windows. Edge/IE might show a dire warning.
Please click the site is safe button.

Install into a clean copy of Arduino if you previously installed beta3 or beta4.


Linux 32 bit:
https://www.pjrc.com/teensy/td_154-b...nstall.linux32

Linux 64 bit:
https://www.pjrc.com/teensy/td_154-b...nstall.linux64

Linux ARM:
https://www.pjrc.com/teensy/td_154-b...stall.linuxarm

Linux ARM64:
https://www.pjrc.com/teensy/td_154-b...l.linuxaarch64

MacOS 10.10 to 10.15:
https://www.pjrc.com/teensy/td_154-b...S_Catalina.zip

MacOS 10.8 to 10.14:
https://www.pjrc.com/teensy/td_154-b...inoInstall.dmg

Windows:
https://www.pjrc.com/teensy/td_154-b...inoInstall.exe


Changes since Teensyduino 1.54-beta8:

Support for Arduino 1.8.15
Fix FreqMeasureMulti on Teensy 4 (joepasquariello)
Fix USB buffer bug on Teensy 3, remove old workaround (ryanrs)
Fix mempy crossing memory regions on Teensy 3.x
Fix EEPROM compile issue on Teensy 2.0
Align code & non-code boundaries to 1K on Teensy 4.x

[mjs513]

@Paul
Installed 1.8.15 and latest beta9 on a windows10x64 desktop. Besides the normal issue with windows wanting to block TD install went without a hitch.

Re-ran the sample sketch for memcpy crossing boundary to check the fix and works on the T3.2:

big_buf = 0x1fff9594 - 0x20003593
below   0xfffefdfc
across  0x0201fffe
above   0x04030201
trivial 0x0201fffe
aligned 0xfffefdfc 0x04030201
success

Noticed that the header info changed:

Memory Usage on Teensy 4.1:
  FLASH: code:9164, data:2324, headers:7960   free for files:8107016
   RAM1: variables:12992, code:6544, padding:26224   free for local variables:478528
   RAM2: variables:12384  free for malloc/new:511904

and on the Teensy MM:

Memory Usage on Teensy MicroMod:
  FLASH: code:7972, data:1112, headers:8320   free for files:16497668
   RAM1: variables:8896, code:6320, padding:26448   free for local variables:482624
   RAM2: variables:12384  free for malloc/new:511904

think before it was at 7210? This is just the blink sketch. Will probably play more later today.

[Silverlock]

Installed 1.8.15 and latest beta9 on a Raspberry Pi 3B. Teensyduino installer prompted me to copy 00-teensy.rules over to /etc/udev/rules.d/; I had an existing 49-teensy.rules there but I guess there's been some changes. In any case, everything installed and so far, no issues.

[ryanrs]

Mac OS 10.13.6 on an old mac pro.

Java exception on first run. Teensyduino.app starts and automatically opens the last sketch I was working on. I let it sit idle for ~30 secs, then the exception happens. Maybe checking for lib updates in the background, or some other async startup code?

I'm not compiling, loading, etc. Just start the app and let it auto-load the most recent sketch, and wait.

Is there a way to turn on more logging?

Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
	at cc.arduino.view.NotificationPopup.updateLocation(NotificationPopup.java:244)
	at cc.arduino.view.NotificationPopup.<init>(NotificationPopup.java:222)
	at cc.arduino.view.NotificationPopup.<init>(NotificationPopup.java:72)
	at cc.arduino.contributions.ContributionsSelfCheck.lambda$run$0(ContributionsSelfCheck.java:134)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
	at java.awt.EventQueue.access$500(EventQueue.java:97)
	at java.awt.EventQueue$3.run(EventQueue.java:709)
	at java.awt.EventQueue$3.run(EventQueue.java:703)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

[bicycleguy]

macOS 10.15.7

Installed and ran normally. No issues like @ryanrs. Wonder which version he installed? Will try some of my buggy code that's had issues in past.

[PaulStoffregen]

Noticed that the header info changed:

Yup. And I had ran into a last minute problems on Teensy 4.1 with the header size change, so I partially reverted it at the last minute since I didn't want to hold up this beta so we can all start running on Arduino 1.8.15.

Until now, we've had zero unused space between the IVT+bootdata structure and actual executable code. NXP's documentation recommends placing IVT+bootdata in its own 4K. They also recommend padding at the end of executable code so the CSF is aligned to 8K. Recently I did quite a bit of experimenting with the region protection registers, mostly just IOMUXC_GPR_GPR18 & IOMUXC_GPR_GPR19, and I assume the other 3 regions work the same way. The reference manual seems to imply 8 byte granularity, but they don't actually document this anywhere (not even in the super secret security manual). NXP's documentation is also confusing about "start" vs "end" and "TOP" vs "BOT". It only work if IOMUXC_GPR_GPR18 is programmed with a lower number than IOMUXC_GPR_GPR19. Those registers may indeed have 29 bits implemented if used with RAM. I tested only with the FlexSPI memory at 0x60000000 and learned by experimentation the hardware's configurable granularity for those registers is 1K. The low 10 bits are ignored. The register diagrams on pages 367 & 368 are probably wrong regarding bits 3-9 in those registers.

The increase in header size is just extra unused space so things are aligned to 1K, to allow use of those registers in the future.

Installed 1.8.15 and latest beta9 on a Raspberry Pi 3B. Teensyduino installer prompted me to copy 00-teensy.rules over to /etc/udev/rules.d/; I had an existing 49-teensy.rules there but I guess there's been some changes. In any case, everything installed and so far, no issues.

Yup, udev rules changed. On very slow boards (Jetson Nano in particular) a problem turned up where the Arduino IDE would try to reopen the serial device before all the udev rules were actually applied, when the serial monitor was on-screen and tries to automatically connect to the freshly reprogrammed hardware. The filename change seemed to "solve" the problem by just putting this file close to the start of many files udev processes.

The new udev rules also fix a long-standing problem with HID permissions. They work around several subtle differences (or bugs) in how different udev versions on several Linux distros work.

[PaulStoffregen]

Java exception on first run.

I'm going to call that an Arduino bug.

[bicycleguy]

My previously buggy code https://forum.pjrc.com/threads/66869...causes-crashes is still buggy, maybe less so. The graphics may have a little less streaking going on. Sound is still fine until the crash at around the same place.

[defragster]

Windows Install NEW VIRGIN laptop - ALL GOOD.

Downloaded on desktop : IDE 1.8.15 as ZIP and TD 1.54 b9.
> reported the TD as SAFE ( TWICE ) on download and in the Downloads folder - both time then asking to 'KEEP'.

Both downloads marked 'Properties / UNBLOCK'

Transferred those to Laptop and did IDE UNZIP and then TD 1.54 b9 Install to that folder no problem.

Plugged T_4.0 into USB for first Teensy it ever saw and opened IDE, set PORT to PJRC COM3, then SerMon and prior code running showing SerMon
> Opened example BlinkWithoutDelay with BOARD T_4.0 selected
> Edited code to print(millis()) on each blink and uploaded

Code compiled and uploaded and ran as expected!

<Edit / Update>
Swapped T_4.1 for T_4.0 with board change and uploaded same simple code No Problem.

[KurtE]

So far I have installed on both my main PC (Windows 10) and my old Mac notebook pro and both are working. I did not see any java error when I ran it on mac.

[defragster]

Did p#9 update/install on Desktop to fresh unzip of IDE 1.8.15 w/TD 1.54 b9

Build and TeensyLoader to T_4.1 works as expected with IDE SerMon display.

Same blinkwithout delay, now with an edit to print millis() when LED goes HIGH and after upload I see this - that looks like an IDE BUG?

"T:\\arduino-1.8.15\\hardware\\teensy/../tools/teensy_post_compile" -file=BlinkWithoutDelay.ino "-path=C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_876450" "-tools=T:\\arduino-1.8.15\\hardware\\teensy/../tools/" -board=TEENSY41
"T:\\arduino-1.8.15\\hardware\\teensy/../tools/teensy_size" "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_876450/BlinkWithoutDelay.ino.elf"
Memory Usage on Teensy 4.1:
  FLASH: code:10620, data:2388, headers:7464   free for files:8105992
   RAM1: variables:12992, code:8000, padding:24768   free for local variables:478528
   RAM2: variables:12384  free for malloc/new:511904
T:\arduino-1.8.15\hardware\teensy/../tools/teensy_post_compile -file=BlinkWithoutDelay.ino -path=C:\Users\Tim\AppData\Local\Temp\arduino_build_876450 -tools=T:\arduino-1.8.15\hardware\teensy/../tools -board=TEENSY41 -reboot -port=usb:0/140000/0/6/1/4 -portlabel=hid#vid_16c0&pid_0478 Bootloader -portprotocol=Teensy 
Invalid library found in T:\tCode\libraries\tmp: no headers files (.h) found in T:\tCode\libraries\tmp

There is a sketch (only file) in that TMP folder [ from 4/9/21 :: hm01b0_test.ino // so there some time without prior notice on older IDE ]- but not sure of ANY reason for the IDE to look there and complain - especially AFTER the build and upload is completed?

[KurtE]

Continue from Beta #8 and GCC 9...

When I build the simple program:

Archiving built core (caching) in: C:\Users\kurte\AppData\Local\Temp\arduino_cache_384166\core\core_25376d0426ffc526bfc9b59b374b7afb.a
Linking everything together...
"C:\\arduino-1.8.15\\hardware\\teensy/../tools/arm9/bin/arm-none-eabi-gcc" -O2 -Wl,--gc-sections,--relax "-TC:\\arduino-1.8.15\\hardware\\teensy\\avr\\cores\\teensy4/imxrt1062_t41.ld" -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -o "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_409950/foo.ino.elf" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_409950\\sketch\\foo.ino.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_409950/core\\core.a" "-LC:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_409950" -larm_cortexM7lfsp_math -lm -lstdc++
c:/arduino-1.8.15/hardware/tools/arm9/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(functexcept.o):(.ARM.exidx.text.unlikely._ZSt17__throw_bad_allocv+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text.unlikely._ZSt17__throw_bad_allocv'
c:/arduino-1.8.15/hardware/tools/arm9/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(functexcept.o):(.ARM.extab.text.unlikely._ZSt19__throw_logic_errorPKc+0x0): relocation truncated to fit: R_ARM_PREL31 against symbol `__gxx_personality_v0' defined in .text.__gxx_personality_v0 section in c:/arduino-1.8.15/hardware/tools/arm9/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o)
c:/arduino-1.8.15/hardware/tools/arm9/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(functexcept.o):(.ARM.exidx.text.unlikely._ZSt19__throw_logic_errorPKc+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text.unlikely._ZSt19__throw_logic_errorPKc'
c:/arduino-1.8.15/hardware/tools/arm9/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(functexcept.o):(.ARM.extab.text.unlikely._ZSt20__throw_length_errorPKc+0x0): relocation truncated to fit: R_ARM_PREL31 against symbol `__gxx_personality_v0' defined in .text.__gxx_personality_v0 section in c:/arduino-1.8.15/hardware/tools/arm9/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o)
c:/arduino-1.8.15/hardware/tools/arm9/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(functexcept.o):(.ARM.exidx.text.unlikely._ZSt20__throw_length_errorPKc+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text.unlikely._ZSt20__throw_length_errorPKc'
c:/arduino-1.8.15/hardware/tools/arm9/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(string-inst.o):(.ARM.exidx.text._ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_createERjj[_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_createERjj]+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text._ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_createERjj'
c:/arduino-1.8.15/hardware/tools/arm9/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_catch.o):(.ARM.extab.text.__cxa_begin_catch+0x0): relocation truncated to fit: R_ARM_PREL31 against symbol `__gxx_personality_v0' defined in .text.__gxx_personality_v0 section in c:/arduino-1.8.15/hardware/tools/arm9/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o)
c:/arduino-1.8.15/hardware/tools/arm9/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_catch.o):(.ARM.exidx.text.__cxa_begin_catch+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text.__cxa_begin_catch'
c:/arduino-1.8.15/hardware/tools/arm9/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o):(.ARM.exidx.text._ZL21base_of_encoded_valuehP15_Unwind_Context+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text._ZL21base_of_encoded_valuehP15_Unwind_Context'
c:/arduino-1.8.15/hardware/tools/arm9/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o):(.ARM.extab.text.__gxx_personality_v0+0x0): relocation truncated to fit: R_ARM_PREL31 against symbol `__gxx_personality_v0' defined in .text.__gxx_personality_v0 section in c:/arduino-1.8.15/hardware/tools/arm9/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o)
c:/arduino-1.8.15/hardware/tools/arm9/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o):(.ARM.exidx.text.__gxx_personality_v0+0x4): additional relocation overflows omitted from the output
collect2.exe: error: ld returned 1 exit status
Error compiling for board Teensy 4.1.

When I did a google search on: R_ARM_PREL31
I ran into the web page from about 2 and a half years ago: https://stackoverflow.com/questions/...t-r-arm-prel31

Where the person mentioned error like:

(.ARM.exidx.itcm.text+0x0): relocation truncated to fit: R_ARM_PREL31 against `.itcm.text'

They said they resolved it by using: -fno-exceptions.

Which I believe we are already doing...

[KurtE]

Another maybe interesting data for the R_ARM_PREL31 is from an NXP page: https://community.nxp.com/t5/i-MX-RT...on/td-p/981181

[defragster]

Continue from Beta #8 and GCC 9...

...
They said they resolved it by using: -fno-exceptions.

Which I believe we are already doing...

Indeed this shows on BUILD line for T_4.1 above:

Compiling sketch...
"T:\\arduino-1.8.15\\hardware\\teensy/../tools/precompile_helper" "T:\\arduino-1.8.15\\hardware\\teensy\\avr/cores/teensy4" "t:\\temp\\arduino_build_BlinkWithoutDelay.ino " "T:\\arduino-1.8.15\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -x c++-header -O2 -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -std=gnu++14 -fno-exceptions -fpermissive -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=154 -DARDUINO=10600 -DARDUINO_TEENSY41 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IT:\\arduino-1.8.15\\hardware\\teensy\\avr/cores/teensy4" "t:\\temp\\arduino_build_BlinkWithoutDelay.ino/pch/Arduino.h" -o "t:\\temp\\arduino_build_BlinkWithoutDelay.ino/pch/Arduino.h.gch"


ALSO note: Running BUILDER from command line TSET - that p#11 "Invalid library found" does not show in the console output.

[defragster]

Something odd indeed in the IDE - not sure if anything in TD build setup is causing this - or just IDE issue?

Back on NEW laptop w/T_4.1 and unaltered BlinkWithoutDelay.ino.

As a new install sketchbook is still default : C:\Users\Tim\Documents\Arduino
So like above p#11, made a tmp folder there to test and just copied the INO file "C:\Users\Tim\Documents\Arduino\libraries\tmp\Blin kWithoutDelay.ino" there, and after build and upload the same 'Invalid library found; is reported:

Memory Usage on Teensy 4.1:
  FLASH: code:9196, data:2324, headers:7928   free for files:8107016
   RAM1: variables:12992, code:6576, padding:26192   free for local variables:478528
   RAM2: variables:12384  free for malloc/new:511904
Invalid library found in C:\Users\Tim\Documents\Arduino\libraries\tmp: no headers files (.h) found in C:\Users\Tim\Documents\Arduino\libraries\tmp

Like the other machine that folder 'tmp' is extraneous and not part of Windows system path or usage.

[Silverlock]

Something odd indeed in the IDE - not sure if anything in TD build setup is causing this - or just IDE issue?

Back on NEW laptop w/T_4.1 and unaltered BlinkWithoutDelay.ino.

As a new install sketchbook is still default : C:\Users\Tim\Documents\Arduino
So like above p#11, made a tmp folder there to test and just copied the INO file "C:\Users\Tim\Documents\Arduino\libraries\tmp\Blin kWithoutDelay.ino" there, and after build and upload the same 'Invalid library found; is reported:

Hmm. I tried this on Raspbian (Linux ARM) and couldn't reproduce it. If it was an IDE issue I'd have expected it to crop up here too.

Modified the BlinkWithoutDelay sketch to print out millis when the LED went high; compiled and loaded fine.

Added a tmp folder inside the libraries folder and copied the unmodified BlinkWithoutDelay.ino file in there. Modified sketch still compiled and loaded as before. As expected, I couldn't open the copied sketch in the newly created tmp directory as the IDE complained that the folder name didn't match the sketch name.

I'll mull it over for a bit and see if any lightbulbs come on.

[defragster]

Not a Teensy problem
Looking to try for another non-PJRC board I switch to UNO since I have an SFun redboard here. On switching the board this shows:

Invalid library found in T:\tCode\libraries\tmp: no headers files (.h) found in T:\tCode\libraries\tmp

Also trying to upload - but not seeing it connect - but that line prints when trying.

Hmm. I tried this on Raspbian (Linux ARM) and couldn't reproduce it. If it was an IDE issue I'd have expected it to crop up here too.
...

That seems a valid test pointing to Windows only perhaps.

Note - rarely use the IDE here without TyCommander and building from SublimeText editor - which doesn't show this line.

Went back to IDE 1.8.13 with earlier TD 1.54 beta and removed TyCommander integration.

Within the IDE 1.8.13 this same behavior repeats - so it is Not New - it just went unobserved - and that file only went there to 'tmp' 9 days ago:

T:\arduino-1.8.13_t54\hardware\teensy/../tools/teensy_post_compile -file=BlinkWithoutDelay.ino -path=C:\Users\Tim\AppData\Local\Temp\arduino_build_98600 -tools=T:\arduino-1.8.13_t54\hardware\teensy/../tools -board=TEENSY41 -reboot -port=usb:0/140000/0/6/1/4 -portlabel=COM4 Serial -portprotocol=Teensy 
Invalid library found in T:\tCode\libraries\tmp: no headers files (.h) found in T:\tCode\libraries\tmp

Though - given it also does that on a virgin laptop freshly installed without any mods to ZIP install suggests they have something in there doing odd stuff looking specifically for "...\libraries\tmp"

Quick scan of github issues and issues OS_windows and recent PR's doesn't fins it noted - if I hit the right repository.

[Silverlock]

Ahh... figured out how to make the error message appear.

I decided to take the error message at face value. It finds a folder in the libraries folder. So it expects to find at least a header file in there, right? If you want to include a library, you include its header file in your sketch. If there's no header file, the IDE complains "how do you expect to include this library?" So I created an empty tmp folder in libraries, switched to Uno and got:

Invalid library found in /home/pi/Documents/sketchbook/libraries/tmp: no headers files (.h) found in /home/pi/Documents/sketchbook/libraries/tmp

Added an empty 'tmp.h' file in there, and the error message no longer appears when changing board type. Delete the .h file, error message comes back. So it means exactly what it says. Either put an empty 'tmp.h' file in there or get rid of the tmp folder altogether and the problem should vanish.

Now, as to where that tmp folder came from originally... shrug!

Further data point: I went back to my original test (tmp folder with BlinkWithoutDelay.ino file in it) and still didn't get the error message on a compile. I only see if when I change board types. That seems to be what triggers the library scan in my setup.

Further further data point: scratch that. It's now doing it after the upload, just like you're describing. I don't know why I didn't see that behaviour the first time around, but it's doing it consistently now. But getting rid of the tmp folder gets rid of the error message, so that still makes sense.

[defragster]

Ahh... figured out how to make the error message appear.
...

Call this solved - it is in LIBRARIES and it parses that for any candidates - which explains it finding it on switching boards.

Odd that Raspian didn't find it the same way

That folder was put there 'by me' to save a tmp copy of a file, without thinking of the LIB parsing process - and it acts differently when doing command line build as the IDE isn't triggered for board requests.

> tmp folders removed.

[PaulStoffregen]

Where the person mentioned error like:

(.ARM.exidx.itcm.text+0x0): relocation truncated to fit: R_ARM_PREL31 against `.itcm.text'

They said they resolved it by using: -fno-exceptions.

Maybe gcc 9 needs newlib recompiled with -fno-exceptions?

[luni]

Maybe gcc 9 needs newlib recompiled with -fno-exceptions?

The last answer from the link Kurt gave in #13 seems to describe the root cause and how to solve it. See here https://community.nxp.com/t5/i-MX-RT...ght/true#M5280. Looks like the change you did to the linker script in the commit I referenced above subtly changed something with the exidx definitions.

That:

- If the C++ project uses -fno-exceptions then it should be safe to discard .ARM.exidx input sections using a /DISCARD/ output section in the linker script. In this case __exidx_start/__exidx_end markers should still be placed in FLASH somewhere but may refer to an empty range.

might be worth a try

[PaulStoffregen]

I'd like to ask everyone to please run this very simple Serial.begin() test program on Teensy 4.0 or 4.1, first with no serial monitor window on your screen. Do all 5 lines appear when you open it a few seconds after uploading? Then please upload again while the serial monitor is still on screen. Do you get all 5 lines when the serial monitor automatically reconnects? And which operating system are you using?

If you comment out Serial.begin(9600), you should get only part of the output, since this doesn't wait for the serial monitor.

void setup() {
  Serial.begin(9600);
  Serial.println("first line");
  dots(5);
  Serial.println("second line");
  dots(5);
  Serial.println("third line");
  dots(5);
  Serial.println("fourth line");
  dots(50);
  Serial.println("last line");
}

void dots(int n) {
  for (int i=0; i < n; i++) {
    delay(20);
    Serial.print(".");
  }
}

void loop() {
}

A frequently asked questions comes from people who run code written for Arduino Uno, where opening the serial monitor hard reboots the board, and where the USB connection is implemented by a separate chip which doesn't reboot. Those programs always have Serial.begin(), but most of them don't use while(!Serial) to wait for the serial monitor. When people use only printing this way in setup(), they believe Teensy isn't working because nothing shows up in the serial monitor.

With 1.54's release, I want to bring back a previous idea of making Serial.begin() try to delay until the serial monitor is open, so people running those program will get a "just works out of the box" experience. But we don't want the delay to be too long for everyone else (the reason this idea was previously abandoned). This latest beta tries to be smarter about the delay, waiting only 0.7 seconds if there is no USB activity. If USB enumeration has begun, it waits up to 2 seconds.

Of course, you can avoid this delay completely by just not using Serial.begin(), which does nothing on Teensy (except now, this delay - but nothing functional). 1.54-beta9 implements this delay only on Teensy 4.x. I'm planning to put it onto the other boards in the next beta.

The big question is whether these fixed delays, 0.7 seconds if the PC hasn't sent the configure device command or 2.0 second if it has, give a good serial monitor experience with all operating systems across a variety of computers of different speeds and amounts of installed software?

[mjs513]

I'd like to ask everyone to please run this very simple Serial.begin() test program on Teensy 4.0 or 4.1, first with no serial monitor window on your screen. Do all 5 lines appear when you open it a few seconds after uploading? Then please upload again while the serial monitor is still on screen. Do you get all 5 lines? And which operating system are you using?
....
With 1.54's release, I want to bring back a previous idea of making Serial.begin() try to delay until the serial monitor is open, so people running those program will get a "just works out of the box" experience. But we don't want the delay to be too long for everyone else (the reason this idea was previously abandoned). This latest beta tries to be smarter about the delay, waiting only 0.7 seconds if there is no USB activity. If USB enumeration has begun, it waits up to 2 seconds.

System: Windows PC Win10x64 using 1.8.15b9.....

Loaded up the sketch on a T4.1. Waited about 10 seconds but only the first line showed up:

first line
...

it I only wait for about 1 second:

first line
.....second line
.....third line
.....fourth line
..................................................last line

with serial monitor open I get all five lines again.

On a teensy 3.2 (was curious):
Waiting again for about 10 seconds:

first line
.....second line
...

See same output if I wait only 5 seconds (not a 5 count by 1000's)

and of course with the serial monitor open on the T3.2:

first line
.....second line
.....third line
.....fourth line
..................................................last line

[KurtE]

I tried it with T4.1 currently have integrated with TyCommander...

If I have the Commander open with Serial.open()

first line
.....second line
.....third line
.....fourth line
..................................................last line

Without Serial.open()

.....third line
.....fourth line
..................................................last line

When I did not have TyCommander open it opened it automatically and received the whole output

Reverted back to Serial monitor... I downloaded and ran again with Serial.begin. As soon as it downloaded I clicked the Serial monitor button and output was:

first line
.....................................................last line

[mjs513]

@PaulStoffregen

Back when we were testing Beta7 I had an issue with SerialMonitor hanging (reference: https://forum.pjrc.com/threads/66357...l=1#post271493), @defragster confirmed this in his follow on post. We initially saw this issue during beta testing: https://forum.pjrc.com/threads/54711...l=1#post213179. Looks like the problem has returned.

If you run the following simple sketch:

void setup() {
  // initialize serial communication at 9600 bits per second:
  Serial.begin(115200);
}

// the loop routine runs over and over again forever:
void loop() {
  // print out the value you read:
  Serial.println(millis());
  //delay(1);        // delay in between reads for stability
}

it pretty much hangs after a 1 second or less. If you add the delay(1) in the SerMon doesn't hang.