Teensyduino 1.55 Beta #2

Status
Not open for further replies.
Really glad you did. It's now on my list to fix for 1.55-beta3.

I will send you another 4.0 lockable beta board, and a lockable 4.1 early next week. :)

Nice! Glad I ran headlong into that to get it taken care of.

Some on this ( from Beta 1 thread):
Cool that you look and ran it! ... Code4Code.ino

I can give it a look. As posted indeed it runs forever - doing the same thing - and currently it starts the _isr() at high rate slowing the loop() test tremendously.

Primary goal was {shotgun spec} to stuff a lot of code and reference data in FLASH and see that it:
A: Worked at all - some repeat task that worked out a known result of 60 Pi digits.
B: Could deal with odd ptr[] boundary reads, sizes, directions in the added _isr()
C: Dealt with Code Cache being a bit to small - for some 100 KB's
D: Dealt with data Cache being a bit small for 4,000 copies of const szPi[64] == 256KB
E: Then monitoring cycles used I found some measure of the run rate
F: Run Forever meant it could show changing Temp
G: Run the 4,000 cascading func####()'s - or call the terminal Func0() 4,000 times

I finished the spec'd task list and all seemed well and first indication was ~5% overhead ...

Given the caveats [A-G] - there are not many moving parts in that test code to measure, and they overlap.
The spewed data was only to prove the code functioned blowing out the 32KB cache - which meant easy to produce (repetitive) code that was FAT in the end, and computation heavy making Pi digits. Taking that out leaves some 'net' time in the cascading call chain where the 'code' {encrypted or not} needs to be loaded to run in cache.
That and some teeth/hair pulling suggests that extreme case without the _isr() active is 9.6% faster:
Code:
>> No _isr		Casc Net	Direct Net	Mult Factor	[B]Rel Diff[/B]
10379960 nor ns: @600	29019		1969		14.73793804	[B]1.096993871[/B]
10379970 ENC SM: @600	31866		1971		16.1674277	0.910836813
6052840 nor ns: @600	29010		1970		14.72588832	[B]1.097891505[/B]

Adding the BIG _isr overhead the difference largely goes away {so not cleaning the tab formatting} - at least with the treatment applied.
Which gives wonder how 9% faster and 6% faster is getting lost in the mix going toward zero and not at least adding together?
But the _isr() char[] compares really is a seperate test - see below:
Code:
>> With _isr	Casc Net	Direct Net	Mult Factor	Rel Diff
10379960 nor ns: @600	35276	3617	9.75283384	0.102534301
10379970 ENC SM: @600	38537	4044	9.529426311	0.104938111
6052840 nor ns: @600	34608	3529	9.80674412	0.101970643

But when looking at the time in the _isr alone it shows 5.8 to 6% improvement in that - running _isr() at 3 rates.
Did the math for two .hex versus the .eHex and they gave these numbers - so here is one set:
Code:
_isr Only CPU %		@50 us		@100 us		@200 us
10379960 nor ns: @600	0.377891	0.192134	0.092131
10379970 ENC SM: @600	0.400139	0.203387	0.097733
			[B]1.05887412	1.058568499	1.060804724[/B]

If I'm done tweaking I could CODE that Excel work with fixed 'ref numbers' and spit out the 'Expected %' as a benchmark?

Here is the RAW data for the above:
Code:
	Not enabled _isr() char[] Testing.
Cascading 4000 calls took 5131274 us [3061353591 piCycles] : net 29019 us
Direct calls took 5111882 us [3065947966 piCycles] : net 1969 us

	ENABLED _isr() char[] Test @50 us	_isr Cycles 226734696 of 600000060 : CPU =0.377891
	ENABLED _isr() char[] Test @100 us	_isr Cycles 115280639 of 600000058 : CPU =0.192134
	ENABLED _isr() char[] Test @200 us	_isr Cycles 55278436 of 600000059 : CPU =0.092131
Cascading 4000 calls took 5692838 us [5657562 piCycles] : net {less Pi} 35276 us
	_isr Cycles 325468326 of 3415703076 : CPU =0.095286
