Teensyduino 1.59 Beta #2

[jmarsh]

Not sure what the DMAMEM region size and 'dynamic calc' refers to? DMAMEM is a fixed 512KB aka RAM2 starting at 0x20200000. CrashReport and BreadCrumbs reside at a fixed location at the top of that 512KB region - up 524,160 bytes.

  struct arm_fault_info_struct *info = (struct arm_fault_info_struct *)0x2027FF80;
  struct crashreport_breadcrumbs_struct *bc = (struct crashreport_breadcrumbs_struct *)0x2027FFC0;

As recently mentioned in another thread, it's possible to make the DMAMEM region larger - FlexRAM can be configured three ways (ITCM / DTCM / OCRAM) and configuring it as OCRAM adds available memory starting at 0x20280000. This can be handy if you need >= 512KB of contiguous memory with more speed than what PSRAM is capable of (e.g. a large video framebuffer). Having the CrashReport area hardcoded where it currently is interferes with this, and the linker script already provides a pointer to the end of DMAMEM (_heap_end) that could be used instead.

(Not sure why I said 256KB, think that was a typo.)

[defragster]

As recently mentioned in another thread, it's possible to make the DMAMEM region larger - FlexRAM can be configured three ways (ITCM / DTCM / OCRAM) and configuring it as OCRAM adds available memory starting at 0x20280000. This can be handy if you need >= 512KB of contiguous memory with more speed than what PSRAM is capable of (e.g. a large video framebuffer). Having the CrashReport area hardcoded where it currently is interferes with this, and the linker script already provides a pointer to the end of DMAMEM (_heap_end) that could be used instead.

Yes, read that - but wasn't clicking here as related as seen. Not found for certain, but malloc knows the start after compile allocations and the top of DMA from linker passed values. If the .LD were changed to reconfigure, seems it could find/add a ref to use for that location it seems as other values are used in/on reset to locate things.

Testing decryption for locked Teensy posted a sketch that put all code in FLASH and called down through hundreds of copies of code to exceed the code cache and fill flash - written by code called Code4Code - it didn't run much slower running normally - maybe 5%? If it were adjusted to run code from DMAMEM and loaded there instead it would get 32KB cache and DMAMEM while slower than TCM should be faster than reading from FLASH? That would free up all of TCM for RAM and spare could still use the rest of DMAMEM. That wouldn't be a contiguous part over 512 ... but would be faster for RAM access.

[defragster]

Side note re p#118 - failed QSPI NAND Flash: It is a WSON package on a pinned T_4.1 - so hard to reach and not much contact area - but it worked before - also has a PSRAM on shared pads that works fine.
> first quick solder touch up - light flux paste and resolder - some of the prior solder was hard oxidized (hard to heat) looking and not shiny. :: Still failed
--> 2nd better reflow with more solder paste and some fresh solder - shiny balls again hopefully welded to WSON pads - and Isop#91 washed :: Fail again. It will complete a format and come up, but make root dirs and drive reports FULL.

Has this been tested with NOR or NAND flash on the other QSPI pads?

I believe LittleFS should be using only IP bus. Earlier experimental code did access flash chips by AHB. This change will probably break that old code, but maybe that's ok as we really only support Flash by LittleFS now.

re p#123 ran on QSPI NOR and NAND with LittleFS and Integrity tested good - no apparent affect on transfer rate like with PSRAM.

[mjs513]

@defragster
Believe LittleFs uses its own pre-fetch configuration and SPI is fixed at 30Mhz. If I remember the setups correctly its controlled via

	config.cache_size = info->progsize;
	config.lookahead_size = info->progsize;

but don't hold me too it. Its been too long since I played with those parameters.

[defragster]

@defragster
Believe LittleFs uses its own pre-fetch configuration and SPI is fixed at 30Mhz. If I remember the setups correctly its controlled via

	config.cache_size = info->progsize;
	config.lookahead_size = info->progsize;

but don't hold me too it. Its been too long since I played with those parameters.

You certainly could have forgotten more about that that I ever knew having coded some of that ... Might that apply to the QSPI? Aren't they faster than 30MHz? This, for PSRAM, is the MCU 'code' interface to QSPI setting AFAIK and is the PreFetch setting where MCU can read ahead of requested address to have it in cache if requested? Maybe this is bypassed under LittleFS for direct I/O?

[mjs513]

