Increase default SRAM_DTC size on RT1064

[D_TTSA]

Good day

I would like to increase the size of the SRAM_DTC in my MCUXpresso project. I am using NXP's RT1064 EVK. 

The reason I would like to increase this is because I get the following error when compiling my code: "region SRAM_DTC overflowed by 13664 bytes". I believe my stack is too large to fit into the default 128kB that is allocated for DTC.

After some searching, I found this post https://community.nxp.com/t5/i-MX-RT/How-to-modify-the-default-ITCM-DTCM-OCRAM-memory-allocations-fo... . However, I am new to embedded systems, so this is a very advanced topic for me. I also tried reading the application note AN12077 (Using the i.MX RT FlexRAM), but I don't understand the 'demonstration' part, so this wasn't particularly helpful.

From the above reading, I learned that the FlexRAM consists of 16 banks of 32kB. By default, 8 banks are for OCRAM and both ITC and DTC get 4 banks. I was thinking I could simply re-allocate one of the banks from ITC to DTC, so that my project's stack would not overflow (5 banks for DTC and 3 for ITC). However, I'm not sure if I can simply do this - is ITC and DTC memory exactly the same apart from their software configuration? Or do they differ in their hardware?

I tried looking at the evkmimxrt1064_flexram_ram_allocate SDK example, but it seems this is more for using the OCRAM. I know I *can* use the OCRAM, but I also know it is slower than the TC memories (from AN12077). My project is a real-time application, so I would like to avoid slower accesses as far as possible.

Could someone please explain to me how I can increase the size of the SRAM_DTC? I tried increasing the size in Project properties -> C/C++ Build -> MCU Settings, but this only 'fixes' the linking error and causes a hard fault when I try to debug the program. 

Thank you in advance.

[jeremyzhou · Accepted solution]

Hi,
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
To provide the fastest possible support, I'd highly recommend you to refer to the post: https://community.nxp.com/t5/i-MX-RT-Knowledge-Base/Reallocating-the-FlexRAM/ta-p/1117649
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[D_TTSA]

Thank you very much @jeremyzhou!

I followed the guide and it worked perfectly.

However, I have another question on this topic. At the end of the article, the author says it is highly recommended to "burn the fuses" to configure the RAM. I'm not sure what this means? Where can I find out more about fuse burning and FlexRAM and how this fits together?

Kind regards

[jeremyzhou]

Hi，
Thanks for your reply.
1) I'm not sure what this means? Where can I find out more about fuse burning and FlexRAM and how this fits together?
-- We can reconfigure the FlexRAM via not only setting GPR_GPR17, GPR_GPR14, GPR_GPRT16 registers but also burning value to 0xD0[19:16] in fuse map, just like below table shows.

Once you burn the value in the fuse map, it can't recover, in another word, the reconfigure FlexRAM will keep the same permanently.
So during the developing phase, you'd better not use burn fuse way to reconfigure the FlexRAM.
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[mjbcswitzerland]

Hi

Beware that if you burn fuses the values can't be changed again. There are more flexible methods to achieve the same.

Regards

Mark

[D_TTSA]

Hi Mark

Thank you for your warning! I am aware of this, but according to the aforementioned article, it is better to do so, as setting the FlexRAM in software has certain risks associated with it?

Could you perhaps provide your opinion on this?

Kind regards

[mjbcswitzerland]

Hi

It is correct that there is an additional risk involved in changing FlexRAM layout on-the-fly and fixing the layout via eFUSES possibly avoids this. However if they are fixed by eFUSE and you need to change the layout during the product's lifetime you have other problems - either you need to throw away the boards or use on-the-fly to override it (back to square one).

There are various other risks involved when using the i.MX RT - eg. if your application is in the process of erasing a sector in QSPI and there is a reset the board can't restart without a power cycle. Therefore solving a potential FlexRAM risk by locking eFUSEs is not going to result in a reliable product. For reliable product development an overall concept is needed whereby the FlexRAM risk itself is quite negligible and needs to be solved globally anyway.

The only way to achieve truly reliable i.MX RT based systems is by using a power-cycling external watchdog as typically used in automotive electronic systems and eFUSEs will not help in this respect.

Regards

Mark