Teensyduino 1.55 Beta #3

Status
Not open for further replies.
Paul

Paul

Administrator
Staff member
Here is a third beta test for Teensyduino 1.55.


Linux 32 bit:
https://www.pjrc.com/teensy/td_155-beta3/TeensyduinoInstall.linux32

Linux 64 bit:
https://www.pjrc.com/teensy/td_155-beta3/TeensyduinoInstall.linux64

Linux ARM:
https://www.pjrc.com/teensy/td_155-beta3/TeensyduinoInstall.linuxarm

Linux ARM64:
https://www.pjrc.com/teensy/td_155-beta3/TeensyduinoInstall.linuxaarch64

MacOS 10.10 to 11.x:
https://www.pjrc.com/teensy/td_155-beta3/Teensyduino_MacOS_Catalina.zip

MacOS 10.8 to 10.14:
https://www.pjrc.com/teensy/td_155-beta3/TeensyduinoInstall.dmg

Windows:
https://www.pjrc.com/teensy/td_155-beta3/TeensyduinoInstall.exe


Changes since Teensyduino 1.55-beta2:

SdFat use MAINTAIN_FREE_CLUSTER_COUNT on 32 bit Teensy
Do not build .lst file - very slow for large code
Sketch > Export Compiled Binary now saves .ehex, if possible
Consistent startup sequence on Teensy 3 & 4
Add startup_default_middle_hook()
Fix Serial.begin() delay with serial emulation and Teensy 3
String compatibility with Arduino for C++ iterators
Fix DMAChannel triggerContinuously() on Teensy 4 (Kurt E)
Fix CCM_ANALOG_PLL_ENET define (Shawn Silverman)
Improve arm_dcache_delete() documentation
Rename LittleFS example folders
LittleFS_RAM always starts blank
Update ST7735_t3
Update TeensyThreads
Fix Teensy Loader GUI stalls with locked Teensy 4
Show .ehex filename in status bar when automatically using .ehex
Clearer messages about hex vs ehex in Verbose Info
Only show percentage flash used after connecting to real hardware
Avoid fusewrite fuse memory corruption if different key used
Improve error messages in fusewrite sketch
 
Something different - went to install TD but gave me an error that it could upload to the folder. Checked in Task Manager and had 2 copies of Teensy_reboot.exe still running. Once closed it installed without an issue.

Sketch > Export Compiled Binary now saves .ehex, if possible
Click to expand...
Verified that an .ehex and .hex are both save to the sketch directory.

Do not build .lst file - very slow for large code
Click to expand...
verified that the .lst file is not created using Tim's code4code sketch but took about 1:47 seconds to go from upload arrow to when TeensySize prints. Not sure anyway around this for that large of a program.

Show .ehex filename in status bar when automatically using .ehex
Click to expand...
Very nice and thank you.
Capture.PNG

Improve error messages in fusewrite sketch
Click to expand...
Not sure how much clearer that can be
Code: 
17:58:31.485 (loader): File "Code4Code.ino.hex". 1337344 bytes, 66% used
17:58:31.485 (loader): File "Code4Code.ino.hex" opened, but "Code4Code.ino.ehex" will actually be used
17:58:31.532 (loader): elf appears to be for Teensy 4.0 (IMXRT1062) (2031616 bytes)
17:58:31.532 (loader): elf binary data matches hex file
17:58:31.532 (loader): elf file is for Teensy 4.0 (IMXRT1062)
17:58:31.532 (loader): using encrypted ehex (required - secure mode is locked)

Ok next up is the fusewrite with wrong key and see what happens.

UPDATE:
Avoid fusewrite fuse memory corruption if different key used
Click to expand...
Like the message that TL shows that ehex can not be written because wrong key and nothing uploads and sketch already on T4 continues to run.

Also checked if the correct key is used with fuse write - nice output to let you know it was already written don't remember if that was there before:
Code: 
....
[B]Decryption key was previously written & locked, so
it can not be directly verified, but the following
test will confirm whether decryption works.[/B]

Bus Encryption Engine is active (this program is encrypted)
  Encryption is assumed to be working if this program runs.
 
Installed okay, no complaints - except I left IDE open even after it told me teensy_ports was open.
> Backed up both times and completed as desired

Rebuilt C4CbenchM @4,000 func#()'s WIP okay. Faster without .lst!

Upload to Locked_Beta and Prod boards worked - but something funny happened - may have triggered second before first was complete?
> Got bumped from 'AUTO' for fast reboot?

four _isr rates give this for T4_Locked - not shown yet the 4 rates 24, 48, 96, 192 us update rates on the IntervalTimer:
Code: 
PERF _isr() char[] Test % Diff versus production T4:
	_isr() char[] Test @24 us % Diff of 0.997
	_isr() char[] Test @48 us % Diff of 0.965
	_isr() char[] Test @96 us % Diff of 0.945
	_isr() char[] Test @192 us % Diff of 0.918