You certainly could have forgotten more about that that I ever knew having coded some of that ... Might that apply to the QSPI? Aren't they faster than 30MHz? This, for PSRAM, is the MCU 'code' interface to QSPI setting AFAIK and is the PreFetch setting where MCU can read ahead of requested address to have it in cache if requested? Maybe this is bypassed under LittleFS for direct I/O?

Just to refresh my memory I went back through littleFS setup for SPI and QSPI.
1. If the NAND or NOR is configured as SPI its fixed at 30Mhz. Tried going faster for the NAND but had issues.
2. For PSRAM on QSPI is fixed at 88Mhz in startup.c - I did have it running faster without any issues during beta testing.

In terms of QSPI for NAND, NOR and PSRAM I can't answer that 100% but gut feeling is that LittleFS will probably limit it. This is from lfs.h

    // Size of block caches. Each cache buffers a portion of a block in RAM.
    // The littlefs needs a read cache, a program cache, and one additional
    // cache per file. Larger caches can improve performance by storing more
    // data and reducing the number of disk accesses. Must be a multiple of
    // the read and program sizes, and a factor of the block size.
    lfs_size_t cache_size;

    // Size of the lookahead buffer in bytes. A larger lookahead buffer
    // increases the number of blocks found during an allocation pass. The
    // lookahead buffer is stored as a compact bitmap, so each byte of RAM
    // can track 8 blocks. Must be a multiple of 4.
    lfs_size_t lookahead_size;

As I said do not know the interaction between LittlFS and Pre-Fetch with the MCU. Never really looked at pre-fetch. If you are using PSRAM without using LittleFS I am sure it would help. Sure I am missing something.

[jmarsh]

Paul said LittleFS is only using IP bus commands. If that's the case enabling prefetching for AHB transactions would have no effect on it.

The PSRAM chip that I have claims to be able to do 133MHz but starts being unreliable at more than 120MHz (regardless of prefetching).

[defragster]

Paul said LittleFS is only using IP bus commands. If that's the case enabling prefetching for AHB transactions would have no effect on it.

There was that note - testing seemed to confirm that as nothing was faster ... and nothing broke - though so deep under the covers sketch observation is just anecdotal.

Just to refresh my memory I went back through littleFS setup for SPI and QSPI.
...

In terms of QSPI for NAND, NOR and PSRAM I can't answer that 100% but gut feeling is that LittleFS will probably limit it. This is from lfs.h
...
As I said do not know the interaction between LittlFS and Pre-Fetch with the MCU. Never really looked at pre-fetch. If you are using PSRAM without using LittleFS I am sure it would help. Sure I am missing something.

With the PR708 edit the PSRAM under LittleFS ran some 5% faster - when the files were larger. The PR tells the MCU to read more than needed with PreFetch and when that data is needed it helps without having to wait for it. So that is an MCU hardware level 'PreFetch/Caching' process since the MCU handles read/write of the QSPI - a full layer under what LittleFS does.

You got a better read of the NOR/NAND code there than here for sure. All I saw was SPI access - and that as noted would bypass the lowest level MCU PreFetch ... it seems based on notes by @Paul and @jmarsh that was what was expected.

[defragster]

@PaulStoffregen (@all) - looking at CrashReport - playing with recent topic on Stack overflow

Caused a CrashReport for killing the Stack:

T:\T_Drive\tCode\sketch_jul14a\sketch_jul14a.ino Jul 15 2023 22:57:32
CrashReport:
  A problem occurred at (system time) 22:58:9
  Code was executing from address 0x2F84
  CFSR: 82
	(DACCVIOL) Data Access Violation
	(MMARVALID) Accessed Address: 0x2006FB80 (Stack problem)
	  Check for stack overflows, array bounds, etc.
  Temperature inside the chip was 47.90 °C
  Startup CPU clock speed is 600MHz
  Reboot was caused by software write to SCB_AIRCR or CPU lockup
hello world before buffer clear

It was Causing an INSTANT restart so made me wonder if CrashReport uses more stack variables and crashing causes it to crash.

Wondering if any variable in CrashReportClass:rintTo(Print& p) should be made static?
> and in unused_interrupt_vector()? :: It recorded this crash correctly - AFAIK

Also noticed that none of the strings are F("inflash") so even though the code is in FLASH - the many strings are in RAM1?

So then I tried some extra strings to WATCH them appear in FLASH :: Please read and explain if this is going wrong?

