Teensyduino 1.55 Beta #1

Status
Not open for further replies.
And now for something completely different :D

If my sketch crashes and I have
Code:
  Serial.print(CrashReport);
The crash report (as well as other stuff early on in next run) shows up in the Serial Monitor window when I use the (not in the build)
USB type of MTP Disk Serial (Experimental)

But none of this output shows up with the MTP Disk(Experimental)
I do finally get some output after the sketch has completed setup:

Turned out I was going through NULL pointer...

Setup for this is the starting of new round of: some MTP/MSC stuff that @mjs513 and I have started including adding file dates and times...
Easy setup :D - Note will be starting new thread on this as a follow up to my earlier TLA thread.

Current setup: Arduino 1.8,15 and this beta:
Update cores: with https://github.com/KurtE/cores/tree/FS_DATES (Added dates/times will have branch FS_Integration)
update MTP: https://github.com/KurtE/MTP_t4/tree/FS_Integration
update MSC: https://github.com/KurtE/UsbMscFat/tree/FS_Integration
Update LittleFS: https://github.com/Mjs513/LittleFS/tree/FS_Integration

Update: SD: (This is what I forgot) with https://github.com/KurtE/SD/tree/FS_Integration

run the sketch: https://github.com/KurtE/MTP_t4/blob/FS_Integration/examples/SD_MTP-logger/SD_MTP-logger.ino
And then on PC try to expand the Teensy/SD directory... And it called through null ptr to un updated SD Modify date and crashed...

Easy ;)

Now back to playing

Glad to see this. Will update:)
 
Glad to see this. Will update:)
Will be posting new thread soon!

Trying to first take care of the strange crash I mentioned in other thread...
Kept running into this through the earlier code, but never fully tracked it down...
 
Update to p#323 and p#325
added arm_dcache_flush_delete( a1, sizeof( a1 ) ); for the four strings a1,a2,z1,z2 on exit from _isr()
> that will force it to fully fill cache 'as needed' for each char compare on every entry
-> Could alternate (after each cycle) char* and uint32* to force 4 byte chunk compare - the repetitive nature of the source string should pass.

It is still working!

It takes about 1000% longer per pass with the loss of continuous cache encypted or not here are the TallDog's:
Code:
[B]7.1875, 48.33
10379970 ENC SM: Completed CASCADE Count 4000	Cascading took 10301797 us [1844042038 piCycles] : net 7228394
Direct calls took 10243064 us [1845954231 piCycles] : net 7166474
[/B]
Code:
[B]7.8926, 43.58
6683800 nor ns: Completed CASCADE Count 4000	Cascading took 9883625 us [1596720292 piCycles] : net 7222425
Direct calls took 9843493 us [1606557656 piCycles] : net 7165897[/B]

Also added test of those 4 strings to be in encrypted space - and they are PASS on the two ENCrypted units 970 and 960, other of course FAIL.
Here is 960 Locked SM/ENCrypted start:
Code:
Pass: Bus Encryption Engine is active
Pass: Encryption region starts at proper address
Pass: Program data is entirely within encrypted region
Pass: title_function() is within encrypted region
Pass: title_text[] is within encrypted region
[B]Pass: a1[] is within encrypted region
Pass: a2[] is within encrypted region
Pass: z1[] is within encrypted region
Pass: z2[] is within encrypted region
[/B]Pass: csf is PJRC
NOTE: hab_version == 0x40307
NOTE: hab_status == 0xF0
Secure mode IS set :: Fuses == 0x4C8B01A

All Tests Passed.  :-)
 
Time to restart the IDE:
IDErestart.png

PENDING POST - I GOT WEDGED


Since TSET just calls the IDE Builder I suppose it works ... I should try it ...

>> GOOD WORK @Paul

TSET under SUBLIME TEXT build WORKS... one caveat not integrated it prompts and holds Serial Open
>> just escape/close the select Dialog, and Push the Teensy Button or TyComm/Bootloader

