Teensyduino 1.48 Beta #3

[Paul]

Here is a third beta test for Teensyduino 1.48.


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

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

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

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

Mac OS-X:
https://www.pjrc.com/teensy/td_148-b...inoInstall.dmg

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


Changes since Teensyduino 1.48-beta2

Add CPU Speed menu for Teensy 4.0
Fix SoftwareSerial on Teensy 4.0 (KurtE)
Fix Wire on Teensy 4.0 when I2C device prior NAK (KurtE)
Add startup hooks on Teensy 4.0 (Defragster)
Fix Audio TDM & I2C2 on Teensy 4.0
Improve Audio I/O on overclocked Teensy 3.6
Fix ST7735_t3 DMA (KurtE)
Update TeensyThreads

[PaulStoffregen]

My hope is to release 1.48 soon, probably very close to this 3rd beta.

The serial monitor timestamp feature still missing. Sorry, it just isn't going to happen for 1.48, since the speedup stuff bypasses that part of the serial monitor's abstraction layers.

After we have a stable 1.48 release, I'm going to start work again on the missing USB types and porting the remaining Teensy3-only libraries like OctoWS2811.

[mjs513]

Morning all

Downloaded and install on a Windows10x64 with no issues during the install.

Can copy from a closed sermon of course.

Tried the demosauce sketch that identified the issue hang with the PIT timer in startup and that worked now without issue.

Changed clock speed from 600Mhz to 816Mhz and that work - tested with one of the ILI9341 test sketches. Ok - tested up to 1Ghz.(no cooling)
1. at 1Ghz - lost usb on upload probably max temp shutdown
2. at 960 T4 kept resetting - probably max temp reached
3. at 912 T4 ran a few seconds then lost usb but sketch kept running.

[manitou]

My hope is to release 1.48 soon, probably very close to this 3rd beta.

The serial monitor timestamp feature still missing. Sorry, it just isn't going to happen for 1.48, since the speedup stuff bypasses that part of the serial monitor's abstraction layers.

After we have a stable 1.48 release, I'm going to start work again on the missing USB types and porting the remaining Teensy3-only libraries like OctoWS2811.

Any thoughts on WDOG reset not working on T4 (1060) but did work on T4B1 (1050)? Discussed in
https://forum.pjrc.com/threads/54711...l=1#post217661
and
https://forum.pjrc.com/threads/57810...t-on-Teensy4-0

[defragster]

Downloaded but not yet installed B_3. I see MAX voltage updated to hardware spec for OC.

...
Changed clock speed from 600Mhz to 816Mhz and that work - tested with one of the ILI9341 test sketches. Ok - tested up to 1Ghz.(no cooling)
1. at 1Ghz - lost usb on upload probably max temp shutdown
2. at 960 T4 kept resetting - probably max temp reached
3. at 912 T4 ran a few seconds then lost usb but sketch kept running.

With added startup hook - a serial# port could be made active to push out TempMon data before setup.

Paul posted the TWO benchmarks - last I ran them both ran at 700 but only one at 800 MHz - would be interesting to see results with new higher MAX V on more than one unit.

[KurtE]

Beta 3 installed W10 1.8.10 so far so good.

[defragster]

1.8.10 w/ TD 1.48 B3 installed - with PORTABLE dir in place so it came up using that subset directory. Funny just noticed it was not doing VERBOSE compile as that was unset in current Portable.

No problem - looks good for WIN 10

I removed the sketchbook\libraries\TeensyThreads and the now updated included version work to run the USBHost LAN Ethernet build!

TeensyThreads is giving this minor warning {it was before too}:

T:\arduino_1.8.10\hardware\teensy\avr\libraries\Te ensyThreads\TeensyThreads.cpp:327:13: warning: 'void context_pit_empty()' defined but not used [-Wunused-function]
static void context_pit_empty() {}

Multiple libraries were found for "TeensyThreads.h"
 Used: T:\arduino_1.8.10\hardware\teensy\avr\libraries\TeensyThreads