In above :rintTo building with the following extra strings causes this memory size change from the first to ...?

    p.println("CrashReport:");

Memory Usage on Teensy 4.1:
  FLASH: code:38100, data:8168, headers:9024   free for files:8071172
   RAM1: variables:457600, code:33360, padding:32176   free for local variables:1152
   RAM2: variables:486272  free for malloc/new:38016

To this - where is seems the added string went to FLASH 'data' and RAM1/DTCM reducing 'free for local variables'?:

    p.println("CrashReport:");
    p.println("Cr1shReport12345678:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234");
    p.println("Cr2shReport12345678:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234");
    p.println("Cr3shReport12345678:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234");
    p.println("Cr4shReport12345678:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234");
    p.println("Cr5shReport12345678:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234");
    p.println("Cr6shReport12345678:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234");
    p.println("Cr7shReport12345678:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234");
    p.println("Cr8shReport12345678:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234");
    p.println("Cr9shReport12345678:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234");
    p.println("Cr0shReport12345678:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234");


Memory Usage on Teensy 4.1:
  FLASH: code:38316, data:9192, headers:8808   free for files:8070148
   RAM1: variables:458624, code:33360, padding:32176   free for local variables:128
   RAM2: variables:486272  free for malloc/new:38016

And using the F("") changes nothing where the above took out 1,024 bytes of RAM for 10 strings of 101 chars - It is still 'gone'?:

    p.println("CrashReport:");
    p.println(F("Cr1shReport12345678:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
    p.println(F("Cr2shReport12345678:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
    p.println(F("Cr3shReport12345678:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
    p.println(F("Cr4shReport12345678:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
    p.println(F("Cr5shReport12345678:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
    p.println(F("Cr6shReport12345678:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
    p.println(F("Cr7shReport12345678:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
    p.println(F("Cr8shReport12345678:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
    p.println(F("Cr9shReport12345678:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
    p.println(F("Cr0shReport12345678:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));


Memory Usage on Teensy 4.1:
  FLASH: code:38316, data:9192, headers:8808   free for files:8070148
   RAM1: variables:458624, code:33360, padding:32176   free for local variables:128
   RAM2: variables:486272  free for malloc/new:38016

And for repro this WIP that triggers this - added code and stack dropped as posted above and this happened - easy fix "uint8_t buf1[447500];", but seemed noteworthy:

extern "C" unsigned long _heap_start;
extern "C" unsigned long _heap_end;
extern "C" unsigned long  _stext;
extern "C" unsigned long  _etext;
uint8_t buf1[448000];
DMAMEM uint8_t buf2[480000];
uint32_t fooCnt = 0;
void setup() {
  Serial.begin(9600);
  while (!Serial) ;  // wait for serial monitor
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
  if ( CrashReport ) Serial.print( CrashReport );
  Serial.println("hello world before buffer clear");
  memset(buf1, 0x5A, sizeof(buf1));
  memset(buf2, 0xA5, sizeof(buf2));
  Serial.println("hello world after buffer clear");
  Serial.printf( "[HeapStart 0x%X] [HeapEnd 0x%X] [SText 0x%X] [EText 0x%X]\n",
                 ((uint32_t)&_heap_start) - 0x20200000, ((uint32_t)&_heap_end) - 0x20200000, (uint32_t)&_stext, (uint32_t)&_etext );
  foo( (uint32_t)&_heap_start );
}

uint32_t foo( uint32_t stPtr ) {
  uint32_t fooRet = 0;
  uint32_t bar[8];
  bar[0] = stPtr;
  fooCnt++;
  Serial.printf( "foo %u MYbar @%lu INbar %lu [HeapEnd %lu]\n", fooCnt, (uint32_t)bar, stPtr, &_heap_end );
  if ( fooCnt < 3 ) fooRet = foo( (uint32_t) bar );
  Serial.printf( "\tRet foo %u barRET %lu fooRet %lu [HeapEnd %lu]\n", fooCnt, fooRet, stPtr, &_heap_end );
  fooCnt--;
  return (uint32_t)bar;
}

void loop() {
}

[jmarsh]

Also noticed that none of the strings are F("inflash") so even though the code is in FLASH - the many strings are in RAM1?

So then I tried some extra strings to WATCH them appear in FLASH :: Please read and explain if this is going wrong?

I suspect F() isn't actually doing anything for Teensy4.

https://github.com/PaulStoffregen/co.../WString.h#L44

// Brian Cook's "no overhead" Flash String type (message on Dec 14, 2010)
// modified by Mikal Hart for his FlashString library
class __FlashStringHelper;
#ifndef F
#define F(string_literal) ((const __FlashStringHelper *)(string_literal))
#endif

Seems to be a direct cast to a __FlashStringHelper pointer, which is cast back to const char* in Print:rintf(const __FlashStringHelper *format, ...)

int Print::printf(const __FlashStringHelper *format, ...)
{
	va_list ap;
	va_start(ap, format);
#ifdef __STRICT_ANSI__
	va_end(ap);
	return 0;
#else
	int retval = vdprintf((int)this, (const char *)format, ap);
	va_end(ap);
	return retval;
#endif
}

In contrast, the definition of F for Teensy cores before 3 and 4 explicitly puts the argument (string) in PROGMEM using PSTR:

#define F(string_literal) ((const __FlashStringHelper *)(PSTR(string_literal)))

(I might be missing something here, if there's an alternate definition somewhere for F besides the one in cores/teensy4/WString.h)

[defragster]

I suspect F() isn't actually doing anything for Teensy4.
...

That was the idea I was getting.

Simple source to repro without hacking as above in CrashReport code - using those same strings - pulled one char so the ten should each be 100 bytes with NULL:

void setup() {
  Serial.begin(9600);
  while (!Serial) ;  // wait for serial monitor
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
  if ( CrashReport ) Serial.print( CrashReport );
}

void loop() {
#if 1 // NO big strings if 0
  /*  Memory Usage on Teensy 4.1:
    FLASH: code:12740, data:5096, headers:8784   free for files:8099844
     RAM1: variables:6432, code:8000, padding:24768   free for local variables:485088 */
#if 1 // big strings not forced to FLASH if 1 and 1 above
  /* Memory Usage on Teensy 4.1:
    FLASH: code:13124, data:6120, headers:8400   free for files:8098820
     RAM1: variables:7456, code:8384, padding:24384   free for local variables:484064 */
  Serial.println("Cr1shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234");
  Serial.println("Cr2shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234");
  Serial.println("Cr3shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234");
  Serial.println("Cr4shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234");
  Serial.println("Cr5shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234");
  Serial.println("Cr6shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234");
  Serial.println("Cr7shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234");
  Serial.println("Cr8shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234");
  Serial.println("Cr9shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234");
  Serial.println("Cr0shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234");
#else // big strings "forced" to FLASH ?
  /*  Memory Usage on Teensy 4.1:
    FLASH: code:13124, data:6120, headers:8400   free for files:8098820
     RAM1: variables:7456, code:8384, padding:24384   free for local variables:484064 */
  Serial.println(F("Cr1shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
  Serial.println(F("Cr2shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
  Serial.println(F("Cr3shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
  Serial.println(F("Cr4shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
  Serial.println(F("Cr5shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
  Serial.println(F("Cr6shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
  Serial.println(F("Cr7shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
  Serial.println(F("Cr8shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
  Serial.println(F("Cr9shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
  Serial.println(F("Cr0shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
#endif
#endif
  while (1);
}

[PaulStoffregen]

@Defragster - Could I talk you into comparing this string memory usage with 1.57 (gcc 5.4 with C++14) and 1.58 (gcc 11.3 with C++14) ?

[jmarsh]

I would suggest simply trying PSTR() instead of F().

[defragster]

@Defragster - Could I talk you into comparing this string memory usage with 1.57 (gcc 5.4 with C++14) and 1.58 (gcc 11.3 with C++14) ?

>> same results under 1.57 - below as :: // IDE 1.8.19 TD 1.57

I would suggest simply trying PSTR() instead of F().

>> This looks to have worked as expected - see setup()

Results repeated above are TD 1.59.b2, new results for TD 1.57 commented as such - ALL new results in RED

Updated:

void setup() {
  Serial.begin(9600);
  while (!Serial) ;  // wait for serial monitor
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
  if ( CrashReport ) Serial.print( CrashReport );

#if 1 // big strings not forced to FLASH if 1 and 1 above
/* Memory Usage on Teensy 4.1:
  FLASH: code:12932, data:6096, headers:8616   free for files:8098820
   RAM1: variables:6432, code:8192, padding:24576   free for local variables:485088 */
  Serial.println(PSTR("Cr1shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
  Serial.println(PSTR("Cr2shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
  Serial.println(PSTR("Cr3shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
  Serial.println(PSTR("Cr4shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
  Serial.println(PSTR("Cr5shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
  Serial.println(PSTR("Cr6shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
  Serial.println(PSTR("Cr7shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
  Serial.println(PSTR("Cr8shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
  Serial.println(PSTR("Cr9shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
  Serial.println(PSTR("Cr0shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
  /* Memory Usage on Teensy 4.1: // IDE 1.8.19 TD 1.57
  FLASH: code:13428, data:7120, headers:9144   free for files:8096772
   RAM1: variables:7168, code:8960, padding:23808   free for local variables:484352 */
  #endif
}

void loop() {
#if 0 // NO big strings if 0
  /*  Memory Usage on Teensy 4.1:
    FLASH: code:12740, data:5096, headers:8784   free for files:8099844
     RAM1: variables:6432, code:8000, padding:24768   free for local variables:485088 */
     /* Memory Usage on Teensy 4.1:  // IDE 1.8.19 TD 1.57
  FLASH: code:13236, data:6120, headers:8288   free for files:8098820
   RAM1: variables:7168, code:8768, padding:24000   free for local variables:484352 */
#if 0 // big strings not forced to FLASH if 1 and 1 above
  /* Memory Usage on Teensy 4.1:
    FLASH: code:13124, data:6120, headers:8400   free for files:8098820
     RAM1: variables:7456, code:8384, padding:24384   free for local variables:484064 */
  Serial.println("Cr1shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234");
  Serial.println("Cr2shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234");
  Serial.println("Cr3shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234");
  Serial.println("Cr4shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234");
  Serial.println("Cr5shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234");
  Serial.println("Cr6shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234");
  Serial.println("Cr7shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234");
  Serial.println("Cr8shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234");
  Serial.println("Cr9shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234");
  Serial.println("Cr0shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234");
  /* Memory Usage on Teensy 4.1:  // IDE 1.8.19 TD 1.57
  FLASH: code:13364, data:7144, headers:9184   free for files:8096772
   RAM1: variables:8192, code:8896, padding:23872   free for local variables:483328 */
#else // big strings "forced" to FLASH ?
  /*  Memory Usage on Teensy 4.1:
    FLASH: code:13124, data:6120, headers:8400   free for files:8098820
     RAM1: variables:7456, code:8384, padding:24384   free for local variables:484064 */
  Serial.println(F("Cr1shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
  Serial.println(F("Cr2shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
  Serial.println(F("Cr3shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
  Serial.println(F("Cr4shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
  Serial.println(F("Cr5shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
  Serial.println(F("Cr6shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
  Serial.println(F("Cr7shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
  Serial.println(F("Cr8shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
  Serial.println(F("Cr9shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
  Serial.println(F("Cr0shReport1234567:abcdefghijklmnopqrstuvwxyz1234CrashReport12345678:abcdefghijklmnopqrstuvwxyz1234"));
  /* Memory Usage on Teensy 4.1:  // IDE 1.8.19 TD 1.57
  FLASH: code:13428, data:7144, headers:9120   free for files:8096772
   RAM1: variables:8192, code:8960, padding:23808   free for local variables:483328 */
#endif
#endif
  while (1);
}

[defragster]

Just made this QNEthernet sketch and built default FASTER it works, after below FAIL, it works to run FAST WITH LTO

FAIL: Build FASTER with LTO completes and uploads and the T_4.1 goes MISSING.

Sketch posted: github.com/Defragster/TeensySketches/tree/main/TCP_UDPstaticIP

[PaulStoffregen]

I set the "Smalles Code with LTO" option. I chose a simple blink code from the example library.
I uploaded it after compile. That worked. After that, I change the delay from 1000ms to 100ms to see if the update was working or not.
After pressing upload, Teensy started again and I got a timeout while uploading.

Got this error:
Teensy did not respond to a USB-based request to enter program mode.
Please press the PROGRAM MODE BUTTON on your Teensy to upload your sketch.

Please note thtat there was no problem with platformio, not with the normal case.
I have a problem when I try Lockable verision. Or Teensy is locked with the key.

I was able to reproduce this problem. Only happens on Lockable Teensy with optimization Smallest Code with LTO.

Must admit, I don't fully understand why this happens. But I eventually tracked the problem down to the _reboot_Teensyduino_() function not working when LTO builds it as inline. To dig into the problem I defined it as noinline so I could compare the code, but without inline the exact same (working) code is generated. Really wish I fully understood why this works, but for now going with just using noinline.

https://github.com/PaulStoffregen/co...42fd4baddc8b45

[defragster]

Just made this QNEthernet sketch and built default FASTER it works, after below FAIL, it works to run FAST WITH LTO

FAIL: Build FASTER with LTO completes and uploads and the T_4.1 goes MISSING.

Sketch posted: github.com/Defragster/TeensySketches/tree/main/TCP_UDPstaticIP

Pulled latest github_PaulStoffregen_CORES: {This branch is up to date with PaulStoffregen/cores:master.}
> Upload code as noted to a LOCKED T_4.1 and no trouble LDO FAST or LDO FASTER. Early lockable (?) ser#: 9706370

> Same upload to Unlocked T_4.1 and LDO FAST works
> Upload LDO FASTER and after upload I see 7 blinks one time and the Teensy goes offline. : This is an old T_4.1 with heat sync from early days testing ser#: 7658860
>> Confirmed same results with 2nd standard (not lockable) T_4.1 in same config: this unit is New Feb 2023 sent by PJRC [#21 ser#: 13287570]

Repeated multiple times with Button press uploads. Windows 11 PRO - IDE 1.8.19 - and github's cores copied to: T:\T_Drive\arduino-1.8.19\hardware\teensy\avr\cores
> confirmed latest CrashReport.h edit fails when ';' removed: T:\T_Drive\arduino-1.8.19\hardware\teensy\avr\cores\teensy4/CrashReport.h:28:25: error: expected ';' before 'b'

>> Updated to latest of github.com/ssilverman/QNEthernet and rebuilding same result

Memory Usage on Teensy 4.1:
  FLASH: code:149168, data:22472, headers:8580   free for files:7946244
   RAM1: variables:28000, code:142660, padding:21180   free for local variables:332448
   RAM2: variables:79744  free for malloc/new:444544
"T:\\T_Drive\\arduino-1.8.19\\hardware\\teensy/../tools/stdout_redirect" "T:\\TEMP\\arduino_build_37639/TCP_UDPstaticIP.ino.lst" "T:\\T_Drive\\arduino-1.8.19\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objdump" -d -S -C "T:\\TEMP\\arduino_build_37639/TCP_UDPstaticIP.ino.elf"
Using library QNEthernet at version 0.24.0-snapshot in folder: T:\T_Drive\tCode\libraries\QNEthernet 
Using library Time at version 1.6.1 in folder: T:\T_Drive\arduino-1.8.19\hardware\teensy\avr\libraries\Time

[pr8x]

Did some testing and 1.59 seems to run much more stable than 1.58. I am seeing far less glitches with the Teensy hanging on boot for certain optimization flags:

I checked (with --specs=nano.specs as well):

- DTEENSY_OPT_DEBUG_LTO
- DTEENSY_OPT_DEBUG
- DTEENSY_OPT_FAST
- DTEENSY_OPT_FASTEST_LTO

And they all worked fine for my project. However

- DTEENSY_OPT_FASTEST
- DTEENSY_OPT_FASTEST_LTO

seem to cause my T4.1 to get stuck somehow. Will try to make a repro in Arduino IDE, but will probably take some while since the project is quite complex and many moving parts could cause this...

[acumartini]

I have not read every post in detail here but it looks like some attention is being paid to compiler time. I have been unable to upgrade to the latest release because compilation is just too slow. At first I though it was because my macbook was older, but I have a brand new M2 macbook now and it is still too slow for development. I opened an issue with platformio integration in case it is specific to the tooling there, but I am guessing the underlying issue is with the GCC tooling changes in 1.58.

Issue for reference: https://github.com/platformio/platfo...nsy/issues/105

[Mcu32]

I have not read every post in detail here but it looks like some attention is being paid to compiler time.

Try Platformio, it compiles faster.

[defragster]

Try Platformio, it compiles faster.

It seems that p#144 is specifically calling out use with Platformio and the newer update to toolchain.

[BriComp]

Try Platformio, it compiles faster.

I opened an issue with platformio integration in case it is specific to the tooling there,

He is!! .

[Mcu32]

hm ok you're right

[BriComp]

Sorry Frank, did not see it was you before doing the reply.
Regards.