Teensyduino 1.54 Beta #11

Status
Not open for further replies.
Paul

Paul

Administrator
Staff member
Here is an eleventh beta test for Teensyduino 1.54.

This beta is meant as a 1.54 release candidate. Please report any bugs.
At this point, new features will be considered for 1.55. We need to
get 1.54 wrapped up and released!


Linux 32 bit:
https://www.pjrc.com/teensy/td_154-beta11/TeensyduinoInstall.linux32

Linux 64 bit:
https://www.pjrc.com/teensy/td_154-beta11/TeensyduinoInstall.linux64

Linux ARM:
https://www.pjrc.com/teensy/td_154-beta11/TeensyduinoInstall.linuxarm

Linux ARM64:
https://www.pjrc.com/teensy/td_154-beta11/TeensyduinoInstall.linuxaarch64

MacOS 10.10 to 11.4:
https://www.pjrc.com/teensy/td_154-beta11/Teensyduino_MacOS_Catalina.zip

MacOS 10.8 to 10.14:
https://www.pjrc.com/teensy/td_154-beta11/TeensyduinoInstall.dmg

Windows:
https://www.pjrc.com/teensy/td_154-beta11/TeensyduinoInstall.exe


Changes since Teensyduino 1.54-beta10:

Fault handler on Teensy 4 stores info, keeps USB active, reboots after 8 sec
Add CrashReport for printing or logging fault info
Fix NULL pointer read after String subString returning empty
Fix String operator == ambiguous overload
Disable Arduino Sketch-Upload Using Programmer menu item
LittleFS minor updates (mjs513)
 
Downloaded WIN version with no browser warning.
Installed with no errors into IDE 1.8.15
A couple of uploads work as expected.
 
Issues:

- Teensy LC waveplayer does not work (simple solution: fix buffer size Edit: simple, but not perfect because it needs more memory)
- Usb - mute Audio does not work. (edit: fixed)
- usb audio example uses DAC on T4
- usb audio uses a buffer not marked as DMAMEM (usb_audio_transmit_buffer, Line 297)
- see post from jonr in last beta thread.
- MMeissner: use #ifdef's so the correct SPI pins are selected on the Teensy 4.0/4.1 compared to the Teensy 3.2/3.5/3.6.
- not sure: CrashReport uses printf (edit: fixed)
- crashreport does not report interrupt number.
- unused interrupt is in RAM.
- SD-Library has a warning. (edit: fixed by Bill in newest version @ github)
- round(): double promotion
- _VectorsRam not volatile. (edit: fixed)
- MPU settings not optimal.