Seems this is the 'normal problem'? I could have TSET "ASK" if 'TyComm integrated' and just skip that step when NOT and it builds
>> REM lines 89 and 90 where it calls TyCommander in Compile.CMD

I did see new warnings - Under IDE the 3 INO's collected allowing the new data strings a1,a2,z1,z2 to be seen. From command line I had to share an extern. And a sizeof() for dcache_flush_delete( sz, sizeof( sz ) )) now wanted to know how big each was with a number I didn't include?

Tried to add DWORD 'pointer cast' of the char code - BIG FAIL : would need custom crafted strings sized to work
 
Last edited:
@Paul - something Broke for finding eHex

Not fixed or working yet.

After all the following -that did not work- I got it working.
> Upload Build VerifySecure.ino with ANOTHER Teensy connected in IDE - just a Production T4
> Power up the LOCKED Beta holding the button and it finally had the needed paths set

Back in IDE this is the Sketch being built to upload to LOCKED T4_Beta - this is th eIDE Console build path:
Code:
"C:\Users\Tim\AppData\Local\Temp\arduino_build_326025\VerifySecure.ino.ehex"

But IDE is LOCKED - and the "Open HEX File" is Grayed so I cannot even point to that USABLE file.

Pressing Button does not turn on RED LED, but Teensy Loader does try Upload and fails pointing to a bad file. I just deleted the indicated t:\temp\arduino_build_MakeCode.ino\ directory and it still persists?

#1> It should be getting proper PATH from the IDE on Build? Not holding a 'broken path' from before with no .eHex.
#2> If File Open was not grayed out - I could show it a valid .eHex file

Code:
> I put the IDE build folder in the expected path with the expected name and it still failed?
> I went into RegEdit {HKEY_USERS\S-1-5-21-3950958835-4219114207-2426240891-1001\Software\PJRC} and took away the dir and file and Did a new Verify
 --> Now it doesn't even show a path in Verbose and still cannot 'Open HEX File'
> There is no teensy_loader_cli.exe here - but trying the following with the files in the folder below still fails:
[QUOTE]
T:\Arduino_1.8.15td155\hardware\tools>teensy --mcu=TEENSY40  -w VerifySecure.ino.ehex
T:\Arduino_1.8.15td155\hardware\tools>teensy --mcu=TEENSY40  -w VerifySecure.ino.hex
[/QUOTE]

[QUOTE]
 Directory of T:\Arduino_1.8.15td155\hardware\tools

  ...
08/17/2021  11:09 AM         4,482,856 teensy.exe
  ...
[B]08/28/2021  02:43 PM            61,275 VerifySecure.ino.ehex
08/28/2021  02:53 PM           456,868 VerifySecure.ino.elf
08/28/2021  02:53 PM            57,677 VerifySecure.ino.hex[/B][/QUOTE]

Doing a 'Verify' Build - because the Beta Teensy is OFFLINE after this failure started.