Refining the 'net' diffs from the Cascade versus Direct calls like in Excel.
 
Last edited:
Just triggered the mystery 'erasing' sequence from TeensyLoader hitting 'TyComm USB Reset' : after Button Upload
> It doesn't program because TyComm is monitoring for Serial connect and it does?

Here is full Verbose since Beta 3 loaded ...
Attached Verbose : View attachment B3_log.zip

Needed to be ZIPped because 296 KB is bigger than limit 195.3

Long time idle so a big break in time stamps to find the events:
17:11:46.113 (loader): redraw, image 9
19:07:11.023 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
Click to expand...

Here is a shorter Log.txt: View attachment B3_log2.txt
> Verify Build
> TyComm 'Bootloader' on production
-> Proper upload
> TyComm 'Reset' on Locked Beta T4
-> FALSE upload - valid Reset
> TyComm 'Bootloader' on Locked Beta T4
-> Proper upload

NOTE: Works the same doing UPLOAD to EACH of the above, then hitting Reset on the first
> Verify Build
> TyComm 'Bootloader' on Locked Beta T4
-> Proper upload
> TyComm 'Bootloader' on production
-> Proper upload
> TyComm 'Reset' on production
-> FALSE upload - valid Reset
 
Last edited:
Just triggered the DUAL LEDS RED & ORANGE:

> Did a new Verify
> on Production accidental with TyComm Reset not Bootloader
> Changed to Beta_T4 : Did TyComm Bootloader
-->> Looked down and saw DUAL LEDS
- > last Verify code was NOT uploaded

Here are Four T_4's running the same variation of Code4Code > C4CbenchM.ino::
>> Both UPDATED : https://github.com/Defragster/T4LockBeta { c4cbenchM has non printing version of isEncrypt( bool ) for ID string create }

Code: 
10379960 nor ns: @600 PERF _isr() char[] Test % Diff versus production T4:
	_isr() char[] Test @24 us % Diff of 1.000
	_isr() char[] Test @48 us % Diff of 1.000
	_isr() char[] Test @96 us % Diff of 1.001
	_isr() char[] Test @192 us % Diff of 1.000

10379960 nor ns: @600 PERF Cascade .vs. Direct Func#()'s Test :
	 Test Diff of 14.019
	% Diff to Production of 0.999

10379960 nor ns: @600 PERF with ISR Cascade .vs. Direct Func#()'s Test :
	 Test Diff of 18.934  {this is most nebulous}
	% Diff to Production of 0.951

Hint: this is the locked T4_Beta
Code: 
[B]10379970 ENC SM[/B]: @600 PERF _isr() char[] Test % Diff versus production T4:
	_isr() char[] Test @24 us % Diff of 0.996
	_isr() char[] Test @48 us % Diff of 0.969
	_isr() char[] Test @96 us % Diff of 0.950
	_isr() char[] Test @192 us % Diff of 0.892

10379970 ENC SM: @600 PERF Cascade .vs. Direct Func#()'s Test :
	 Test Diff of 16.962
	% Diff to Production of 0.826

10379970 ENC SM: @600 PERF with ISR Cascade .vs. Direct Func#()'s Test :
	 Test Diff of 24.728  {this is most nebulous}
	% Diff to Production of 0.728

Code: 
6052840 nor ns: @600 PERF _isr() char[] Test % Diff versus production T4:
	_isr() char[] Test @24 us % Diff of 1.000
	_isr() char[] Test @48 us % Diff of 1.000
	_isr() char[] Test @96 us % Diff of 1.001
	_isr() char[] Test @192 us % Diff of 1.000

6052840 nor ns: @600 PERF Cascade .vs. Direct Func#()'s Test :
	 Test Diff of 14.072
	% Diff to Production of 0.996

6052840 nor ns: @600 PERF with ISR Cascade .vs. Direct Func#()'s Test :
	 Test Diff of 20.643  {this is most nebulous}
	% Diff to Production of 0.872

Code: 
6683800 nor ns: @600 PERF _isr() char[] Test % Diff versus production T4:
	_isr() char[] Test @24 us % Diff of 1.000
	_isr() char[] Test @48 us % Diff of 1.000
	_isr() char[] Test @96 us % Diff of 1.001
	_isr() char[] Test @192 us % Diff of 1.000

6683800 nor ns: @600 PERF Cascade .vs. Direct Func#()'s Test :
	 Test Diff of 14.020
	% Diff to Production of 0.999

6683800 nor ns: @600 PERF with ISR Cascade .vs. Direct Func#()'s Test :
	 Test Diff of 20.153  {this is most nebulous}
	% Diff to Production of 0.893

If you don't see near 1.000 on Production board it comes from nearest build values seen with bool bPrintExtra = true
 
TSET command line build works from SubLime