Cascading 4000 calls took 5692838 us : net {less isr} 3394537780 us
Cascading 4000 calls took 5692838 us : Cycles/call 1423

Direct calls took 5673276 us [5669659 piCycles] : net {less Pi} 3617 us
	_isr Cycles 326463030 of 3403965837 : CPU =0.095907
Direct calls took 5673276 us [3401795860 piCycles] : net {less isr} 5129171 us
Direct calls took 5673276 us [3401795860 piCycles] : Cycles/call 1418
Code:
	Not enabled _isr() char[] Testing.
Cascading 4000 calls took 5135154 us [3061973078 piCycles] : net 31866 us
Direct calls took 5111885 us [3065948739 piCycles] : net 1971 us

	ENABLED _isr() char[] Test @50 us	_isr Cycles 240083719 of 600000060 : CPU =0.400139
	ENABLED _isr() char[] Test @100 us	_isr Cycles 122032171 of 600000057 : CPU =0.203387
	ENABLED _isr() char[] Test @200 us	_isr Cycles 58639895 of 600000057 : CPU =0.097733
Cascading 4000 calls took 5733775 us [5695238 piCycles] : net {less Pi} 38537 us
	_isr Cycles 346975911 of 3440265018 : CPU =0.100857
Cascading 4000 calls took 5733775 us : net {less isr} 3417142899 us
Cascading 4000 calls took 5733775 us : Cycles/call 1433

Direct calls took 5710594 us [5706550 piCycles] : net {less Pi} 4044 us
	_isr Cycles 347544584 of 3426355847 : CPU =0.101433
Direct calls took 5710594 us [3423930197 piCycles] : net {less isr} 5131354 us
Direct calls took 5710594 us [3423930197 piCycles] : Cycles/call 1427
Code:
	Not enabled _isr() char[] Testing.
Cascading 4000 calls took 5131267 us [3061344199 piCycles] : net 29027 us
Direct calls took 5111882 us [3065948170 piCycles] : net 1969 us

	ENABLED _isr() char[] Test @50 us	_isr Cycles 226738784 of 600000060 : CPU =0.377898
	ENABLED _isr() char[] Test @100 us	_isr Cycles 115292902 of 600000058 : CPU =0.192155
	ENABLED _isr() char[] Test @200 us	_isr Cycles 55287032 of 600000060 : CPU =0.092145
Cascading 4000 calls took 5692739 us [5658131 piCycles] : net {less Pi} 34608 us
	_isr Cycles 325396831 of 3415643876 : CPU =0.095267
Cascading 4000 calls took 5692739 us : net {less isr} 3394878992 us
Cascading 4000 calls took 5692739 us : Cycles/call 1423

Direct calls took 5673254 us [5669725 piCycles] : net {less Pi} 3529 us
	_isr Cycles 326391744 of 3403952525 : CPU =0.095886
Direct calls took 5673254 us [3401835257 piCycles] : net {less isr} 5129268 us
Direct calls took 5673254 us [3401835257 piCycles] : Cycles/call 1418

"Revised Spew" code updated at Defragster/T4LockBeta/tree/main/Code4Code

Added a 4 deep cascade as .txt and a similar copy of the 4000 deep cascade - I used the 4 deep version as "CodeMade.ino" to reduce the number of 3 minute builds as the output was tweaked.

GOOD NEWS: Lots of 'Verify' builds and TyComm SerMon GUI 'Bootloader' uploaded with Teensy Loader and No Issues - pushing to THREE T_4.0's - One Locked, one Beta unlockable, one production. Except for noted 12 sec versus 6 second programming time - the Unlocked/Not Secure Beta produced the same times as the Production T4.

One more Note: It takes just over 9ms to get 800 digits of Pi with the code I found. I settled on 60 digits that takes about 1ms. So as written it takes more time to run the code than to load it. The Pi code could be refined/replaced some and settling for 12 digits would cascade faster, now that I know it works - which was Job #1. That might give a clearer Perf picture with less finagling.
> Also I see I don't know how to printf a '%' :: printf("%%");
 