This is what IDE shows: { I got stuck like this once before ??? }
Code:
Archiving built core (caching) in: C:\Users\Tim\AppData\Local\Temp\arduino_cache_195234\core\core_cde230c268154177edb21ee291c1c116.a
Linking everything together...
"T:\\Arduino_1.8.15td155\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -O2 -Wl,--gc-sections,--relax "-TT:\\Arduino_1.8.15td155\\hardware\\teensy\\avr\\cores\\teensy4/imxrt1062.ld" -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -o "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_326025/VerifySecure.ino.elf" "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_326025\\sketch\\VerifySecure.ino.cpp.o" "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_326025/core\\core.a" "-LC:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_326025" -larm_cortexM7lfsp_math -lm -lstdc++
"T:\\Arduino_1.8.15td155\\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 "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_326025/VerifySecure.ino.elf" "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_326025/VerifySecure.ino.eep"
"T:\\Arduino_1.8.15td155\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objcopy" -O ihex -R .eeprom "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_326025/VerifySecure.ino.elf" "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_326025/VerifySecure.ino.hex"
"T:\\Arduino_1.8.15td155\\hardware\\teensy/../tools/teensy_secure" encrypthex TEENSY40 "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_326025/VerifySecure.ino.hex"
encrypting 12288 bytes to C:\Users\Tim\AppData\Local\Temp\arduino_build_326025/VerifySecure.ino.ehex
"T:\\Arduino_1.8.15td155\\hardware\\teensy/../tools/stdout_redirect" "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_326025/VerifySecure.ino.lst" "T:\\Arduino_1.8.15td155\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objdump" -d -S -C "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_326025/VerifySecure.ino.elf"
"T:\\Arduino_1.8.15td155\\hardware\\teensy/../tools/stdout_redirect" "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_326025/VerifySecure.ino.sym" "T:\\Arduino_1.8.15td155\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objdump" -t -C "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_326025/VerifySecure.ino.elf"
"T:\\Arduino_1.8.15td155\\hardware\\teensy/../tools/teensy_post_compile" -file=VerifySecure.ino "-path=C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_326025" "-tools=T:\\Arduino_1.8.15td155\\hardware\\teensy/../tools/" -board=TEENSY40
[B]Teensy Loader is currently busy with another operation (p).  Please try again in a few seconds, or restart Teensy Loader.
quitexit status 1
Error compiling for board Teensy 4.0.
[/B]

Clearing Verbose and building again this is the content from Teensy Loader.
It seems stuck on THIS file from a failed build under TSET: t:\temp\arduino_build_MakeCode.ino\, MakeCode.ino.hex
Code:
14:40:00.603 (loader): remote connection 1528 opened
14:40:00.603 (loader): remote cmd from 1528: "comment: Teensyduino 1.55-beta1 - WINDOWS (teensy_post_compile)"
14:40:00.603 (loader): remote cmd from 1528: "status"
14:40:00.608 (post_compile 7): Begin, version=1.55-beta1, high-res time
14:40:00.615 (post_compile 7): Sending command: comment: Teensyduino 1.55-beta1 - WINDOWS (teensy_post_compile)
14:40:00.616 (post_compile 7): Status: 1, 0, 1, 6, 0, 12, t:\temp\arduino_build_MakeCode.ino\, MakeCode.ino.hex
14:40:00.666 (loader): remote cmd from 1528: "status"
14:40:00.668 (post_compile 7): Status: 1, 0, 1, 6, 0, 12, t:\temp\arduino_build_MakeCode.ino\, MakeCode.ino.hex
14:40:00.724 (loader): remote cmd from 1528: "status"
14:40:00.726 (post_compile 7): Status: 1, 0, 1, 6, 0, 12, t:\temp\arduino_build_MakeCode.ino\, MakeCode.ino.hex
14:40:00.787 (loader): remote cmd from 1528: "status"
14:40:00.788 (post_compile 7): Status: 1, 0, 1, 6, 0, 12, t:\temp\arduino_build_MakeCode.ino\, MakeCode.ino.hex
14:40:00.850 (loader): remote cmd from 1528: "status"
14:40:00.851 (post_compile 7): Status: 1, 0, 1, 6, 0, 12, t:\temp\arduino_build_MakeCode.ino\, MakeCode.ino.hex
14:40:00.913 (loader): remote cmd from 1528: "status"
14:40:00.916 (post_compile 7): Status: 1, 0, 1, 6, 0, 12, t:\temp\arduino_build_MakeCode.ino\, MakeCode.ino.hex
14:40:00.974 (post_compile 7): Teensy Loader is currently busy with another operation (p).
14:40:00.975 (post_compile 7): quit
 
@mjs513 @KurtE - Not seeing the change needed on Builder line? Somehow it doesn't get the updated path to TeensyLoader?
It worked ONCE because the old path had valid code it was using. Then the path got changed and it wasn't 'right' apparently RE:p#330.

TSET Works to Verify and Build, creates .hex and .eHex, shows teensy_size.exe - but not to notify Teensy.exe of the new file location?

Will have to look after Beta two perhaps ...
 
@defragster - right now mostly using Arduino to build... Currently MTP+Serial currently For T4.1...
 