@Paul - All looking good for general use Arduino and Command line call of the builder - ala TSET!
> many builds and uploads and no faults or issues - that can't be perhaps explained by jumping between 2 or 4 T4's doing Reset and Bootloader Upload via USB command.
> Not doing .lst file in each build (plus perhaps local system changes) results in expected build times. with upload just over 10 secs for 10 func() c4cBM and just over 1 minute with 4,000 func()'s

Not sure I changed anything in TSET (core local file date was 8/28) from Beta1 ... may have been a timing error or caught something since beta improved.
> The Upload doesn't finish before TyCommander reports 'failed to reset' - but the upload completes - at least with 4K func()'s in C4CbenchM
NOTES for TSET:
> answer LAST question "T" not "Y" to upload with TeensyLoader
> For MULTI INO sketches :: Do the build of Compile.cmd from the MAIN INO! {then any file in folder will run Build right}
> tested BUILD UPLOAD (normal), Verify (notifies TLoader of new HEX location) , CLEAN (Full rebuild empties TEMP)
> New copy of TSET on github, as always save or edit CMD1.BAT
BTW: If you have Multiple of same Teensy online - it works to pick one to upload directly, then Button or GUI 'Bootloader' the others. All work as normal on TyComm serial Monitor.
And of course don't integrate TyComm for the Beta Locked - then building opens Teensy Loader