Last edited:
Good Morning Paul,

PRs... and Update libraries

a) Not sure if you want to update SDFat to his latest stuff... He allows some of the settings to be pre-set somehow and if set does not override... Mostly for Makefiles and the like... I have not checked out what other changes have been made...
Actually wish we would just change the default: #define MAINTAIN_FREE_CLUSTER_COUNT 1
In config file...

b) Other Random PRs... Probably none of them critical.

Cores: (Tmod p38 39 set rx ) https://github.com/PaulStoffregen/cores/pull/593
This has to do with two parts can split if wanted:
a) Wondering about pins (SDIO) 38 and 39 on TMOD I think they are reversed versus T4...
b) Fixes issue with SerialX.setRx to XBar pin

Cores: T4 DMAChannel - Implement triggerContinuously - https://github.com/PaulStoffregen/cores/pull/603
When trying to test the Cache delete stuff, wanted to do DMA transfer memory to memory... So tried something like:
Code:
  dma.sourceBuffer((uint8_t*)low_buffer, sizeof(low_buffer));
  dma.destinationBuffer((uint8_t*)dmam.dmaBuffer, sizeof(dmam.dmaBuffer));
  dma.transferCount(sizeof(dmam.dmaBuffer));
  dma.disableOnCompletion();
  dma.enable();
  dma.clearComplete();
  dma.triggerContinuously();
And found triggerContinuously was not implemented with a TODO comment... So I put a version in...

Note: this was in testing the arm_dcache_delete issues... Not sure if anything should be done for this release.

ST7735_t3 - Fix some pin names and constructors - https://github.com/PaulStoffregen/ST7735_t3/pull/28
A couple of the examples, some of the alternate constructors had the wrong Pin Names, also in those cases some of the constructors
had in them ST7789_t3 instead of ST7735_t3...


Again none of these may be critical.
But thought would mention..
 
Actually wish we would just change the default: #define MAINTAIN_FREE_CLUSTER_COUNT 1

Ok, I changed it to this for upcoming 1.55-beta3

Code:
/**
 * Set MAINTAIN_FREE_CLUSTER_COUNT nonzero to keep the count of free clusters
 * updated.  This will increase the speed of the freeClusterCount() call
 * after the first call.  Extra flash will be required.
 */
#if defined(__AVR__)
#define MAINTAIN_FREE_CLUSTER_COUNT 0
#else
#define MAINTAIN_FREE_CLUSTER_COUNT 1
#endif
 
@Paul

Finally after I don't know how many uploads I finally ran into the issue with the dual LEDs blinking on an upload with the Arduino IDE using the locked T4. As @defragster and @KurtE mentioned after maybe 10seconds it did reset/upload (sorry forgot been distracted today) without any intervention on my part and the sketch ran normally.
 
@Paul

Finally after I don't know how many uploads I finally ran into the issue with the dual LEDs blinking on an upload with the Arduino IDE using the locked T4. As @defragster and @KurtE mentioned after maybe 10seconds it did reset/upload (sorry forgot been distracted today) without any intervention on my part and the sketch ran normally.

On revisit to Beta 1 thread - with Beta 2 installed - it was noted running a trivial KurtE sketch I triggered the DUAL LEDS on button push. Tried then repeating steps it seemed led to it and it didn't show.

I did see the 'TyComm Reset' over USB trigger Teensy Loader to do the reported false Upload start and fail - which seems only to happen first time after an Upload. Again 'feeling' is Teensy Loader or something is holding 'state' from prior upload when triggered by 'USB Reset' it acts based on 'state' of prior operation? Not sure if that might be causing the DUAL LEDS where a valid Button upload isn't starting from 'clean slate/state'?


@Paul: Still wondering if teensy_reset.exe has utility and directions for use so something other than TyComm could be used for a USB Prompted Reset to take it out of the equation.
 
@Paul - @defragster - @KurtE