@mjs513 @KurtE - Not seeing the change needed on Builder line? Somehow it doesn't get the updated path to TeensyLoader?
It worked ONCE because the old path had valid code it was using. Then the path got changed and it wasn't 'right' apparently RE:p#330.

TSET Works to Verify and Build, creates .hex and .eHex, shows teensy_size.exe - but not to notify Teensy.exe of the new file location?

Will have to look after Beta two perhaps ...

I pretty much stick to Arduino IDE but haven't had any issues with loading sketches to the Locked Beta4. Only issue I had was loading code4code onto a single T4. Worked once then had problems. Just uploaded a different sketch and no problem.

Really have played much with it since the last temp tests. Primarily working with MTP+serial on T4.1 although have tried MTP with the Locked T4 without an issue using an ext SD Card and SPI chip.
 
@defragster - right now mostly using Arduino to build... Currently MTP+Serial currently For T4.1...

Yes, me too. But crashing the IDE with the 3MB code file made me wonder ... and seems there is a missing trick for TSET use.

Will do a better study of the CMD lines used - looked the same and resulted in valid Hex's. But then again It has never been perfect using TyComm perhaps and now a new trick is needed.
 
Last edited:
I pretty much stick to Arduino IDE but haven't had any issues with loading sketches to the Locked Beta4. Only issue I had was loading code4code onto a single T4. Worked once then had problems. Just uploaded a different sketch and no problem.

Really have played much with it since the last temp tests. Primarily working with MTP+serial on T4.1 although have tried MTP with the Locked T4 without an issue using an ext SD Card and SPI chip.

Indeed the IDE is the safe bet and has to be tested. It will need to be workable otherwise - and TSet ideally should - and it does build and Teensy.exe just doesn't know where it seems. Seems to fail getting Teensy_post_compile notice, maybe TyComm interferes? Will have to follow up on the CMDline for that and see about using it.

Problem I found was locking up the Locked T4 when Teensy.exe got path confusion ( not sure what was wrong the first time I got that ) - but this time took some doing until I found the simple solution, since Teensy 'OPEN' was disabled?