UPDATED :: Defragster/T4LockBeta/tree/main/C4CbenchM
> had not replaced the .txt content to swap number of funcs() with reduced number of Pi Digits calculated from 60 to 12, so saw ERRORS.
> Results seem to change with build :( So for side by side compare use bool bPrintExtra = true; to see the raw numbers.
-> it does shows the decrypting from FLASH adds overhead, though the 'nebulous' Combo ISR & char[] test are very close so it may be that the decrypt [data & code] happens in parallel, or it is so busy with lost cache that the difference is a wash - or maybe there is an error in the calc logic.
> Hitting 'Enter' triggers loop() to run repeatedly and show the Temp, and allows resetting of bool "bPrintExtra = false;" at compile time -

Here is Console output - you can see it is not from IDE because the string "teensy_size:" is present:
Code: 
Building Sketch: ".\C4CbenchM.ino"
Using board 'teensy40' from platform in folder: C:\T_Drive\Arduino_1.8.16_155\hardware\teensy\avr
Using core 'teensy4' from platform in folder: C:\T_Drive\Arduino_1.8.16_155\hardware\teensy\avr
Detecting libraries used...
"C:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -E -CC -x c++ -w -g -Wall -ffunction-sections -fdata-sections -nostdlib -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=155 -DARDUINO=10600 -DARDUINO_TEENSY40 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IC:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy\\avr\\cores\\teensy4" "R:\\temp\\arduino_build_C4CbenchM.ino\\sketch\\C4CbenchM.ino.cpp" -o nul
Generating function prototypes...
"C:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -E -CC -x c++ -w -g -Wall -ffunction-sections -fdata-sections -nostdlib -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=155 -DARDUINO=10600 -DARDUINO_TEENSY40 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IC:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy\\avr\\cores\\teensy4" "R:\\temp\\arduino_build_C4CbenchM.ino\\sketch\\C4CbenchM.ino.cpp" -o "R:\\temp\\arduino_build_C4CbenchM.ino\\preproc\\ctags_target_for_gcc_minus_e.cpp"
"C:\\T_Drive\\Arduino_1.8.16_155\\tools-builder\\ctags\\5.8-arduino11/ctags" -u --language-force=c++ -f - --c++-kinds=svpf --fields=KSTtzns --line-directives "R:\\temp\\arduino_build_C4CbenchM.ino\\preproc\\ctags_target_for_gcc_minus_e.cpp"
Compiling sketch...
"C:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy/../tools/precompile_helper" "C:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy\\avr/cores/teensy4" "R:\\temp\\arduino_build_C4CbenchM.ino" "C:\\T_Drive\\Arduino_1.8.16_155\\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=155 -DARDUINO=10600 -DARDUINO_TEENSY40 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IC:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy\\avr/cores/teensy4" "R:\\temp\\arduino_build_C4CbenchM.ino/pch/Arduino.h" -o "R:\\temp\\arduino_build_C4CbenchM.ino/pch/Arduino.h.gch"
Using previously compiled file: R:\temp\arduino_build_C4CbenchM.ino\pch\Arduino.h.gch
"C:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -c -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=155 -DARDUINO=10600 -DARDUINO_TEENSY40 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IR:\\temp\\arduino_build_C4CbenchM.ino/pch" "-IC:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy\\avr\\cores\\teensy4" "R:\\temp\\arduino_build_C4CbenchM.ino\\sketch\\C4CbenchM.ino.cpp" -o "R:\\temp\\arduino_build_C4CbenchM.ino\\sketch\\C4CbenchM.ino.cpp.o"
Compiling libraries...
Compiling core...
Using precompiled core: R:\temp\arduino_cache_C4CbenchM.ino\core\core_4291cde6f2aeb6bd53a075bd323e65cd.a
Linking everything together...
"C:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -O2 -Wl,--gc-sections,--relax "-TC:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy\\avr\\cores\\teensy4/imxrt1062.ld" -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -o "R:\\temp\\arduino_build_C4CbenchM.ino/C4CbenchM.ino.elf" "R:\\temp\\arduino_build_C4CbenchM.ino\\sketch\\C4CbenchM.ino.cpp.o" "R:\\temp\\arduino_build_C4CbenchM.ino/..\\arduino_cache_C4CbenchM.ino\\core\\core_4291cde6f2aeb6bd53a075bd323e65cd.a" "-LR:\\temp\\arduino_build_C4CbenchM.ino" -larm_cortexM7lfsp_math -lm -lstdc++
"C:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objcopy" -O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0 "R:\\temp\\arduino_build_C4CbenchM.ino/C4CbenchM.ino.elf" "R:\\temp\\arduino_build_C4CbenchM.ino/C4CbenchM.ino.eep"
"C:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objcopy" -O ihex -R .eeprom "R:\\temp\\arduino_build_C4CbenchM.ino/C4CbenchM.ino.elf" "R:\\temp\\arduino_build_C4CbenchM.ino/C4CbenchM.ino.hex"
"C:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy/../tools/teensy_secure" encrypthex TEENSY40 "R:\\temp\\arduino_build_C4CbenchM.ino/C4CbenchM.ino.hex"
encrypting 1107968 bytes to R:\temp\arduino_build_C4CbenchM.ino/C4CbenchM.ino.ehex
"C:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy/../tools/teensy_post_compile" -file=C4CbenchM.ino "-path=R:\\temp\\arduino_build_C4CbenchM.ino" "-tools=C:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy/../tools/" -board=TEENSY40
"C:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy/../tools/stdout_redirect" "R:\\temp\\arduino_build_C4CbenchM.ino/C4CbenchM.ino.sym" "C:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objdump" -t -C "R:\\temp\\arduino_build_C4CbenchM.ino/C4CbenchM.ino.elf"
"C:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy/../tools/teensy_size" "R:\\temp\\arduino_build_C4CbenchM.ino/C4CbenchM.ino.elf"
teensy_size: Memory Usage on Teensy 4.0:
teensy_size:   FLASH: code:972344, data:134680, headers:9132   free for files:915460
teensy_size:    RAM1: variables:90848, code:28968, padding:3800   free for local variables:400672
teensy_size:    RAM2: variables:12384  free for malloc/new:511904
      upload@10379970-Teensy  Uploading to board '10379970-Teensy' (Teensy 4.0)
      upload@10379970-Teensy  Triggering board reboot
      upload@10379970-Teensy  Waiting for Teensy Loader
      upload@10379970-Teensy  Failed to reset board '10379970-Teensy'
[Finished in 70.9s]
 
Last edited:
@Paul

As @defragster said
All looking good for general use Arduino ........
> many builds and uploads and no faults or issues - that can't be perhaps explained .......
Click to expand...

Last night and this morning I tried to fault the Locked T4 doing successive uploads of Tim's code4code sketch and then hitting the pgm button a couple of times in between to reload the sketch without any faults. In addition I uploaded several sketches one after the other with PGM button pushes in between without faulting. Only one time did I get the RED and orange light at the same time but that was my fault - I pressed the PGM button at almost the same time as a sketch was uploading I did see a Message window pop up from TL but wasn't on the screen long enough to read it - another PGM push loaded the sketch properly so again was probably me.
 
Morning all,
Installed latest beta...

I am not sure if the SEREMU fix is working properly now in this build? That is I build MTPD sketch (using the in build MTP Disk) and lost most of the startup output and also it felt like I was back to longer delays on startup...
So Again ran slightly modified test:
Code: 
//#include <MTP.h>

void setup() {
  while (!Serial && millis() < 5000) ;
  Serial.begin(115200);
  if (!Serial) Serial.println("!Serial");
  Serial.println(millis(), DEC);
  Serial.print(CrashReport);

  Serial.println("Enter something to go boom");
}
uint16_t loop_count = 0;
void loop() {
  if (Serial.read() != -1) {
    uint8_t *ptr = 0;
    *ptr = 99;
  }
  Serial.printf("Loop Count: %u\n", ++loop_count);
  delay(250);
}
When I run this With USB type of Serial I get:
Code: 
[COLOR="#FF0000"]461[/COLOR]
CrashReport:
  A problem occurred at (system time) 5:24:28
  Code was executing from address 0x88
  CFSR: 82
	(DACCVIOL) Data Access Violation
	(MMARVALID) Accessed Address: 0x0 (nullptr)
	  Check code at 0x88 - very likely a bug!
	  Run "addr2line -e mysketch.ino.elf 0x88" for filename & line number.
  Temperature inside the chip was 48.98 °C
  Startup CPU clock speed is 600MHz
  Reboot was caused by auto reboot after fault or bad interrupt detected
Enter something to go boom
Loop Count: 1
Loop Count: 2
Loop Count: 3
When I run it with USB Type of: MTP Disk (experimental) It runs, but notice difference in how long it takes to run:
Code: 
[COLOR="#FF0000"]6030[/COLOR]
CrashReport:
  A problem occurred at (system time) 5:26:42
  Code was executing from address 0x88
  CFSR: 82
	(DACCVIOL) Data Access Violation
	(MMARVALID) Accessed Address: 0x0 (nullptr)
	  Check code at 0x88 - very likely a bug!
	  Run "addr2line -e mysketch.ino.elf 0x88" for filename & line number.
  Temperature inside the chip was 48.33 °C
  Startup CPU clock speed is 600MHz
  Reboot was caused by auto reboot after fault or bad interrupt detected
Enter something to go boom
Loop Count: 1
Loop Count: 2
Loop Count: 3
Loop Count: 4
I ran this both with locked T4 and normal T4... Maybe something screwy on my machine, but ...
 
KurtE said:
Morning all,
Installed latest beta...

I am not sure if the SEREMU fix is working properly now in this build? That is I build MTPD sketch (using the in build MTP Disk) and lost most of the startup output and also it felt like I was back to longer delays on startup...
So Again ran slightly modified test:
Code: 
//#include <MTP.h>

void setup() {
  while (!Serial && millis() < 5000) ;
  Serial.begin(115200);
  if (!Serial) Serial.println("!Serial");
  Serial.println(millis(), DEC);
  Serial.print(CrashReport);

  Serial.println("Enter something to go boom");
}
uint16_t loop_count = 0;
void loop() {
  if (Serial.read() != -1) {
    uint8_t *ptr = 0;
    *ptr = 99;
  }
  Serial.printf("Loop Count: %u\n", ++loop_count);
  delay(250);
}
Click to expand...
Just ran it here on my Win10x64 machine and got very similar results:

With USB type of Serial = 412
With USB Type of: MTP Disk (experimental) = 6048

This is on a locked T4 with the latest updates.
 
Just ran on Ubuntu machine and with Beta2 and latest, timing was about 880ms with Beta3 about 990... Not sure if real difference or just slight delta... Will see how it runs on MAC next
 
mjs513 said:
Went back to the Beta1 thread and found @KurtE's initial timing timing test: https://forum.pjrc.com/threads/67989-Teensyduino-1-55-Beta-1?p=288241&viewfull=1#post288241, which shows it was 1011ms. Only thing not 100% sure about is if that was with Windows or Ubuntu. @KurtE?
Click to expand...

That one was Windows 10...

Note on MAC it was about 300ms...
But I am not sure if MAC has any MTP stuff built in...
At one point was playing with OpenMTP... But...

Sorry Paul, I know this is not an MTP release... Am just checking for differences from Beta2 to Beta3 and it felt like it had changed between the two betas...

Edit: tried running beta 2 with Arduino 15 with current cores\teensy4 same timings... Not sure what changed... Or maybe I was dreaming when it came up in about a second earlier... (Beta 1 thread)
 
Last edited:
MTP Disk - startup timing differences...

Figured out what was different, between then and now. I believe I mentioned I had a modified usb_desc.h file that I was trying.
That I changed it to be closer to Audio...

That is it has two interfaces: MTP and SEREMU...
Current in build:
Code: 
#define MTP_INTERFACE		0	// MTP Disk
#define SEREMU_INTERFACE      1 // Serial emulation

Timeout in this case about: 6 seconds

Change to:
Code: 
#define MTP_INTERFACE		1	// MTP Disk
#define SEREMU_INTERFACE      0 // Serial emulation
Timeout < 1 second:
Code: 
994
CrashReport:
  A problem occurred at (system time) 8:42:21
  Code was executing from address 0x88
  CFSR: 82
	(DACCVIOL) Data Access Violation
	(MMARVALID) Accessed Address: 0x0 (nullptr)
	  Check code at 0x88 - very likely a bug!
	  Run "addr2line -e mysketch.ino.elf 0x88" for filename & line number.
  Temperature inside the chip was 53.52 °C
  Startup CPU clock speed is 600MHz
  Reboot was caused by auto reboot after fault or bad interrupt detected
Enter something to go boom
Loop Count: 1
Loop Count: 2
Loop Count: 3

To late to change?
 
@KurtE
Just made the changed and on my locked T4 shows even better:
Code: 
344
CrashReport:
  A problem occurred at (system time) 11:53:50
  Code was executing from address 0x88
  CFSR: 82
	(DACCVIOL) Data Access Violation
	(MMARVALID) Accessed Address: 0x0 (nullptr)
	  Check code at 0x88 - very likely a bug!
	  Run "addr2line -e mysketch.ino.elf 0x88" for filename & line number.
  Temperature inside the chip was 57.06 °C
  Startup CPU clock speed is 600MHz
  Reboot was caused by auto reboot after fault or bad interrupt detected
Enter something to go boom
Loop Count: 1
Loop Count: 2
Loop Count: 3
Loop Count: 4
before booming the T4
Code: 
1001
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
Enter something to go boom
Loop Count: 1
Loop Count: 2
 
KurtE said:
Morning all,
Installed latest beta...

I am not sure if the SEREMU fix is working properly now in this build? That is I build MTPD sketch (using the in build MTP Disk) and lost most of the startup output and also it felt like I was back to longer delays on startup...
...
Click to expand...

When I tested with the dual while() {blink mostly off then on} on prior thread - the change to .begin() in cores showed function - but it was still slow - where the first 5 second wit exhausted - it didn't make it any faster for Serial to come online with the patch applied.

i.e.: it worked - but was still slow to come online with MTP_exp

Just tried that USB==Serial build fine on TyComm with :: firstSerial @462
-> but never starts on USB==MTP_exp as before

with USB==MTP_exp Opening IDE and starting t_serial.exe gives :: firstSerial @6851 - hadn't printed first Serial millis() before - but that is what the blinks showed.

<crosspost - hand edited the PR==608 and it works better here>
Making Kurts usb_desc.h edits: #elif defined(USB_MTPDISK)
#define MTP_INTERFACE 1 // MTP Disk
#define SEREMU_INTERFACE 0 // Serial emulation

IDE t_SerMon reports a faster and good :: firstSerial @792

> change doesn't help TyComm for whatever reason.

Did get same results with CmdLine :: teensy_serialmon.exe -v usb:0/140000/0/6/1/1


<EDIT> :: BTW - I built the MTP_Boom.ino from TSet {as Serial and MTP_exp} and it worked! { only problem hinted at above } is that not having IDE open means there is no easy way to start a usable SerMon - either open IDE or dig the USB: out of TLoader/Verbose in a DOS box.
 
Didn't build any LittleFS - but just confirmed all RAM drives : PSRAM or DMAMEM that can generally persist across warm restart for some avenue of utility have been set to destroy on .begin()

> memset(ptr, 0xFF, size); // always start with blank slate

Not sure why YMMV loss of utility ... but that is now the case.

<edit>: yes, I was a big fan of the old awesome behavior.
> If the user wanted this destructive 'safe' behavior it is easy to do low level format or even Quick format on start in the examples with YMMV note on removing that.
 
Last edited:
defragster said:
Didn't build any LittleFS - but just confirmed all RAM drives : PSRAM or DMAMEM that can generally persist across warm restart for some avenue of utility have been set to destroy on .begin()

> memset(ptr, 0xFF, size); // always start with blank slate

Not sure why YMMV loss of utility ... but that is now the case.

<edit>: yes, I was a big fan of the old awesome behavior.
> If the user wanted this destructive 'safe' behavior it is easy to do low level format or even Quick format on start in the examples with YMMV note on removing that.
Click to expand...

Wouldn't worry too much about LittleFS @KurtE and I have been testing the heck out of it while testing MTP. Think the only thing we haven't tested was QSPI since we have been primarily using the Locked T4. Tested NAND, SPI flash, RAM, Program etc. Works very well with what we have been doing with MTP as well.
 
mjs513 said:
Wouldn't worry too much about LittleFS @KurtE and I have been testing the heck out of it while testing MTP. Think the only thing we haven't tested was QSPI since we have been primarily using the Locked T4. Tested NAND, SPI flash, RAM, Program etc. Works very well with what we have been doing with MTP as well.
Click to expand...

My worry was with the RAM feature/function loss :(

I migrated "LittleFS usuage" <sic> into C4CbenchM.ino running it to PROG Flash before starting the C4C code.

Just added the INO to the sketch folder and had to prototype the two versions of PrintDir - and take out the SPI usage for PROG and luckily downsize the PROG to 824 KB:
Code: 
teensy_size: Memory Usage on Teensy 4.0:
teensy_size:   FLASH: code:1003656, data:136800, headers:8468   [B]free for files:882692[/B]
teensy_size:    RAM1: variables:90848, code:56808, padding:8728   free for local variables:367904
teensy_size:    RAM2: variables:12384  free for malloc/new:511904

So it works with Func4000()'s !!!

Then I had to comment :: //myfs.quickFormat();
>> which is what RAM_drive could do if they worried about prior content

So the first thing that Example does is WIPE drive Media before each start Upload, cold or warm start.

So with that gone I duped the bigfile to bigfile2 and it Persists and grows with each Restart or Upload.


>> Just decided to try the same on second Unlockble T4 Beta
- It works to Not Full Erase Flash

ALSO TESTING BUG FIX - on Unlockable Beta with Locked Bad pem.key from Beta 2
It seems to have properly recognized the issue
Code: 
Writing public key hash
Error: public key hash not written properly!
       Secure mode will not run your programs

Decryption key was previously written & locked, so
it can not be directly verified, but the following
test will confirm whether decryption works.


Testing Bus Encryption Engine
Success: ciphertext decryption test passed :-)

Notice: JTAG is still enabled

Notice: Secure mode is not yet set, unencrypted
        programs are still allowed to run

@Paul Question on FuseWrite.ino_BETA3 as written:
Those [8] sequential tests seem ODD - perhaps it pans out as the best and proper way . But what if one of the 8 was keyed with no bits set as parts of a proper key? Perhaps impossible, or not likely, one set of 32 bits would have the same 'unset' value. Just seems all [8] should be tested and if ANY fails - then none should be written?

And as noted above there is a typo in comment of LittleFS_Usage.ino :: LittleFS usuage from the LittleFS library
 
Paul and all,

As @mjs513 mentioned, we have been testing out lots of the LittleFS versions, as well as some SD card stuff. And as mentioned doing most of it with T4 and T4.1 as to compare locked version versus unlocked...

I have also done a little now with T3.6, as a quick and dirty sanity test to make sure our updates to FS two classes compiles and the like.

I used one of @mjs513 sketches that does do a little FS on several different media, including the Memory board that Paul built with 4 memories. As well as an SD Card connected to pin 8...

It built and runs.

Ran into a few interesting things.

A couple of times, I receive the message in the build area, about not being able to open the port... Something like reporting ready before it was...

Also had issue with one SDCard that this sketch could not open. Also the listfiles SD example could not open...

But then I ran the SD example: SDFat_usage and it appeared like it worked... I then took card over to PC, which looked ok, copied a few more files to it...And then brought back to T3.6 and it liked the cared then...
Probably some hiccup like corrupted. Or maybe it does not like a Card with nothing on it... Will play some more.

LittleFS_RAM ... So far I am only using this mostly for test cases and I can see if I want a quick and dirty drive for MTP... sometimes persist/never-persist. Probably something to discuss after the release cycle...

But maybe the right answer for this is to make two different classes for it... That is if you want you can create something like: LittleFS_RAMPERSIST... or some such name.

But since it is setup to not persist, wondering if this code within the class is needed
Code: 
	static int static_sync(const struct lfs_config *c) {
		if ( c->context >= (void *)0x20200000 ) {
			//Serial.printf("    arm_dcache_flush_delete: ptr=0x%x, size=%d\n", c->context, c->block_count * c->block_size);
			arm_dcache_flush_delete(c->context, c->block_count * c->block_size );
		}
		return 0;
	}
Also wondering how often it is called. That is, is this called every time LittleFS writes out a block of memory? Or when file closed...
What overhead does this give us: That is if I am reading this right, if I have a T4.1 with an 8MB SRAM on it with LittleFS, this will call the arm_dcache_flush_delete on the whole 8mb range, so
the loop in the call will loop 262144 times... So hope not called often. Also not sure why it does flush_delete? So the next memory reads in LittleFS will then have to fetch back from real memory.

Anyone bench marked this to see if any differences?

Just wondering

EDIT: Tried with T4.1... Created RAM of 4mb... so far working... Calls static_sync reasonably infrequent. I built it with MTP... When I copied files to it maybe twice for the file... Actually maybe one per file plus one for index...
 
Last edited:
KurtE said:
Paul and all,

As @mjs513 mentioned, we have been testing out lots of the LittleFS versions, as well as some SD card stuff. And as mentioned doing most of it with T4 and T4.1 as to compare locked version versus unlocked...

I have also done a little now with T3.6, as a quick and dirty sanity test to make sure our updates to FS two classes compiles and the like.

I used one of @mjs513 sketches that does do a little FS on several different media, including the Memory board that Paul built with 4 memories. As well as an SD Card connected to pin 8...

It built and runs.

Ran into a few interesting things.

A couple of times, I receive the message in the build area, about not being able to open the port... Something like reporting ready before it was...

Also had issue with one SDCard that this sketch could not open. Also the listfiles SD example could not open...

But then I ran the SD example: SDFat_usage and it appeared like it worked... I then took card over to PC, which looked ok, copied a few more files to it...And then brought back to T3.6 and it liked the cared then...
Probably some hiccup like corrupted. Or maybe it does not like a Card with nothing on it... Will play some more.

LittleFS_RAM ... So far I am only using this mostly for test cases and I can see if I want a quick and dirty drive for MTP... sometimes persist/never-persist. Probably something to discuss after the release cycle...

But maybe the right answer for this is to make two different classes for it... That is if you want you can create something like: LittleFS_RAMPERSIST... or some such name.

But since it is setup to not persist, wondering if this code within the class is needed
Code: 
	static int static_sync(const struct lfs_config *c) {
		if ( c->context >= (void *)0x20200000 ) {
			//Serial.printf("    arm_dcache_flush_delete: ptr=0x%x, size=%d\n", c->context, c->block_count * c->block_size);
			arm_dcache_flush_delete(c->context, c->block_count * c->block_size );
		}
		return 0;
	}
Also wondering how often it is called. That is, is this called every time LittleFS writes out a block of memory? Or when file closed...
What overhead does this give us: That is if I am reading this right, if I have a T4.1 with an 8MB SRAM on it with LittleFS, this will call the arm_dcache_flush_delete on the whole 8mb range, so
the loop in the call will loop 262144 times... So hope not called often. Also not sure why it does flush_delete? So the next memory reads in LittleFS will then have to fetch back from real memory.

Anyone bench marked this to see if any differences?

Just wondering

EDIT: Tried with T4.1... Created RAM of 4mb... so far working... Calls static_sync reasonably infrequent. I built it with MTP... When I copied files to it maybe twice for the file... Actually maybe one per file plus one for index...
Click to expand...

I can say - having put the cache_flush there it is called often and regularly on block and indexing changes - often enough that nothing in the cache is at risk of not being in RAM with restart it seemed - seeing the .printf() output. I put in a PR that it doesn't need the _delete - but that was on the line I copied into the code. I asked at the time in that Beta and it wasn't discussed and left in - that was when the persistent was enabled - and it should not delete.

I never paid attention to the length of the flush - given LFS often duplicates changes - the flush/sync may be associated with the cleanup after changes when blocks are committed.

Having a way to maintain a persistence - certainly across 8-16 MB of PSRAM makes sense and was tested directly and indirectly. A large amount of data could be quickly 'buffered' there and in the event of warm restart - it would not have been lost. Now it is encoded with LFS storage structures - and deleted on .begin(). It does add overhead to direct memory storage - but as planned it is common file storage interface.
 
@KurtE - can only test DMAMEM on T_4's active. Sync is HUGE on each file - the whole media size.

Code: 
[  0.35 M](0.35438 M elap) Awaiting input 0123456789RdDwcghkFqvplmusSBbyYxfan+-? loops left 0 >1
:: /B_file.txt     arm_dcache_flush_delete: ptr=0x20200000, size=399360
    arm_dcache_flush_delete: ptr=0x20200000, size=399360
    arm_dcache_flush_delete: ptr=0x20200000, size=399360
 +++ size 0: Add 1152 @KB/sec 774.19 	  Verify 1152 Bytes  @KB/sec 2456.29
:: /C_file.txt     arm_dcache_flush_delete: ptr=0x20200000, size=399360
    arm_dcache_flush_delete: ptr=0x20200000, size=399360
 +++ size 0: Add 1664 @KB/sec 1218.16 	  Verify 1664 Bytes  @KB/sec 2548.24
:: /1_dir/D_file.txt     arm_dcache_flush_delete: ptr=0x20200000, size=399360
    arm_dcache_flush_delete: ptr=0x20200000, size=399360
 +++ size 0: Add 2176 @KB/sec 1314.80 	  Verify 2176 Bytes  @KB/sec 2696.41
:: /1_dir/E_file.txt     arm_dcache_flush_delete: ptr=0x20200000, size=399360
    arm_dcache_flush_delete: ptr=0x20200000, size=399360
 +++ size 0: Add 2688 @KB/sec 1338.65 	  Verify 2688 Bytes  @KB/sec 2734.49
:: /2_dir/A_file.txt     arm_dcache_flush_delete: ptr=0x20200000, size=399360
    arm_dcache_flush_delete: ptr=0x20200000, size=399360
 +++ size 0: Add 5760 @KB/sec 1555.92 	  Verify 5760 Bytes  @KB/sec 2830.47
:: /2_dir/B_file.txt     arm_dcache_flush_delete: ptr=0x20200000, size=399360
    arm_dcache_flush_delete: ptr=0x20200000, size=399360


Indeed on a volatile/discardable disk - like RAM1 where addresses were excluded - there is no point in the sync.
 
defragster said:
-->> Looked down and saw DUAL LEDS
Click to expand...

mjs513 said:
Only one time did I get the RED and orange light at the same time but that was my fault - I pressed the PGM button at almost the same time as a sketch was uploading...
Click to expand...

Oh, now that is a valuable piece of info! It very likely may be a bootloader bug in 1.07. The bootloader is supposed to ignore the Program button during certain critical times, but probably isn't in this case with a locked chip.


Edit: just so you know, this is absolutely not your fault. The both LEDs blink pattern is an error that's never supposed to happen.
 
Last edited:
Status
Not open for further replies.
Back
Top