Just noticed something off (maybe this is intentional) but when using the Locked T4 I noticed that the TL window shows the hex name of the sketch at the bottom of the window but the verbose info is showing the ehex is being used. Is this the correct behavior?
Capture.PNG
or don't I just not understand what its suppose to show?

EDIT: I did just notice this at the begin of the verbose info:
Code:
17:53:03.086 (post_compile 1): Begin, version=1.55-beta2, high-res time
17:53:03.271 (loader): Teensy Loader 1.55-beta2, begin program
17:53:03.377 (loader): File "C:\Users\Merli\AppData\Local\Temp\arduino_build_980006\mtp-test.ino.hex", 174080 bytes
17:53:03.402 (loader): File "C:\Users\Merli\AppData\Local\Temp\arduino_build_980006\mtp-test.ino.ehex", 174080 bytes, 4960 extra
17:53:03.403 (loader): ehex is valid, key hash: 3CD8795F 9A168642 4FCF82ED AFC620F1 BCFECAB3 B978FA67 0D47FE2D F09253DD
17:53:03.412 (loader): Listening for remote control on port 3149
17:53:03.412 (loader): initialized, showing main window
17:53:03.510 (loader): remote connection 1364 opened
17:53:03.510 (loader): remote cmd from 1364: "comment: Teensyduino 1.55-beta2 - WINDOWS (teensy_post_compile)"
17:53:03.510 (loader): remote cmd from 1364: "status"
17:53:03.510 (loader): HID/win32:  vid:045E pid:07F8 ver:0300  usb:0/140000/0/5/6
17:53:03.510 (loader): HID/win32:  vid:045E pid:07F8 ver:0300  usb:0/140000/0/5/6
17:53:03.510 (loader): HID/win32:  vid:062A pid:4101 ver:0110  usb:0/140000/0/A/3/4
17:53:03.510 (loader): HID/win32:  vid:062A pid:4101 ver:0110  usb:0/140000/0/A/3/4
17:53:03.510 (loader): HID/win32:  vid:062A pid:4101 ver:0110  usb:0/140000/0/A/3/4
[B]17:53:03.510 (loader): remote cmd from 1364: "dir:C:\Users\Merli\AppData\Local\Temp\arduino_build_980006\"
17:53:03.510 (loader): remote cmd from 1364: "file:mtp-test.ino.hex"[/B]
17:53:03.513 (post_compile 1): Sending command: comment: Teensyduino 1.55-beta2 - WINDOWS (teensy_post_compile)

PS> When beta3 is released can you close the beta1 and beta2 threads - so can start fresh without having to jump back and forth :)
 
@Paul - @defragster - @KurtE

Just noticed something off (maybe this is intentional) but when using the Locked T4 I noticed that the TL window shows the hex name of the sketch at the bottom of the window but the verbose info is showing the ehex is being used. Is this the correct behavior?
...

Paul made some note about .hex being the pointer to the right spot for loader source, and when .eHex is present and required or usable, then it gets used.

Not sure how the IDE UI can alter the build otherwise? It doesn't know if the .hex or .ehex is destined for a locked or unlocked target that Teensy Loader will Program.

It seems the new build for the 1062's ( not T_MM ? ) might always build an .eHex just so it is there? Maybe it keys off having a key.pem file present? Obviously without that it can't build an .eHex?

As noted in Code4Code with 3MB CodeMade.ino w/4K func####()'s takes about 1.5 minutes ... After the build is otherwise done ... on what should be a faster than average Windows computer..
> that note suggested user console output for 'ehex being built ...' Then perhaps "... Done building .ehex"

@mjs513 - how long is the delay after teensy_size is printed on he 1MB Large sketch you made?
 
Paul made some note about .hex being the pointer to the right spot for loader source, and when .eHex is present and required or usable, then it gets used.

........

As noted in Code4Code with 3MB CodeMade.ino w/4K func####()'s takes about 1.5 minutes ... After the build is otherwise done ... on what should be a faster than average Windows computer..
> that note suggested user console output for 'ehex being built ...' Then perhaps "... Done building .ehex"

@mjs513 - how long is the delay after teensy_size is printed on he 1MB Large sketch you made?

I had thought that the windows pop up was showing the file that was loaded - oh well.

As to your question about the 1MB file - not sure which one that was but the ones I used to test with the upload time after teensy size displayed was always less than 10 seconds:
Code:
Memory Usage on Teensy 4.0:
  FLASH: code:37084, data:165364, headers:8492   free for files:1820676
   RAM1: variables:45760, code:35384, padding:30152   free for local variables:412992
   RAM2: variables:12384  free for malloc/new:511904


Memory Usage on Teensy 4.0:
  FLASH: code:140156, data:18544, headers:8208   free for files:1864708
   RAM1: variables:66368, code:132712, padding:31128   free for local variables:294080
   RAM2: variables:16512  free for malloc/new:507776


Memory Usage on Teensy 4.0:
  FLASH: code:83056, data:21268, headers:8312   free for files:1918980
   RAM1: variables:168768, code:62072, padding:3464   free for local variables:289984
   RAM2: variables:16512  free for malloc/new:507776

Memory Usage on Teensy 4.0:
  FLASH: code:87084, data:167588, headers:8492   free for files:1768452
   RAM1: variables:49984, code:82232, padding:16072   free for local variables:376000
   RAM2: variables:16512  free for malloc/new:507776

I did just try an older version of code4code sketch on the T4 locked and an estimated upload time was less than 30seconds
Code:
Memory Usage on Teensy 4.0:
  FLASH: code:1000092, data:323560, headers:8568   free for files:699396
   RAM1: variables:86752, code:36568, padding:28968   free for local variables:372000
   RAM2: variables:12384  free for malloc/new:511904
 
I had thought that the windows pop up was showing the file that was loaded - oh well.

As to your question about the 1MB file - not sure which one that was but the ones I used to test with the upload time after teensy size displayed was always less than 10 seconds:
...

I did just try an older version of code4code sketch on the T4 locked and an estimated upload time was less than 30seconds
Code:
Memory Usage on Teensy 4.0:
  FLASH: code:1000092, data:323560, headers:8568   free for files:699396
   RAM1: variables:86752, code:36568, padding:28968   free for local variables:372000
   RAM2: variables:12384  free for malloc/new:511904

The BIG one was the one you used with LittleFS PROG media to cross the 1MB boundary.

Thanks for the timing note. I wonder if the Windows 11 Drag and Drop slowness - some 10 second delay is causing me grief during builds? Even a rename takes similar time.
 
Wondering about this new computer with 1TB NVMe SSD being so slow for copy/paste and the build of Code4Code:
> Looks like I can't take off the Beta Windows 11 any longer ... would need a clean install of Win 10 :(
> I did remove my drive Map for C:\T_drive as "T:\" : No change in build time

Which is a problem: it built no .eHex and TLoader screamed that .eHex was required?
> This left the T_4.0 OFFLINE, so next Upload required a button press. Not a biggie, just sayin' ...

Why: IDE lost track of Sketchbook folder 'silently' - of course I noticed a previously open sketch didn't re-open, and sketchbook 'path' didn't occur top of mind.
> So it could not make a working .eHex, but it still went through the motions ???

Updated IDE to actual location and again LONG BUILD and then there was a .eHex.
>> After IDE restart: required because it updated sketchbook, but build failed.

BUT: Above it took that extra 1.5 minutes to do something with no pem.key? See below.

Next: In sketchbook renamed to xpem.key :
>> SAME extended LONG BUILD TIME - but why there is no pem.key?
>> Also it did not remove the prior .eHex in the build folder, so it uploaded the .eHex that doesn't match the .hex file.
Code:
Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----         9/12/2021  [B][COLOR="#FF0000"]12:46 AM[/COLOR][/B]        3227855 Code4Code.ino.ehex
-a----         9/12/2021  [B]12:50 AM[/B]        3758843 Code4Code.ino.hex

