Forum Rule: Always post complete source code & details to reproduce any issue!
Page 6 of 6 FirstFirst ... 4 5 6
Results 126 to 149 of 149

Thread: Teensyduino 1.59 Beta #2

  1. #126
    Senior Member
    Join Date
    Mar 2023
    Posts
    215
    Quote Originally Posted by defragster View Post
    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.
    Code:
      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.)

  2. #127
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    17,433
    Quote Originally Posted by jmarsh View Post
    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.

  3. #128
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    17,433
    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.


    Quote Originally Posted by PaulStoffregen View Post
    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.

  4. #129
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    8,758
    @defragster
    Believe LittleFs uses its own pre-fetch configuration and SPI is fixed at 30Mhz. If I remember the setups correctly its controlled via
    Code:
    	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.

  5. #130
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    17,433
    Quote Originally Posted by mjs513 View Post
    @defragster
    Believe LittleFs uses its own pre-fetch configuration and SPI is fixed at 30Mhz. If I remember the setups correctly its controlled via
    Code:
    	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?

  6. #131
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    8,758
    Quote Originally Posted by defragster View Post
    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
    Code:
        // 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.

  7. #132
    Senior Member
    Join Date
    Mar 2023
    Posts
    215
    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).

  8. #133
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    17,433
    Quote Originally Posted by jmarsh View Post
    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.

    Quote Originally Posted by mjs513 View Post
    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.

  9. #134
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    17,433
    @PaulStoffregen (@all) - looking at CrashReport - playing with recent topic on Stack overflow

    Caused a CrashReport for killing the Stack:
    Code:
    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 ...?
    Code:
        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'?:
    Code:
        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'?:
    Code:
        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:
    Code:
    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() {
    }

  10. #135
    Senior Member
    Join Date
    Mar 2023
    Posts
    215
    Quote Originally Posted by defragster View Post
    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
    Code:
    // 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, ...)
    Code:
    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:
    Code:
    #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)

  11. #136
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    17,433
    Quote Originally Posted by jmarsh View Post
    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:
    Code:
    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);
    }

  12. #137
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    28,469
    @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) ?

  13. #138
    Senior Member
    Join Date
    Mar 2023
    Posts
    215
    I would suggest simply trying PSTR() instead of F().

  14. #139
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    17,433
    Quote Originally Posted by PaulStoffregen View Post
    @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

    Quote Originally Posted by jmarsh View Post
    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:
    Code:
    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);
    }

  15. #140
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    17,433

    FASTER LTO fails, but FASTER and FAST LTO works.

    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

  16. #141
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    28,469
    Quote Originally Posted by ted View Post
    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

  17. #142
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    17,433
    Quote Originally Posted by defragster View Post
    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
    Code:
    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

  18. #143
    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...

  19. #144
    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

  20. #145
    Senior Member
    Join Date
    Sep 2021
    Posts
    239
    Quote Originally Posted by acumartini View Post
    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.

  21. #146
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    17,433
    Quote Originally Posted by Mcu32 View Post
    Try Platformio, it compiles faster.
    It seems that p#144 is specifically calling out use with Platformio and the newer update to toolchain.

  22. #147
    Senior Member BriComp's Avatar
    Join Date
    Apr 2014
    Location
    Cheltenham, UK
    Posts
    1,376
    Quote Originally Posted by Mcu32 View Post
    Try Platformio, it compiles faster.
    I opened an issue with platformio integration in case it is specific to the tooling there,
    He is!! .

  23. #148
    Senior Member
    Join Date
    Sep 2021
    Posts
    239
    hm ok you're right

  24. #149
    Senior Member BriComp's Avatar
    Join Date
    Apr 2014
    Location
    Cheltenham, UK
    Posts
    1,376
    Sorry Frank, did not see it was you before doing the reply.
    Regards.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •