T4.0 Memory - trying to make sense of the different regions

beermat · Feb 25, 2020

Frank B said:
.. Have fun til next update

I'm having fun, thanks for this, my sketch now has the headroom it needs (although the IDE still reports way more global variable space usage when I chose FLASH memory vs compiling on the Teensy 3.6).

One issue, though - when I compile/link my sketch to flash memory using your modified linker above, audio stops working. Switch back to ITCM and it works. I'm using the Audio library and various modules (AudioPlaySdWav, AudioPlayQueue, AudioMixer4, AudioAmplifier, AudioOutputI2S2). No errors returned in my code, just no audio output. In one area my sketch makes a call to playSdWav1.isPlaying() and waits for true to synch other actions to the sound, and it just waits there. This is only when I choose flash; ITCM it all works. Under flash, all my other code - driving TFT, accessing hardwired SD card, etc - seems to be fine. Thanks for your help on this!

Frank B · Feb 27, 2020

That's too unspecific..

I connected an audioshield and tested the Guitar - example: works.
Can you post a !minimal! example which does not work?

xenington · Apr 19, 2020

ITCM spillover?

Sorry for resurrecting this thread, but I have suddenly found it very interesting.

My program is randomly dropping sensor readings and copying over variables with strange numbers. I think it might be a memory problem.

I did a freemem() of it after setup:

Code:

ITCM: 64kB, DTCM: 448kB, OCRAM: 0(+512)kB [DDDDDDDDDDDDDDII]
ITCM:   55376 84.50% of   64kB (  10160 Bytes free) (RAM1) FASTRUN
OCRAM:  12384  2.36% of  512kB ( 511904 Bytes free) (RAM2) DMAMEM, Heap
FLASH:  67456  3.22% of 2048kB (2029696 Bytes free) FLASHMEM, PROGMEM
DTCM:
   458752 Bytes (448 kB)
-   17088 Bytes (16 kB) global variables
-     104 Bytes (0 kB) stack (currently)
=========
   441560 Bytes free (431 kB), 17192 Bytes in use (16 kB).
Size of Free ITCM in Bytes = 10156
Start of Free ITCM = 55380 [D854] 
End of Free ITCM = 65536 [10000]

The ITCM part of RAM1 is close to filling 2 blocks of memory (84.5%) so I tried to reduce it by using FLASHMEM on all functions except loop() and DMAMEM on most non-const variables. This is the result:

Code:

ITCM: 64kB, DTCM: 448kB, OCRAM: 0(+512)kB [DDDDDDDDDDDDDDII]
ITCM:   53856 82.18% of   64kB (  11680 Bytes free) (RAM1) FASTRUN
OCRAM:  23200  4.43% of  512kB ( 501088 Bytes free) (RAM2) DMAMEM, Heap
FLASH:  69072  3.29% of 2048kB (2028080 Bytes free) FLASHMEM, PROGMEM
DTCM:
   458752 Bytes (448 kB)
-   17088 Bytes (16 kB) global variables
-     104 Bytes (0 kB) stack (currently)
=========
   441560 Bytes free (431 kB), 17192 Bytes in use (16 kB).
Size of Free ITCM in Bytes = 11676
Start of Free ITCM = 53860 [D264] 
End of Free ITCM = 65536 [10000]

The number of dropped readings went down, but did not go away altogether, and the variables stopped changing.

Is it possible that during runtime, the program is overflowing the 64KB of ITCM that has been allocated to it? I am assuming that once this amount has been set, it cannot be changed because other stuff has already been piled on top of it? Can more ITCM be allocated to the FASTRUN code, say another 32KB block? Or might it be best to aim for a program that just spills over the 32KB line, thus reserving 31KB or so for runtime?

Cheers

xenington · Apr 19, 2020

Ignore that last post

Ignore that last post. I haven't had my morning coffee yet.

Compiling the program using the 'smallest' option leaves nearly 30KB of ITCM free:

Code:

ITCM: 64kB, DTCM: 448kB, OCRAM: 0(+512)kB [DDDDDDDDDDDDDDII]
ITCM:   35952 % of   64kB (  29584 Bytes free) (RAM1) FASTRUN
OCRAM:  12384 % of  512kB ( 511904 Bytes free) (RAM2) DMAMEM, Heap
FLASH:  45008 % of 2048kB (2052144 Bytes free) FLASHMEM, PROGMEM

DTCM:
   458752 Bytes (448 kB)