I postulated earlier that the .eHex build only proceeds when pem.key exists - this isn't the case.

This was a rare case - unmapping (remapping) a drive, but seems it shows some issues?
 
Wondering about this new computer with 1TB NVMe SSD being so slow for copy/paste and the build of Code4Code:

Just a quick guess, maybe the slowness isn't building at all, but the post-build commands which create extra output files.

Try editing platform.txt. Look for this part:

Code:
## Post Build - inform Teensy Loader of new file
recipe.hooks.postbuild.1.pattern="{compiler.path}stdout_redirect" "{build.path}/{build.project_name}.lst" "{compiler.path}{build.toolchain}{build.command.objdump}" -d -S -C "{build.path}/{build.project_name}.elf"
recipe.hooks.postbuild.2.pattern="{compiler.path}stdout_redirect" "{build.path}/{build.project_name}.sym" "{compiler.path}{build.toolchain}{build.command.objdump}" -t -C "{build.path}/{build.project_name}.elf"
recipe.hooks.postbuild.3.pattern="{compiler.path}teensy_post_compile" "-file={build.project_name}" "-path={build.path}" "-tools={compiler.path}" "-board={build.board}"
recipe.hooks.postbuild.4.pattern="{compiler.path}teensy_size" "{build.path}/{build.project_name}.elf"

Try deleting either the first or second line (or both) and edit the other lines so the pattern numbers start at 1.
 
The BIG one was the one you used with LittleFS PROG media to cross the 1MB boundary.

Thanks for the timing note. I wonder if the Windows 11 Drag and Drop slowness - some 10 second delay is causing me grief during builds? Even a rename takes similar time.

Ok thanks for the reminder. I did just run it and seemed to take less than 5 seconds or so from when TeensySize was printed.

Curious about the slowness as well. Never did a timing comparison from before 1.55 to 1.55 but just had a feeling it was a longer. Just as a note seems to sit for a bit less than 40 seconds on these last 4 lines - about 20secs for the first and about 20 for the rest.
Code:
F:\arduino-1.8.16\arduino-builder -dump-prefs -logger=machine -hardware F:\arduino-1.8.16\hardware -hardware C:\Users\Merli\AppData\Local\Arduino15\packages -tools F:\arduino-1.8.16\tools-builder -tools F:\arduino-1.8.16\hardware\tools\avr -tools C:\Users\Merli\AppData\Local\Arduino15\packages -built-in-libraries F:\arduino-1.8.16\libraries -libraries D:\Users\Merli\Documents\Arduino\libraries -fqbn=teensy:avr:teensy40:usb=mtp,speed=600,opt=o2std,keys=en-us -ide-version=10816 -build-path C:\Users\Merli\AppData\Local\Temp\arduino_build_737197 -warnings=none -build-cache C:\Users\Merli\AppData\Local\Temp\arduino_cache_781486 -verbose D:\Users\Merli\Documents\Arduino\T4 Security Beta\littlefs_teensy_test1a-UPDATED\littlefs_teensy_test1a-UPDATED.ino
F:\arduino-1.8.16\arduino-builder -compile -logger=machine -hardware F:\arduino-1.8.16\hardware -hardware C:\Users\Merli\AppData\Local\Arduino15\packages -tools F:\arduino-1.8.16\tools-builder -tools F:\arduino-1.8.16\hardware\tools\avr -tools C:\Users\Merli\AppData\Local\Arduino15\packages -built-in-libraries F:\arduino-1.8.16\libraries -libraries D:\Users\Merli\Documents\Arduino\libraries -fqbn=teensy:avr:teensy40:usb=mtp,speed=600,opt=o2std,keys=en-us -ide-version=10816 -build-path C:\Users\Merli\AppData\Local\Temp\arduino_build_737197 -warnings=none -build-cache C:\Users\Merli\AppData\Local\Temp\arduino_cache_781486 -verbose D:\Users\Merli\Documents\Arduino\T4 Security Beta\littlefs_teensy_test1a-UPDATED\littlefs_teensy_test1a-UPDATED.ino
Using board 'teensy40' from platform in folder: F:\arduino-1.8.16\hardware\teensy\avr
Using core 'teensy4' from platform in folder: F:\arduino-1.8.16\hardware\teensy\avr