Feature request for 1.55: Easy way to change USB name, vendor id etc. whthout having to copy and patch the whole arduino directory. Currently, updates are very complicated :(
 
Last edited:
Indeed CrashReport.cpp has 6 calls to printf.
Quick hack remove of them - before and after:
Code: 
teensy_size: Memory Usage on Teensy 4.0:
[B]teensy_size:   FLASH: code:26828, data:5776, headers:8352   free for files:1990660
teensy_size:    RAM1: variables:12992, code:23752, padding:9016   free for local variables:478528
[/B]teensy_size:    RAM2: variables:12384  free for malloc/new:511904


teensy_size: Memory Usage on Teensy 4.0:
[B]teensy_size:   FLASH: code:11220, data:2520, headers:8784   free for files:2009092
teensy_size:    RAM1: variables:8896, code:8240, padding:24528   free for local variables:482624
[/B]teensy_size:    RAM2: variables:12384  free for malloc/new:511904
 
Just installed beta 11 over beta 10 on a Win10x64 home edition without issue. Again no blue screen from windows.

Ran a couple of fault examples - noticed a lot more descriptive info printed. One note on Unused_ISR.ino sketch. I am getting the following message:
Code: 
No Crash Data To Report
  Hopefully all is well, but certain types of crashes can't be reported:
	stuck in an infinite loop (technically, hardware still running properly)
	remaining in a low power sleep mode
	access to certain peripherals without their clock enabled (eg, FlexIO)
	change of CPU or bus clock speed without use of glitchless mux
Is this to be expected with this sketch?

The FPU_Turned_Off.ino goes into an continuous reboot with seeing any crash report unless you put a delay before turning off the FPU. Also, not sure continuous reboot is good, makes it very difficult to upload another sketch - pretty much have to do a 15s restore unless you time it right.
 
mjs513 said:
Ran a couple of fault examples - noticed a lot more descriptive info printed. One note on Unused_ISR.ino sketch. I am getting the following message:
Code: 
No Crash Data To Report
  Hopefully all is well, but certain types of crashes can't be reported:
	stuck in an infinite loop (technically, hardware still running properly)
	remaining in a low power sleep mode
	access to certain peripherals without their clock enabled (eg, FlexIO)
	change of CPU or bus clock speed without use of glitchless mux
Is this to be expected with this sketch?
Click to expand...

I'd expect a little more information.
 
Don't know what is possible without too much work - The Interrupt number would be fine.
Also, when a crash occurs inside an interrupt.
 
Separate Topic - LittleFS check
Ran @defragster LFSIntegrity sketch on the memory board for the 2GB memory chip with no issues - created files, deleted etc.

Also tested memory retention on restart for the T4 and TMM.
 
Frank B said:
Wow that's a big difference.
Click to expand...
defragster said:
Removed PrintF() ... did a github.com/PaulStoffregen/cores/pull/577
Click to expand...

I have mixed feelings about losing the nice formatting. 15K seems like a lot, but this needs to be considered in the context of a feature which is temporarily added for troubleshooting, then (usually) removed once the problem is solved. The design is for the always-built fault handler to be small & simple, and CrashReport which is optional can have lots of code to show it nicely.

I'm going to merge this now. Maybe in 1.55 we'll improve CrashReport with nicer formatting....
 
Frank B said:
- SD-Library has a warning.
Click to expand...

I can't reproduce this.

screenshot.png

Can you give me more detail, which board & settings, and which example to compile to reproduce the problem?
 
macOS 10.15.7

Installed and ran normally. My crashing programs now spring back to life! Where do I find info on how to use this 'Crash Reporter' ?
 
defragster said:
Downloaded WIN version with no browser warning.
Installed with no errors into IDE 1.8.15
A couple of uploads work as expected.
Click to expand...

Another note >> I didn't even notice :: I was NOT Warned about the EXE and I did not 'UNBLOCK' it manually under 'Properties'!
So it was marked SAFE to run - not 'danger from a download' - Very Nice.

Indeed dropping Printf compromises desired formatting - as noted in the PR. But some sketches already running on the edge using RAM and possibly adding 15K to debug won't fly. Some amount of alternate code might work in TD 1.55.

Though running the Faulty sketch - then running the example/TypicalUse - without power off - would expose a recorded CrashReport.

@Paul: Is there a place in 'examples' for a sketch like :: TypicalUse.ino?
> it would be a ready Forum reference for 'TypicalUse' and also as way to expose as noted above.
 
PaulStoffregen said:
I have mixed feelings about losing the nice formatting. 15K seems like a lot, but this needs to be considered in the context of a feature which is temporarily added for troubleshooting, then (usually) removed once the problem is solved. The design is for the always-built fault handler to be small & simple, and CrashReport which is optional can have lots of code to show it nicely.

I'm going to merge this now. Maybe in 1.55 we'll improve CrashReport with nicer formatting....
Click to expand...

If on initial crash the crash data is stored in a non volatile location, then a separate ino can be run to print out the Error data in a nice Formatted manner.
 
bicycleguy said:
Thanks defragster
Click to expand...

:)

BriComp said:
If on initial crash the crash data is stored in a non volatile location, then a separate ino can be run to print out the Error data in a nice Formatted manner.
Click to expand...

Indeed ... See p# 21 and #20


Just confirmed that on T_4 the .print("const char strings data") is stored in Flash like F() ... they do not go into RAM1


RE: SD Warnings :: Also ran listfiles.ino and did not see any warnings.
 
PaulStoffregen said:
I can't reproduce this.

View attachment 25148

Can you give me more detail, which board & settings, and which example to compile to reproduce the problem?
Click to expand...

I completely forgot that I use GCC10 as default.
So, sorry for the "false" alarm - but maybe someone (you, Bill) wants to fix it anyway now?:
Code: 
C:\Arduino\hardware\teensy\avr\libraries\SdFat\src\ExFatLib\ExFatPartition.cpp: In member function 'bool ExFatPartition::freeChain(uint32_t)':
C:\Arduino\hardware\teensy\avr\libraries\SdFat\src\ExFatLib\ExFatPartition.cpp:225:5: warning: 'next' may be used uninitialized in this function [-Wmaybe-uninitialized]
  225 |     if ((cluster + 1) != next || status == 0) {
      |     ^~
Any Sketch which includes SdFat will do.

Seen with Teensy 4.0, a Sketch with audio (but SD is not used).
 
Status
Not open for further replies.
Back
Top