I tried the initial MTP and it worked. Since I have two TallDog boards I could move to that with builtin SD for testing. Perhaps the other Bet on the PJRC Memory Breakout with the NAND & NOR Flash pairs? That would support an Audio board for SD cardRev D (unless it used p#6 for CS?) too right?
 
Indeed the IDE is the safe bet and has to be tested. It will need to be workable otherwise - and TSet ideally should - and it does build and Teensy.exe just doesn't know where it seems. Seems to fail getting Teensy_post_compile notice, maybe TyComm interferes? Will have to follow up on the CMDline for that and see about using it.

Problem I found was locking up the Locked T4 when Teensy.exe got path confusion ( not sure what was wrong the first time I got that ) - but this time took some doing until I found the simple solution, since Teensy 'OPEN' was disabled?

I tried the initial MTP and it worked. Since I have two TallDog boards I could move to that with builtin SD for testing. Perhaps the other Bet on the PJRC Memory Breakout with the NAND & NOR Flash pairs? That would support an Audio board for SD cardRev D (unless it used p#6 for CS?) too right?

pin 6 is the memory pin cs for the on board flash. At some point will test on the locked T4 but need to workout issues first with know quantity and qspi etc.
 
pin 6 is the memory pin cs for the on board flash. At some point will test on the locked T4 but need to workout issues first with know quantity and qspi etc.

Thought it was shared with something - seems the Rev D Audio here seems to have conflicting memory chips on them ...

But that gives me the Native SDIO SD on the TallDog also two units with USBMsc with one a locked Beta
 
@Paul - loaded a few sketches to T_4.0 on the TallDog breakout with no problem with TD 1.55 Beta.

Using USB and SDIO socket it provides - One Production and the other Locked Beta unit.

Just put CR1220 cell's onto them and they hold time and work with TeensyTime3 and @Luni's Time_Clock code with us resolution.

Same Verify build works to upload to either unit without issue, except the puzzling TWIN LED flashed noted twice.
 
Reviewing possible issues, still have this from msg #96 on my list:


However for some reason looks like it is corrupting the directory and file data in LittleFS

When this was written - only 15 days ago but kinda seems like forever now - I had not yet written this documentation:

https://www.pjrc.com/teensy/td_code_security.html

The latest documentation now has a table for maximum LittleFS sizes to be properly retained across code updates. Scroll down to "Minimum Erase Size".

@mjs513 - Any chance I can talk you into retrying this test with the LittleFS filesystem size of 960K for secure mode or 1472K for normal mode?

If corruption happens with those sizes, and the program is less than 512K or 1M, the we do indeed have a bug I need to fix. But my hope is the issue was just lack of documentation at the time and attempting sizes larger than the now-documented maximum.
 
@mjs513 - Any chance I can talk you into retrying this test with the LittleFS filesystem size of 960K for secure mode or 1472K for normal mode?
Will do it right now give me a bit while I remember what I did - seems like forever. But I think once we figure out about the 960 block it wasn't an issue but will try again to confirm.

Locked T4 with 960blocks of 1024 bytes: Data is retained between restarts or code updates without an issue.
Code Size:
Code:
Memory Usage on Teensy 4.0:
  FLASH: code:78464, data:6900, headers:8840   free for files:1937412
   RAM1: variables:17088, code:73624, padding:24680   free for local variables:408896
   RAM2: variables:12384  free for malloc/new:511904

Normal T4 with 1472blocks of 1024, same thing Data is retained between restarts or code updates without an issue.

In neither case am I see any corruption.

Edit:
By accident I ran the 1472k on the locked t4 and flue system was corrupted as you would expect.
The only way to clear the corruption even if I changed to 960k was to do a quick format.
 
Last edited:
@Paul - Should the examples/Integrity/RAM/RAM.ino be updated to account for the 'change on boot' region of DMAMEM?

Something like:
Code:
// This declares the LittleFS Media type and gives a text name to Identify in use
LittleFS_RAM myfs;  // CAN use either RAM1 or RAM2 as available
#define LFS_BUF_SIZE 390*1024
//char LFS_BUF[ LFS_BUF_SIZE ];	// BUFFER in RAM1 :: Lost on any Restart/Upload
[B]void *LFS_BUF = (void*)(0x2027ff00-LFS_BUF_SIZE); // RAM2 Addr :: typically survives Restart/Upload, avoid lower 64KB 0x2020000, upper CrashReport area[/B]

Instead if this sure to break:
Code:
//DMAMEM char buf[ 390 * 1024 ];	// DMAMEM Uses RAM2 :: Typically survives Restart/Upload
 
Last edited:
Something like:

Let's not put raw addresses into the examples.

Really not sure how important this is, to demonstrate RAM-based filesystem retained across code updates. But if it is, please do so with a normal array and then don't use the first 32k, probably with a comment in the code that the first 32k of RAM2 can be overwritten during reboot.

So something like myfs.begin(buf + offset, sizeof(buf) - offset)
 
Let's not put raw addresses into the examples.

Really not sure how important this is, to demonstrate RAM-based filesystem retained across code updates. But if it is, please do so with a normal array and then don't use the first 32k, probably with a comment in the code that the first 32k of RAM2 can be overwritten during reboot.

So something like myfs.begin(buf + offset, sizeof(buf) - offset)

Indeed the RAW address is UGLY - but prevents WASTE of that 32KB - though it DOES assure that any leftover DMAMEM is blocked form dynamic allocations.

Was just compilng to test - will rework as noted ...
 
Works like this - not real pretty either - adding the #define BUF_OFFSET for the common .begin():
Code:
// This declares the LittleFS Media type and gives a text name to Identify in use
LittleFS_RAM myfs;  // CAN use either RAM1 or RAM2 as available
#define LFS_BUF_SIZE 390*1024 // Adjust this for the usable desired size, here in KiloBytes
[B]#define BUF_OFFSET 32768 // 0 // ZERO When using RAM.  Must be 32768 when using DMAMEM to survive warm restart
[/B]//char buf[ LFS_BUF_SIZE ];	// BUFFER in RAM1 :: Lost on any restart
[B]DMAMEM char buf[ LFS_BUF_SIZE ];	// DMAMEM Uses RAM2 :: Typically survives Restart/Upload
[/B]char szDiskMem[] = "RAM_DISK";

// ... 
void setup() {
// ...
	[B]if (!myfs.begin(&buf[BUF_OFFSET], sizeof(buf)-BUF_OFFSET))[/B] {
 
You could use malloc() and allocate enough memory that the address exceeds the 32kb. - and then free the unused memory. This is also not pretty, but cleaner, and nothing would be wasted.
And the heap would know about littleFS.

littleFS could do that itself, too, on create.
 
@KurtE mentioned that we have been making changes to simplify setting up MTP and adding in things like SD Card Detection as well as file dates and times. I have been testing with a T4.1 since we can then test with PSRAM as well as QSPI flash. On the T4.1 it has been working - did have to do a quick adjust (not much) after the FS update :).

So I decided to see if it would break the Locked T4 - I did not break it and it does work with some caveats for now. Next up testing on a normal T4.
  1. If I have a hub plugged in with a SSD drive and 2 partions, along with a USB Drive with 1 partition and another with 2 partitions MTP doesn't recognize the SSD or the USB drives on startup. Have to plug them into the hub after the MTP starts. Now sure why this is happening or its unique to the Locked T4 but I do know on a T4.1 with the hub plugged in and all drives in the hub MTP recognizes the drive on MTP start.
  2. SD card detect is still a work in progress as @KurtE already mentioned.


Here is a screen shot of explorer with all the drives/partitions:
Capture.PNG

See this post for the links to the files and libraries that are affected: https://forum.pjrc.com/threads/67989-Teensyduino-1-55-Beta-1?p=287150&viewfull=1#post287150

@KurtE's MTP fork has a number of updates that the the MTP_T4 does not have - like more events to support the changes. Did I get this right Kurt.

EDIT: Tracked the problem down and its an issue with my breakout board. On the T4 breakout I have a USB current limit chip on it which I don't have on the T4.1 breakout board. So attached a Powered Hub and all drives came up when MTP started. So no issue with MTP working with a Locked T4.
 
Last edited:
Ok, going to delete that one from my issues list. Thanks for retesting! :)

Not a problem - was watching backyard and front of the house flooding from IDA anyways. Just as a note I started adding the following test to example sketches for T4 and the 960K limit for the locked T4:
Code:
  // see if the Flash is present and can be initialized:
  // lets check to see if the T4 is setup for security first
  #if ARDUINO_TEENSY40
    if ((IOMUXC_GPR_GPR11 & 0x100) == 0x100) {
      //if security is active max disk size is 960x1024
      Serial.println("SECURITY ENABLED");
      if(file_system_size > 960*1024){
        diskSize = 960*1024;
        Serial.printf("PROGRAM disk defaulted to %u bytes\n", diskSize);  
      } else {
        diskSize = file_system_size;
        Serial.printf("PROGRAM disk using %u bytes\n", diskSize);
      }
    }
  #else
    diskSize = file_system_size;
  #endif
Should I go ahead and add to the LittleFS example sketch or hold off for now.
 
Malloc() works - but like the solution posted in #345 - the address is subject to change between builds.

The Great thing about the RAW Address is : it is always there - safe ABOVE the 32KB without wasting it for other use and as long as DMAMEM alloc()'s don't push up - it won't be corrupted in use or with a warm restart.

Also the p#345 is ugly with the secondary #define needed to edit to skip the 32KB - would be cleaner to have that not be in the shared RAM sketch but a separate DMAMEM_RAM example.

I don't suppose this is any better than the RAW number ? :: extern unsigned long _heap_end;
> seems I mentioned having a way for having malloc() allocate from that _heap_end point - then it wouldn't crash into it
 
Status
Not open for further replies.
Back
Top