Using windows stopwatch app the total time to get to TeensySize output was about 48 seconds.
Code:
Memory Usage on Teensy 4.0:
  FLASH: code:76424, data:6932, headers:8800   free for files:1939460
   RAM1: variables:17088, code:71576, padding:26728   free for local variables:408896
   RAM2: variables:5216  free for malloc/new:519072
 
I've again fallen behind, haven't read every message on this thread. Hope to soon, but right now focusing fixing bugs.

Been working on Teensy Loader. Hopefully all the GUI stalls with locked/secure chips are will be fixed for beta3. I've also put in code to clearly state verbose info about when .hex was opened but .ehex will actually be used, and show the correct .hex vs .ehex filename in the status bar.

Going to take a break, and then later today I'm going to work on the fuse write sketch, to avoid corrupting already written key if a different key is attempted, and to print (hopefully) clearer messages in the cases where encryption isn't supported.

I have a few other very minor issues on my list, but unless anyone reminds me of something major, will probably package up 1.55-beta3 once fusewrite is fixed.
 
Paul, Not sure if this has been mentioned and/or has been covered somewhere... Sometimes I also lose the trees in the forest :D

Should a locked T4 act differently then a normal older T4 when you press the program button and the Teensy app is not running yet... I was testing a few of the different USB modes yesterday to see if the issue of Serial Terminal not coming back after crash would reproduce on a USB mode that ships with Teensyduino... So I have a couple of different T4s to try to see if it makes any differences of locked versus unlocked...

What I noticed is that the two boards act differently when I press the program button and I don't have the Teensy app running...

That is: I have two running now with Triple Serial (last one I tried):

So I startup the Arduino App, and have the two Teensy boards running as you can see:
screenshot.jpg
I now press the program button on both boards.

When I do it with the older non-locked T4 it resets, the program led stays lit and waits to be programmed. It also shows up in the Arduino Ports list with the type...

If I do that with the Locked T4, I hear a beep, but program LED does not come/stay on... Also the Teensy no longer shows up int he ports list of Arduino.
In this bogus case I pressed it on both Teensy boards in previous picture:
screenshot2.jpg

Again sorry if covered before... But thought I would mention it before I get the next cup of coffee to fully wake up.
 
If I do that with the Locked T4, I hear a beep, but program LED does not come/stay on... Also the Teensy no longer shows up int he ports list of Arduino.

Yes, this is the correct behavior for a board locked into secure mode.

When you press the button on a locked Teensy, it runs NXP's ROM only. Teensy Loader and the "loader utility" part of a EHEX file are needed to get it into bootloader mode.

If Teensy Loader isn't running, or if Teensy Loader hasn't opened a EHEX file (opening a HEX file automatically also opens the corresponding EHEX file), or if the EHEX file it has opened was created with the wrong encryption key, then the hardware just sits there unable to do anything. It can't even turn on the red LED.

I tried to make the user experience as similar as I could. This part is unavoidably different due to the way the chip's HAB security features work.
 
Yes, this is the correct behavior for a board locked into secure mode.

When you press the button on a locked Teensy, it runs NXP's ROM only. Teensy Loader and the "loader utility" part of a EHEX file are needed to get it into bootloader mode.

If Teensy Loader isn't running, or if Teensy Loader hasn't opened a EHEX file (opening a HEX file automatically also opens the corresponding EHEX file), or if the EHEX file it has opened was created with the wrong encryption key, then the hardware just sits there unable to do anything. It can't even turn on the red LED.

I tried to make the user experience as similar as I could. This part is unavoidably different due to the way the chip's HAB security features work.

Thanks Paul,

Wondering if some of this behavioral differences this should be mentioned on the page: https://www.pjrc.com/teensy/td_code_security.html
Maybe it is, but I don't think I saw the word LED on the page...
 