-   12992 Bytes (12 kB) global variables
-     128 Bytes (0 kB) stack (currently)
=========
445632 Bytes free (435 kB), 13120 Bytes in use (12 kB).
Size of Free ITCM in Bytes = 29580
Start of Free ITCM = 35956 [8C74] 
End of Free ITCM = 65536 [10000]

Readings are still being dropped. Back to the drawing board...

KurtE · Apr 19, 2020

Again hard to say why you are losing data, without any clues on what your program is actually doing.
As mentioned in the first post as well as then the updated data on the PJRC website: https://www.pjrc.com/store/teensy40.html
The fast memory area of the chip is 512kb of which part is DTCM and part is ITCM. This main memory is comprised of 16 32kb chunks of memory, where each chunk of memory will be marked as either DATA or CODE. How many blocks will be marked as code, depends on how big your program is (rounded up to multiples of 32kb) This does not include the code marked as FLASHMEM which will be run from the slower memory. So if your program is under 32kb it will use 1 of the 16 chunks. If it is >32kb and <64kb it will use 2, likewise if over 64kb and under 96kb 3...

So with your above: ITCM: 64kB, DTCM: 448kB, OCRAM: 0(+512)kB [DDDDDDDDDDDDDDII]
It is showing that two of the chunks were allocated to ITCM (the two I's in the above)
And the rest is assigned to be data:

The 82% is not very interesting or important, other than it is showing you how close you are to needing a 3rd page of code... And there are some hacks one can do to try to use the remaining parts of that chunk for data... Without those hacks, that memory will not be used for anything. Likewise, with the majority of your ITCM (faster) memory will not be used for anything, except what variables you have that go onto the stack (local variables to functions...) Anything that is created by new operations or malloc will go into the heap

As for dropping readings. There is nothing mentioned in your post on how you are getting these readings. From a serial port? SPI? Wire? ... The one interesting thing with these memory regions and readings is if you are doing something that for example does DMA operations. If these DMA operations are going to or from RAM2 (DMAMEM new/Malloc) area than you have some stuff to deal with. As these areas of memory have a cache setup, and normal operations use the cache and DMA goes to/from the physical memory so if these two are not in sync you get interesting results. That is if your are doing DMA from this memory, you need to make sure the cache memory is written out to the physical memory. And if your operation is using DMA to write out to the physical memory, you need to tell the cache that this area is no longer valid and it needs to fetch the data...

But again no idea if this is your issue or not.,

xenington · Apr 19, 2020

Yes, I understand, the query was intended to be general. Thank you for trying to help anyway. Incidentally, I now think that the problem might be caused by the screen I am using (RA8875), but that needs a different thread.

My original thought was that if the FASTRUN code was close to filling a whole chunk, say 30KB out of 32KB, or 95KB out of 96KB, could something happen during runtime that might require additional ITCM and cause a spillover? Where might that additional memory come from if the global variables are on top? Or am I doing the compiler a great disservice and it is much cleverer than that?

KurtE · Apr 19, 2020

As far as I know, the only thing that writes to ITCM area is the startup code.

That simply copies the stuff from FLASH memory into the ITCM area, with a really simple copy:
memory_copy(&_stext, &_stextload, &_etext);

Which is the same data shown in your debug outputs. Unlike a PC where there are libraries loaded at run time, with the Teensy the linker will place everything in their final positions which the loader simply uses. Hope that makes sense.

So nothing else uses that extra 2K... Unless you are @defragster

who has test code to allow one to claim that memory to put some variables...

As for RA8875, as you mentioned probably should discuss on a different thread. Either a new one or there are a couple of ones discussing some stuff, that might help, including:
https://forum.pjrc.com/threads/59563-Teensy-4-0-RA8875
https://forum.pjrc.com/threads/57280-RA8875-from-Buydisplay

xenington · Apr 19, 2020

KurtE said:
Hope that makes sense.

Yes, it does. Very interesting - thank you.

bicycleguy · May 11, 2020

Using the code https://forum.pjrc.com/threads/57326-T4-0-Memory-trying-to-make-sense-of-the-different-regions?p=227539&viewfull=1#post227539 #83 in this thread I get the same output for T4.0 and T4.1 Isn't 4.1 supposed to have more flash?

Frank B · May 11, 2020

That old code does not support the T4.1 - i'll update the post....

Frank B · May 11, 2020

Done....

bicycleguy · May 11, 2020

Thanks Frank
That was FAST !

thought there might be more to it than just the defines.

ps. It took me longer to reply than it took you to fix post and reply !

bicycleguy · May 12, 2020

Having a little issue:
Using the new code in #83 it seems to work fine for T4.0 and T4.1 at >150MHz CPU:

Code:

@150MHz:
/var/folders/b9/m7vp5hr925n_3r73_y07979w0000gn/T/arduino_modified_sketch_595702/memory2.ino May 12 2020 18:12:10
Teensyduino version 1.52

ITCM: 32kB, DTCM: 480kB, OCRAM: 0(+512)kB [DDDDDDDDDDDDDDDI]
ITCM:   23200 70.80% of   32kB (   9568 Bytes free) (RAM1) FASTRUN
OCRAM:  12384  2.36% of  512kB ( 511904 Bytes free) (RAM2) DMAMEM, Heap
FLASH:  33632  0.41% of 7936kB (8092832 Bytes free) FLASHMEM, PROGMEM
DTCM:
   491520 Bytes (480 kB)
-   12992 Bytes (12 kB) global variables
-      80 Bytes (0 kB) stack (currently)
=========
   478448 Bytes free (467 kB), 13072 Bytes in use (12 kB).

but at 24MHz:

Code:

@24MHz:
/var/folders/b9/m7vp5hr925n_3r73_y07979w0000gn/T/arduino_modified_sketch_347420/memory2.ino May 12 2020 18:13:39
Teensyduino version 1.52

ITCM: 32kB, DTCM: 480kB, OCRAM: 0(+512)kB [DDDDDDDDDDDDDDDI]
ITCM:   23200 70.80% of   32kB (   9568 Bytes free) (RAM1) FASTRUN
OCRAM:  12384  2.36% of  512kB ( 511904 Bytes free) (RAM2) DMAMEM, Heap
FLASH:  33632  0.41% of 7936kB (8092832 Bytes free) FLASHMEM, PROGMEM
DTCM:
   491520 Bytes (480 kB)
-   12992 Bytes (12 kB) global variables
OCRAM:  12384  2.36% of  512kB ( 511904 Bytes free) (RAM2) DMAMEM, Heap
�>{����
J=========
   478448 Bytes free (467 kB), 13072 Bytes in use (12 kB).

Opitimization setting doesn't seem to matter. The OCRAM line repeats. Maybe there was something about not using USB at this speed? Or a Arduino terminal issue with Mac Catalina only thing?

Don't seem to have any terminal problems with other programs, even ones with a lot of fast printout.

XFer · May 13, 2020

bicycleguy said:
Maybe there was something about not using USB at this speed?

I would exclude this.
I'm running 4.0 at 24 MHz with USB just fine (Teensyduino 1.52beta4).

bicycleguy · May 13, 2020

Has anyone else tried the code posted at #83 https://forum.pjrc.com/threads/5732...ferent-regions?p=227539&viewfull=1#post227539 at 24 MHz? Did you get the results two post above?

Been trying all sorts of variations of stuffing print statements in and moving code around. It seems to:
1. work fine at other CPU speeds
2. work fine if I include the flexRamInfo() function in other code
3. not work no matter if I add additional print statements in the function or move around the existing statements
The second to the last time the fmtstr is used like Serial.printf(fmtstr, "OCRAM:", ... it will show up again overwriting the third to last print statement

4. for some reason print statements using
const char* fmtstr = "%-6s%7d %5.02f%% of %4dkB (%7d Bytes free) %s\n";
seem to duplicate
5. thought it didn't matter before(maybe me) but optimization setting of debug crashes Teensy(short press to reload) and setting of 'smallest code' causes more print errors earlier at any CPU setting.

macrosii · Jul 15, 2020

Hi

I am trying to understand the T4/4.1 Memory structure and using Fanks excellent T4_PowerButton library to display memory usage.

With the code below I was expecting that the line iptr = (int*) malloc(32 * 1024 * sizeof(int)); would take 128K from the heap which I thought was in RAM2/OCRAM.
However I dont see any increase area using the memory function flexRamInfo(), what I get is as below. I am likely doing something stupid or misunderstanding.
Thanks in adavnce for any help.

OUTPUT
C:\Users\Robert\Documents\Arduino\libraries\T4_PowerButton-master\T4_PowerButton.cpp Jul 15 2020 13:32:12
Teensyduino version 1.53
Mem Free : 412964
Heap Free : 446360
Max Stack : 928
*******************************************
FLASH: 37144 0.46% of 7936kB (8089320 Bytes free) FLASHMEM, PROGMEM
ITCM: 24248 74.00% of 32kB ( 8520 Bytes free) (RAM1) FASTRUN
PSRAM: 16 MB
OCRAM:
524288 Bytes (512 kB)
- 77920 Bytes (76 kB) DMAMEM
- 208 Bytes (0 kB) Heap
446160 Bytes heap free (435 kB), 78128 Bytes OCRAM in use (76 kB).
DTCM:
491520 Bytes (480 kB)
- 78528 Bytes (76 kB) global variables
- 1268 Bytes (1 kB) max. stack so far
=========
411724 Bytes free (402 kB), 79796 Bytes in use (77 kB).

Code

Code:

byte buff[1024 * 64];           //64K from DTCM
DMAMEM byte buff2[1024 * 64];  //64K from DMAMEM



#include "T4_PowerButton.h" 


// constants won't change. Used here to set pin numbers:
  // Pin 13: Arduino has an LED connected on pin 13
  // Pin 11: Teensy 2.0 has the LED on pin 11
  // Pin  6: Teensy++ 2.0 has the LED on pin 6
  // Pin 13: Teensy 3.0 has the LED on pin 13
const int ledPin =  13;      // the number of the LED pin

// Variables will change:
int ledState = LOW;             // ledState used to set the LED
long previousMillis = 0;        // will store last time LED was updated

// the follow variables is a long because the time, measured in miliseconds,
// will quickly become a bigger number than can be stored in an int.
long interval = 1000;           // interval at which to blink (milliseconds)

void setup() {
  // set the digital pin as output:
  delay(5000);
  pinMode(ledPin, OUTPUT);     
  buff[0] =1;
  buff2[0]=1; 
  int *iptr;
  iptr = (int*) malloc(32 * 1024 * sizeof(int)); //128K from heap ?
  iptr[1] = 45;
  Serial.println("Setup***************************************");
  progInfo();
  Serial.print("Mem Free  : ");Serial.println(memfree());
  Serial.print("Heap Free : ");Serial.println(heapfree());
  Serial.print("Max Stack : ");Serial.println(maxstack());
  Serial.println("*******************************************");
  flexRamInfo();
  Serial.println("*******************************************");
}

KurtE · Jul 30, 2020

Quick update as well. I also updated my version of the code that you can put into the build to show information as described in post #3 (I think). It uses updating the platform.txt file and prints the stuff as part of a build. Added the support for T4.1. There is a version of this that someone else updated for T4.1 that is part of @defragsters TSET github project.

Changes made: Added T4.1
Added more descriptive output for DTCM versus ITCM configuration.
Changed \r's to \n's as the later versions of Arduino IDE appear to want that change...

Example output from build...

Code:

nking everything together...
"C:\\arduino-1.8.13\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -O2 -Wl,--gc-sections,--relax "-TC:\\arduino-1.8.13\\hardware\\teensy\\avr\\cores\\teensy4/imxrt1062_t41.ld" -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -o "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_998054/JoystickBT.ino.elf" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_998054\\sketch\\JoystickBT.ino.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_998054\\libraries\\USBHost_t36\\adk.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_998054\\libraries\\USBHost_t36\\antplus.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_998054\\libraries\\USBHost_t36\\bluetooth.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_998054\\libraries\\USBHost_t36\\digitizer.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_998054\\libraries\\USBHost_t36\\ehci.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_998054\\libraries\\USBHost_t36\\enumeration.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_998054\\libraries\\USBHost_t36\\hid.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_998054\\libraries\\USBHost_t36\\hub.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_998054\\libraries\\USBHost_t36\\joystick.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_998054\\libraries\\USBHost_t36\\keyboard.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_998054\\libraries\\USBHost_t36\\keyboardHIDExtras.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_998054\\libraries\\USBHost_t36\\memory.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_998054\\libraries\\USBHost_t36\\midi.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_998054\\libraries\\USBHost_t36\\mouse.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_998054\\libraries\\USBHost_t36\\print.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_998054\\libraries\\USBHost_t36\\rawhid.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_998054\\libraries\\USBHost_t36\\serial.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_998054/..\\arduino_cache_552016\\core\\core_349b947665b8f07e40bba91441b96389.a" "-LC:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_998054" -larm_cortexM7lfsp_math -lm -lstdc++
"C:\\arduino-1.8.13\\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\\kurte\\AppData\\Local\\Temp\\arduino_build_998054/JoystickBT.ino.elf" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_998054/JoystickBT.ino.eep"
"C:\\arduino-1.8.13\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objcopy" -O ihex -R .eeprom "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_998054/JoystickBT.ino.elf" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_998054/JoystickBT.ino.hex"
"C:\\arduino-1.8.13\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objcopy" -O ihex -R .eeprom "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_998054/JoystickBT.ino.elf" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_998054/JoystickBT.ino.TEENSY41.hex"
"C:\\arduino-1.8.13\\hardware\\teensy/../tools/stdout_redirect" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_998054/JoystickBT.ino.lst" "C:\\arduino-1.8.13\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objdump" -d -S -C "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_998054/JoystickBT.ino.elf"
"C:\\arduino-1.8.13\\hardware\\teensy/../tools/stdout_redirect" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_998054/JoystickBT.ino.sym" "C:\\arduino-1.8.13\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objdump" -t -C "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_998054/JoystickBT.ino.elf"
cmd /c "C:\\arduino-1.8.13\\hardware\\teensy\\..\\tools\\arm\\bin\\arm-none-eabi-gcc-nm -n C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_998054\\JoystickBT.ino.elf | D:\\GITHUB\\imxrt-size\\Debug\\imxrt-size.exe"

FlexRAM section ITCM+DTCM = 512 KB
    Config : aaaaaaaf (DDDDDDDDDDDDDDII)
    ITCM :  65224 B	(99.52% of   64 KB)
    DTCM :  41664 B	( 9.08% of  448 KB)
    Available for Stack: 417088
OCRAM: 512KB
    DMAMEM:  12384 B	( 2.36% of  512 KB)
    Available for Heap: 511904 B	(97.64% of  512 KB)
Flash:  88808 B	( 1.09% of 7936 KB)
Using library USBHost_t36 at version 0.1 in folder: C:\Users\kurte\Documents\Arduino\libraries\USBHost_t36 
"C:\\arduino-1.8.13\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-size" -A "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_998054/JoystickBT.ino.elf"
Sketch uses 88800 bytes (1%) of program storage space. Maximum is 8126464 bytes.
Global variables use 107188 bytes (20%) of dynamic memory, leaving 417100 bytes for local variables. Maximum is 524288 bytes.

defragster · Jul 30, 2020

Updated the copy of Windows github.com/Defragster/Tset/ to use this KurtE version - though it is renamed imxrt_size.exe. Using that in 'editor of choice' that can run external batch files to execute a true IDE based build into a console window - or from command line. That memory data is shown on T_4.x builds without edits to platform.txt.

beermat · Sep 4, 2020

Frank B said:
Edit:

Ok, new try rename linkerfile above to imxrt1062f.ld

FASTRUN works. The pervious version from an hour ago had a problem with the calculated number of ITCM blocks. This is fixed.
Edit:
The attached file in #138 allows FASTRUN, but allocates at least one block ITCM.
The version from POST #131 ignores FASTRUN and puts everything into the flash.

Frank, is this maintained somewhere for Teensy 4.1? I really hate being forced to load up my ITCM with tons of 3rd part library code that I don't need there, at the expense of being able to use that RAM for, umm, variables, but I don't know enough to maintain linker scripts.

KurtE · Oct 25, 2020

@defragster and all,

I pushed up an updated version of the not very robust imxrt_size code (https://github.com/KurtE/imxrt-size)

That put a little bailing wire on the not overly robust detection and recovery code, but at least it did a quick and dirty fix that with the new Teensyduino beta, fixes the issue where it was not properly finding the stack information and printing out some negative value which it would then error out on.

Also for the fun of it added Quick and dirty addition to the code that if it finds the new tags added for enternal memory start and end it will print out how much EXTMEM was reserved for variables.

On my machine I copied the new binary out to where the tset projct is, so that my builds in sublimetext 3 uses it...

Example output for test code for Camera where I put the buffer out in EXTMEM:

Code:

estack:20070000 ebss:200072c0

FlexRAM section ITCM+DTCM = 512 KB
    Config : aaaaaaaf (DDDDDDDDDDDDDDII)
    ITCM :  57592 B	(87.88% of   64 KB)
    DTCM :  29376 B	( 6.40% of  448 KB)
    Available for Stack: 429376
OCRAM: 512KB
    DMAMEM: 319584 B	(60.96% of  512 KB)
    Available for Heap: 204704 B	(39.04% of  512 KB)
Extmem Used: 614400
Flash:  77064 B	( 0.95% of 7936 KB)

Note for now I left the debug message for the estack and ebss until I am sure I am not running into the issue any more.

luni · Oct 25, 2020

Interesting. I'm using the linker option -Wl,--print-memory-usage in my builds which gives this output:

Code:

Memory region         Used Size  Region Size  %age Used
            ITCM:         32 KB       512 KB      6.25%
            DTCM:      112384 B       512 KB     21.44%
             RAM:      268384 B       512 KB     51.19%
           FLASH:       23008 B      7936 KB      0.28%
            ERAM:          3 MB        16 MB     18.75%

for this sketch

Code:

EXTMEM char buf1[3*1024*1024];
DMAMEM char buf2[250 * 1024];
       char buf3[100 * 1024];

void setup(){
    while (!Serial) ;

    buf1[0] = 0; // need to access the buffers, will be optimized away otherwise
    buf2[0] = 0;
    buf3[0] = 0;
}

void loop() {}

Would be interesting to compare your results to the linker results. How do I call your program?

Edit: Ah, I see, it expects the .elf on stdin

Neal · Feb 5, 2021

Your post is a few months old, but I have two questions:
1. Can you point me to a link that documents the -Wl,--print-memory-usage option?
2. How did the output it generated compare to the output KurtE was getting?

Thanks

defragster · Feb 5, 2021

Neal said:
Your post is a few months old, but I have two questions:
1. Can you point me to a link that documents the -Wl,--print-memory-usage option?
2. How did the output it generated compare to the output KurtE was getting?

Thanks

Did a forum search for "print-memory" - picked top thread and (after this one) then did a search in that thread to find ::

pjrc.com/threads/64592-Teensyduino-1-54-Beta-5

The output is same/similar. It adds one more section on extram IIRC. There may be notes on the linked post/thread above

AndyUK · Sep 5, 2022

Frank B said:
Edit:

Ok, new try rename linkerfile above to imxrt1062f.ld

FASTRUN works. The pervious version from an hour ago had a problem with the calculated number of ITCM blocks. This is fixed.
Edit:
The attached file in #138 allows FASTRUN, but allocates at least one block ITCM.
The version from POST #131 ignores FASTRUN and puts everything into the flash.

Hi, I thought this was the best place to ask for assistance as it is where I found a solution to moving all code to Flash when I had an issue back in December 21.
I have been successfully using the Teensy 4.0 Flash, helpfully provide by Frank B, with Teensyduino 1.53.
The project I am working on required a Teensyduino update to 1.57 , so I could make use of SPI1 and SPI2.
Having updated to 1.57 the Tools>Boards>Teensy 4.0 Flash selection has gone and linker imxrt1062f.id is not suitable for 1.57.
I have updated the build file in 1.57 to include the required teensy40flash0.name=Teensy 4.0 Flash, etc and this works and shows the Teensy 4.0 Flash as an option.
I am unable to modify the 1.57 imxrt1062.id, as I do not possess the necessary knowledge to put all code into Flash as the previous imxrt1062f.id file did.
I wonder if Frank B or someone could help out?
Really hope so, as I have a 10,000 line sketch which I have been working on.
Thanks in advance.

KurtE · Sep 5, 2022

AndyUK said:
Hi, I thought this was the best place to ask for assistance as it is where I found a solution to moving all code to Flash when I had an issue back in December 21.
I have been successfully using the Teensy 4.0 Flash, helpfully provide by Frank B, with Teensyduino 1.53.
The project I am working on required a Teensyduino update to 1.57 , so I could make use of SPI1 and SPI2.
Having updated to 1.57 the Tools>Boards>Teensy 4.0 Flash selection has gone and linker imxrt1062f.id is not suitable for 1.57.
I have updated the build file in 1.57 to include the required teensy40flash0.name=Teensy 4.0 Flash, etc and this works and shows the Teensy 4.0 Flash as an option.
I am unable to modify the 1.57 imxrt1062.id, as I do not possess the necessary knowledge to put all code into Flash as the previous imxrt1062f.id file did.
I wonder if Frank B or someone could help out?
Really hope so, as I have a 10,000 line sketch which I have been working on.
Thanks in advance.

Actually you may want to break this out as it's own thread, as there are probably only a few people who have played with this type of loader scripts and the like

T4.0 Memory - trying to make sense of the different regions

Well-known member

Senior Member

Well-known member

Well-known member

Senior Member+

Well-known member

Senior Member+

Well-known member

Well-known member

Senior Member

Senior Member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Senior Member+

Senior Member+

Well-known member

Senior Member+

Well-known member

Well-known member

Senior Member+

Member

Senior Member+