memory area that I should not access(tennsy4.0)

Status
Not open for further replies.
Hello everybody. I am a Japanese hobby programmer. I am having fun with two Teensy4.0.

Please tell me about the "memory area that I should not access" in T4. Is there an area where execution of the program is stopped just by accessing it?

From the figures I have and the logs of this forum, I interpret the rough memory map of T4 as follows.

https://www.pjrc.com/store/teensy40.html

FLASH:
0x0000: 0000-2MB
RAM1:
0x2000: 0000-512KB-0x2000: 2007: ffff
RAM2:
0x2020: 0000-512KB-0x2027: ffff

I wrote the following program to see the data actually stored.

void loop() {
// put your main code here, to run repeatedly:
const char *ptr = (const char *)0x2007f000;
Serial.println(*ptr, HEX);
delay(1000);
}

However, if the address given to read RAM1 is 0x2007f000, this program will lock. If it is 0x2006f000, 0xD7 was read normally.

I would be glad if I could give some advice to me.

(Mac mini / macOSⅩ Catalina / teensyduino 1.50)
 
Looking at file from TeensyDuino install :: ...\hardware\teensy\avr\cores\teensy4\imxrt1062.ld

Will show this snippet for addresses to start with:
Code:
MEMORY
{
	ITCM (rwx):  ORIGIN = 0x00000000, LENGTH = 512K
	DTCM (rwx):  ORIGIN = 0x20000000, LENGTH = 512K
	RAM (rwx):   ORIGIN = 0x20200000, LENGTH = 512K
	FLASH (rwx): ORIGIN = 0x60000000, LENGTH = 1984K
}

There is more to the ITCM and DTCM split - some added details might come from this page's "Memory Layout" section :: pjrc.com/store/teensy40.html

Those pieces come together in ...\hardware\teensy\avr\cores\teensy4\startup.c :: void ResetHandler(void)
 
Maybe the "Memory Layout" info on the product page can help?

https://www.pjrc.com/store/teensy40.html

In particular, this diagram:

teensy4_memory.png


The RAM1 memory is divided into ITCM (starting at 00000000) and DTCM (starting at 20000000). How much is allocated to ITCM depends on your code size. The rest is DTCM.

Your program is able to read at 2006F000 only because a small amount of the RAM1 512K was allocated as ITCM. If you write more code (and do not use FLASHMEM or PROGMEM, as described in Memory Layout), the DTCM memory will be smaller because more of the 512K will be allocated at ITCM.

If you are accustomed to memory being allocated in fixed amounts at fixed locations, this advanced hardware with configurable memory (in 32K size pieces) can be seem strange. But it is the amazing time we live in today, where an inexpensive microcontroller runs at 600 MHz dual-issue architecture, and has advanced features like hardware reconfigurable memory!
 
Thanks to defragster and Paul for their comments.

I was delighted by the number "2006F000" in Paul's comment. Because it was consistent with the numbers I wrote in my own post. Along with the code sample presented by defragster, I was able to understand what was happening on T4.

Paul, check the meaning of your text below just in case.

> Your program is able to read at 2006F000 only because a small amount of the RAM1 512K was allocated as ITCM.

I interpret it as follows, is it correct?

> Your program can only read up to 2006F000 because a small amount of RAM1 512K was allocated as ITCM.

I also understand that this value changes depending on the situation. I would be even more glad if there was a way (symbol) to know this value while my program was running.

--- *

I bought a T4 micro supercomputer and wrote a little FORTH compiler that I had conceived for some time. I wanted to save the time of writing and compiling source code and writing to T4 every time to play with T4. Because FORTH has an interpreter.

Although this attempt was successful, T4 often locks. This phenomenon was discovered while investigating the cause. Maybe this lock is caused by memory access to an area that is not allowed. I thought so.

Of course, such unauthorized access is due to my program mistake. I am considering measures for myself. Although not perfect.

--- *

Thanks to everyone. Not only for developing T4, but also for answering my questions.
 
The indicated .ld file show names that are usable at runtime to find boundaries and areas on the RAM.

This code for instance generally {AFAIK :)} finds the area of RAM allocated to instruction area ITCM that is unused. The ITCM holds all code that runs from RAM - and that is reserved in 32KB chunks as needed - where this code finds the area above the last used code element:
Code:
#if defined(__IMXRT1062__) // Get Pointer to FREE ITCM
uint32_t *ptrFreeITCM;  // Set to Usable ITCM free RAM
uint32_t  sizeofFreeITCM; // sizeof free RAM in uint32_t units.
uint32_t  SizeLeft_etext;
FLASHMEM
void   getFreeITCM() { // end of CODE ITCM, skip full 32 bits
  extern unsigned long _stext;
  extern unsigned long _etext;
  SizeLeft_etext = (32 * 1024) - (((uint32_t)&_etext - (uint32_t)&_stext) % (32 * 1024));
  sizeofFreeITCM = SizeLeft_etext - 4;
  sizeofFreeITCM /= sizeof(ptrFreeITCM[0]);
  ptrFreeITCM = (uint32_t *) ( (uint32_t)&_stext + (uint32_t)&_etext + 4 );
  Serial.printf( "Size of Free ITCM in Bytes = %u\n", sizeofFreeITCM*sizeof(ptrFreeITCM[0]) );
  Serial.printf( "Start of Free ITCM = %u [%X] \n", ptrFreeITCM, ptrFreeITCM);
  Serial.printf( "End of Free ITCM = %u [%X] \n", ptrFreeITCM + sizeofFreeITCM, ptrFreeITCM + sizeofFreeITCM);
}
#else
void   getFreeITCM() {}
#endif

It likely doesn't apply directly to intended use - but will demo the use of the compile/link names showing how much CODE is used - and how much then is reserved in the DTCM area.

This and similar values are used in the p#2 ResetHandler code indicated.

Code cannot execute from RAM2 - the DMAMEM area - but since this is an interpreter - that 'script' source could be placed and pulled from there - though unless it stays in the cache - access to that RAM2 area as noted on PJRC page runs at F_CPU/4.

Forum search for imxrt-size or flexRamInfo should find other posts on T_4 memory.

imxrt-size examines a compile time file for general allocation information like this about the sketch just built:
Code:
FlexRAM section ITCM+DTCM = 512 KB
    Config : aaaaaaab
    ITCM :  24176 B	(73.78% of   32 KB)
    DTCM :  12992 B	( 2.64% of  480 KB)
    Available for Stack: 478528
OCRAM: 512KB
    DMAMEM:  12384 B	( 2.36% of  512 KB)
    Available for Heap: 511904 B	(97.64% of  512 KB)
Flash:  34768 B	( 1.71% of 1984 KB)

The library with flexRamInfo() does it at runtime with similar more active results on what is used where.
 
Status
Not open for further replies.
Back
Top