Just a quick guess, maybe the slowness isn't building at all, but the post-build commands which create extra output files.

Try editing platform.txt. Look for this part:

Code:
## Post Build - inform Teensy Loader of new file
recipe.hooks.postbuild.1.pattern="{compiler.path}stdout_redirect" "{build.path}/{build.project_name}.lst" "{compiler.path}{build.toolchain}{build.command.objdump}" -d -S -C "{build.path}/{build.project_name}.elf"
recipe.hooks.postbuild.2.pattern="{compiler.path}stdout_redirect" "{build.path}/{build.project_name}.sym" "{compiler.path}{build.toolchain}{build.command.objdump}" -t -C "{build.path}/{build.project_name}.elf"
recipe.hooks.postbuild.3.pattern="{compiler.path}teensy_post_compile" "-file={build.project_name}" "-path={build.path}" "-tools={compiler.path}" "-board={build.board}"
recipe.hooks.postbuild.4.pattern="{compiler.path}teensy_size" "{build.path}/{build.project_name}.elf"

Try deleting either the first or second line (or both) and edit the other lines so the pattern numbers start at 1.

@Paul: That was the extra 1.5 minutes, building .lst and .sym files?
>> Commented out the prior .1. and .2. and renumbered 3&4.

Mike is the Code4Code building the 4K Func()'s version like this - that still takes 1 min +secs here:
Code:
"C:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy/../tools/teensy_size" "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_743307/Code4Code.ino.elf"
Memory Usage on Teensy 4.0:
  [B]FLASH: code:998032[/B], data:329616, headers:8668   free for files:695300
   RAM1: variables:90976, code:41144, padding:24392   free for local variables:367776
   RAM2: variables:24736  free for malloc/new:499552

Funny thing - I was poking at the seePi() code. Did some non-helpful changes but it altered the _isr()::testAlpha() CPU % results by like 20% - but it doesn't have ANY known/expected relationship to the seePi() code? Introducing a second holding array to fill once then doing a memcpy() was only a few us faster per call.
Code:
My calc of the cycles used in the _isr() that does the string looping byte compares went from .40% to .489%
That is NOT Beta Locked specific - same results on Production board: This "CPU %=0.377914" goes to this "CPU %=0.469728"
 
Mike is the Code4Code building the 4K Func()'s version like this - that still takes 1 min +secs here:

Short answer yep about 1.5mins
Code:
Memory Usage on Teensy 4.0:
  FLASH: code:1002292, data:326520, headers:8528   free for files:694276
   RAM1: variables:90976, code:39320, padding:26216   free for local variables:367776
   RAM2: variables:24736  free for malloc/new:499552
 
Short answer yep about 1.5mins
Code:
Memory Usage on Teensy 4.0:
  FLASH: code:1002292, data:326520, headers:8528   free for files:694276
   RAM1: variables:90976, code:39320, padding:26216   free for local variables:367776
   RAM2: variables:24736  free for malloc/new:499552

Thanks! I can rest now - maybe. Win 11 has GUI Explorer issues with 5-10 delays on renames and Drag&Drop ???
Put RamDrive on system after dumping the T:Drive ... may put it back since it wasn't the issue it seems.

... but back to using the system ...
 
Seems objdump is extremely slow for creating the .lst file when the input file is huge. I'm going to disable it for 1.55-beta3.

Sadly, the rest of the slowness seems to be unavoidable due to compiling so much code. Different Tools > Optimize settings can make some difference, but none are speedy for this much code.
 
Been exercising the locked T4 with LittleFS and SD (non MTP tests) without any issues (didn't expect any) just testing if any upload issues. Had a stalled upload once today, non-double LED, just seemed to sit on upload with TL window open and just the orange LED light on. Only way to clear it was to power cycle the T4. This is the first time I saw this one since started testing with beta1 but it did happen after I was uploaded and ran Tim's code4code.
 
Status
Not open for further replies.
Back
Top