Multiple libraries were found for "fnet.h"
 Used: T:\arduino_1.8.10\portable\sketchbook\libraries\FNET
Multiple libraries were found for "USBHost_t36.h"
 Used: T:\arduino_1.8.10\hardware\teensy\avr\libraries\USBHost_t36
Multiple libraries were found for "ASIXEthernet.h"
 Used: T:\arduino_1.8.10\portable\sketchbook\libraries\TeensyASIXEthernet
Using library USBHost_t36 at version 0.1 in folder: T:\arduino_1.8.10\hardware\teensy\avr\libraries\USBHost_t36 
Using library TeensyASIXEthernet in folder: T:\arduino_1.8.10\portable\sketchbook\libraries\TeensyASIXEthernet (legacy)
Using library TeensyThreads at version 1.0.1 in folder: T:\arduino_1.8.10\hardware\teensy\avr\libraries\TeensyThreads 
Using library FNET at version 0.1.2 in folder: T:\arduino_1.8.10\portable\sketchbook\libraries\FNET

[mjs513]

Downloaded but not yet installed B_3. I see MAX voltage updated to hardware spec for OC.



With added startup hook - a serial# port could be made active to push out TempMon data before setup.

Paul posted the TWO benchmarks - last I ran them both ran at 700 but only one at 800 MHz - would be interesting to see results with new higher MAX V on more than one unit.

Just ran the Coremark up through 1Ghz, no problems. Was running Demosauce so a heavier load:


Believe @manitou also ran coremarks

[PaulStoffregen]

The multiple libraries warning when only a single library exists is (probably) a bug in arduino-builder.exe. That's not going to be fixed by 1.48, since we currently do not patch arduino-builder in any way.

[defragster]

@Paul - Portable works for install and afterward without Portable. The SPEED menu works { good now I can remove the HACK to TSET and use external editor and TyComm! }. And at least at 600 and 816 MHz the T_4 spped to run well with the MAX voltage update.

Exited 'Portable' - renamed 'Portable' to 'xPortable' - restart IDE in the system based prior config - all prior sketches opened.

As above removed sketchbook\libraries\TeensyThreads and built USBHost LAN code - running Teensy 4.0 at 816MHz - does not result in change to test throughput { PC LAN to USBHost LAN is at 30 Kbits/sec or ~27 ms for 102,400 Bytes in 20 transfers } - but it does run.

NOTE: At 816 MHz loop()/second is 10,276,692 under TeensyThreads where 2nd thread handles USB/LAN and dropping back to 600 MHz the loop()/sec count is 7,509,250

Seeing ~8900 high speed pings in 10 seconds with MSFT PSPING64 { same at 600 and 816 MHz : ALSO same on T_3.6 at 256 MHz }:

T:\T_Downloads\PSTools>psping64.exe -i 0 -q -n 10s 192.168.0.23

PsPing v2.10 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2016 Mark Russinovich
Sysinternals - www.sysinternals.com

Pinging 192.168.0.23 with 32 bytes of data:
10 seconds (1 warmup pings) connecting test: 100%

Ping statistics for 192.168.0.23:
  Sent = 8993, Received = 8993, Lost = 0 (0% loss),
  Minimum = 0.31ms, Maximum = 6.69ms, Average = 0.89ms

BOTH of these now run at 600 and 816 MHz - one of them before failed at 800 MHz - before the Max Voltage bump.

Coremark at 600 MHZ: Iterations/Sec : 2313.57
Coremark at 816 MHZ: Iterations/Sec : 3146.39



600 MHz :: RSA Signature Speed Test Signature computation took 0.085 seconds
816 MHz :: RSA Signature Speed Test Signature computation took 0.063 seconds


Didn't test TempMon with speed change or re-run the StartupHooks test yet ...

[defragster]

The multiple libraries warning when only a single library exists is (probably) a bug in arduino-builder.exe. That's not going to be fixed by 1.48, since we currently do not patch arduino-builder in any way.

Good to know you saw it - will wait for fix.

[Hacky]

Thanks for the update, Paul. Did you have a chance to look why the PulsePlosition library coming with TD does not compile anymore with T4?
(see also https://forum.pjrc.com/threads/57872...l=1#post217887)

[PaulStoffregen]

Did you have a chance to look why the PulsePlosition library coming with TD does not compile anymore with T4?

PulsePosition hasn't been ported yet. It's filled with FTM/TPM timer code. Only Teensy 3.x & LC have those timers. NXP put different timers in this IMXRT new chip.

I will eventually port PulsePosition, maybe to the FlexPWM timers, maybe to the quad timers. But that's not going to happen for the 1.48 release.

[PaulStoffregen]

Any thoughts on WDOG reset not working on T4 (1060) but did work on T4B1 (1050)?

Not sure. I tried several different software reset ways. All fail and I don't know why.

Not going to hold up the 1.48 release for this. But I have put it on my list of bugs to investigate.

[defragster]

@Paul - check speed text in boards.txt.

Selecting :: teensy40.menu.speed.1008=1.008 GHz (overclock, cooling req'd)
Uses :: teensy40.menu.speed.1008.build.fcpu=1000000000

Starts with F_CPU_ACTUAL :: F_CPU=996000000

Changing to this works:: teensy40.menu.speed.1008.build.fcpu=1008000000

F_CPU=1008000000


FYI: Paul when the 1062 goes offline from OC'ing F_CPU Windows Consoles shows things like this - the last line came on button press:

Unable to open COM39 for reboot request
Windows Error Info: Access is denied.
more ideas... https://forum.pjrc.com/threads/40632...l=1#post126667
Teensy did not respond to a USB-based request to enter program mode.
Please press the PROGRAM MODE BUTTON on your Teensy to upload your sketch.
Unable to open COM39
Now able to open COM39 (Windows said this port was ready before it was actually ready...)Disconnect COM39

This T_4 is on the TallDog beta breakout - so some heat can dissipate and runs okay for simple temp mon test at 960 MHz.

@mjs513 - this sketch has startup hooks coded and attempts to grab the TempMon ISR's?

TempMonTest.ino

I didn't hook up Serial1 or other UART printing for when USB goes offline - but not sure the temp is going HIGH and halting gracefully? prints temps and unless it crashes fast once it hits a 60° tipping point it seems to not be catching the TempMon code for any notice or pBlink calls?

[mjs513]

Not sure. I tried several different software reset ways. All fail and I don't know why.

Not going to hold up the 1.48 release for this. But I have put it on my list of bugs to investigate.

@PaulStoffregen

This seems to be the same issue associated with SCB_AIRCR not resetting the T4. Its like the T4 appears to turn-off instead of resetting. If you reapply power it turns back on.

[mjs513]

@mjs513 - this sketch has startup hooks coded and attempts to grab the TempMon ISR's?

TempMonTest.ino
I didn't hook up Serial1 or other UART printing for when USB goes offline - but not sure the temp is going HIGH and halting gracefully? prints temps and unless it crashes fast once it hits a 60° tipping point it seems to not be catching the TempMon code for any notice or pBlink calls

@defragster

Thanks for moding the example. When I ran coremark up to 1.008Ghz(1ghz) it ran without issue. When I ran demosauce that was when things started happening with resetting and loosing USB

[defragster]

@defragster

Thanks for moding the example. When I ran coremark up to 1.008Ghz(1ghz) it ran without issue. When I ran demosauce that was when things started happening with resetting and loosing USB

Note above - requesting 1008 actually runs at 996. I am finding that TempMonTest.ino will go offline about always at 1008 ( 996 or 1008 with edit ) - and prints go funny at 960 with a couple garb chars showing - and sometime it just vanishes on USB with no special blinky lights as expected. Thought you might check the code - not sure it is getting as far as seeing PANIC temp of 95°C before failure. Originally I was testing that with lower threshold temps in TempMon - but that was weeks back and that code is gone now

[mjs513]

Note above - requesting 1008 actually runs at 996. I am finding that TempMonTest.ino will go offline about always at 1008 ( 996 or 1008 with edit ) - and prints go funny at 960 with a couple garb chars showing - and sometime it just vanishes on USB with no special blinky lights as expected. Thought you might check the code - not sure it is getting as far as seeing PANIC temp of 95°C before failure. Originally I was testing that with lower threshold temps in TempMon - but that was weeks back and that code is gone now

I'll check it out - you guys are night owls while I am a morning person - so give me a little bit. Still have my original sketch where I can adjust the temps. If I remember right it is currently set for 90degC - may have to change the temp alarms for testing

[defragster]

Right 90 - recalled 95 last look - but that was wrong ...

static uint16_t frequency = 0x03U;
static uint32_t highAlarmTemp = 85U;
static uint32_t lowAlarmTemp = 25U;
static uint32_t panicAlarmTemp = 90U;

Posted sketch had them extern'd IIRC to edits in TempMon … some time back ...

[mjs513]

Right 90 - recalled 95 last look - but that was wrong ...



Posted sketch had them extern'd IIRC to edits in TempMon … some time back ...

Have to find the original doc I used to set 90 may be able to raised to 95.

[PaulStoffregen]

Selecting :: teensy40.menu.speed.1008=1.008 GHz (overclock, cooling req'd)
Uses :: teensy40.menu.speed.1008.build.fcpu=1000000000

Oh, opps, I missed editing that number. Already something to fix for 1.49...

As far as trying other overclocking, just editing those numbers in boards.txt lets you try pretty much any frequency. The PLL can generate up to 1.296 GHz. But the DCDC converter is limited to 1.575 volts and it's already at that maximum with 1 GHz. How much faster the CPU can really run will only depend on cooling.

If anyone has a *lot* of time to try overclocking, I'd love to hear some feedback about whether the rate set_arm_clock() increases voltage with frequency is good. I'll admit, this line was pretty much just a guess on my part based on only a couple quick trials, and on the early 1052 beta boards.

#define OVERCLOCK_STEPSIZE  28000000

This number means set_arm_clock() will increase the voltage by a 0.025V step for every 28 MHz over the 600 MHz. How much voltage should really be used is just a matter of experimentation. NXP's datasheet gives no guidance, other than 1.3V is the maximum recommended and we're supposed to use 0.95V for 24 MHz, 1.15V for 25-528 MHz, and 1.25V for 529-600 MHz.

[Maziac]

I updated to Catalina and did a fresh install of Arduino 1.8.10.
I started Arduino, gave it full access rights to all drives and **was able to compile a sketch**.

Then I executed the Teensyduino.app 1.48-beta3.
After it finished I ran Arduino, set the board to TeensyLC and chose an USB Type.
Then run "Verify" (e.g. Blink sketch) and get an error.

Arduino: 1.8.10 (Mac OS X), TD: 1.48-beta3, Board: "Teensy LC, Serial + Keyboard + Mouse + Joystick, 48 MHz, Smallest Code, US English"

/Volumes/SDDPCIE2TB/Applications/Arduino.app/Contents/Java/arduino-builder -dump-prefs -logger=machine -hardware /Volumes/SDDPCIE2TB/Applications/Arduino.app/Contents/Java/hardware -hardware /Users/bob/Library/Arduino15/packages -tools /Volumes/SDDPCIE2TB/Applications/Arduino.app/Contents/Java/tools-builder -tools /Volumes/SDDPCIE2TB/Applications/Arduino.app/Contents/Java/hardware/tools/avr -tools /Users/bob/Library/Arduino15/packages -built-in-libraries /Volumes/SDDPCIE2TB/Applications/Arduino.app/Contents/Java/libraries -libraries /Users/bob/Documents/Arduino/libraries -fqbn=teensy:avr:teensyLC:usb=serialhid,speed=48,opt=osstd,keys=en-us -ide-version=10810 -build-path /var/folders/gr/817lnxns137006z93d2dz7b00000gn/T/arduino_build_819008 -warnings=none -build-cache /var/folders/gr/817lnxns137006z93d2dz7b00000gn/T/arduino_cache_290583 -verbose /var/folders/gr/817lnxns137006z93d2dz7b00000gn/T/untitled1941406174.tmp/sketch_oct12a/sketch_oct12a.ino
loading libs from /Users/bob/Documents/Arduino/libraries: reading dir /Users/bob/Documents/Arduino/libraries: open /Users/bob/Documents/Arduino/libraries: operation not permitted

Error compiling for board Teensy LC.

Then I changed board back to Uno but also the same:

Arduino: 1.8.10 (Mac OS X), TD: 1.48-beta3, Board: "Arduino/Genuino Uno"

/Volumes/SDDPCIE2TB/Applications/Arduino.app/Contents/Java/arduino-builder -dump-prefs -logger=machine -hardware /Volumes/SDDPCIE2TB/Applications/Arduino.app/Contents/Java/hardware -hardware /Users/bob/Library/Arduino15/packages -tools /Volumes/SDDPCIE2TB/Applications/Arduino.app/Contents/Java/tools-builder -tools /Volumes/SDDPCIE2TB/Applications/Arduino.app/Contents/Java/hardware/tools/avr -tools /Users/bob/Library/Arduino15/packages -built-in-libraries /Volumes/SDDPCIE2TB/Applications/Arduino.app/Contents/Java/libraries -libraries /Users/bob/Documents/Arduino/libraries -fqbn=arduino:avr:uno -ide-version=10810 -build-path /var/folders/gr/817lnxns137006z93d2dz7b00000gn/T/arduino_build_819008 -warnings=none -build-cache /var/folders/gr/817lnxns137006z93d2dz7b00000gn/T/arduino_cache_290583 -prefs=build.warn_data_percentage=75 -prefs=runtime.tools.avrdude.path=/Users/bob/Library/Arduino15/packages/arduino/tools/avrdude/6.3.0-arduino17 -prefs=runtime.tools.avrdude-6.3.0-arduino17.path=/Users/bob/Library/Arduino15/packages/arduino/tools/avrdude/6.3.0-arduino17 -prefs=runtime.tools.arduinoOTA.path=/Users/bob/Library/Arduino15/packages/arduino/tools/arduinoOTA/1.3.0 -prefs=runtime.tools.arduinoOTA-1.3.0.path=/Users/bob/Library/Arduino15/packages/arduino/tools/arduinoOTA/1.3.0 -prefs=runtime.tools.avr-gcc.path=/Users/bob/Library/Arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino5 -prefs=runtime.tools.avr-gcc-7.3.0-atmel3.6.1-arduino5.path=/Users/bob/Library/Arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino5 -verbose /var/folders/gr/817lnxns137006z93d2dz7b00000gn/T/untitled1941406174.tmp/sketch_oct12a/sketch_oct12a.ino
loading libs from /Users/bob/Documents/Arduino/libraries: reading dir /Users/bob/Documents/Arduino/libraries: open /Users/bob/Documents/Arduino/libraries: operation not permitted

Error compiling for board Arduino/Genuino Uno.

I.e. after executing Teensyduino.app the Arduino.app does not work anymore.

Any idea.
Maybe a problem with the access rights? But as stated above: I gave Arduino full access to the hard disks.

Not sure if this if of importance: I installed Arduino.app not in the usual /Applications directory but on an external hard disk /Volumes/exthd/Applications/Arduino.app.

[Theremingenieur]

Running already macOS Catalina 15.1 beta here since last night. Fresh install of Arduino 1.8.10, granted rights, the installed Teensyduino 1.48 final release, not beta. Launches, loads sketches, compiles, and uploads without problems.

[Maziac]

It's working now for me as well.

Maybe this helps someone:
To get it to work I had to remove the complete "Arduino" folder under home Documents.
Then I reinstalled the libraries.

I guess this had something to do with the access rights.