How to modify the default ITCM/DTCM/OCRAM memory allocations for i.MX RT1064

[alin_butoi]

Hello,

   Our team is using the i.MX RT1064 microprocessor to develop an application that will likely exceed the 128KB ITCM memory size allocated by default. We have read through AN12077 and informed ourselves about the static and runtime configuration options using the Flexram, and at this point in the development we would like to understand more about how to partition the memory banks using the fuse settings.

What is the recommended method for modifying the default static RAM configuration? From what I understand, writing to the fuse settings during manufacturing time is best? Otherwise, are there any other methods that do not require this extra step of modifying fuse settings?

Thank you in advance,

Alin

[victorjimenez]

Hi Alin, 

Thanks for the additional information! 

The RT1064 has 1MB of on-chip RAM. 512KB out of the 1MB are shared between OCRAM, ITC and DTC. The other half of the on-chip memory is OCRAM and this cannot be changed. The default configuration of the shared 512KB is 128 DTC, 128 ITC and 128 OCRAM.

The correct way to reallocate the FlexRAM is in the startup code before the FlexRAM is initialized. To do this you need to add some assembler code into the Reset_Hanlder located in the file startup_MIMXRT1064.s. Please see the below code. This code reallocates the 512KB shared RAM to be all DTC memory. 

LDR     R0, =0x400ac044
LDR     R1, =0xaaaaaaaa
STR     R1,[R0]
LDR     R0,=0x400ac040
LDR     R1,=0x04
LDR     R3,[R0]
ORR     R2,R1,R3
STR     R2,[R0]‍‍‍‍‍‍‍‍

Additional to this you will need to modify your memory configuration file to match the new configuration of the FlexRAM.  

I hope it helps! 

Victor 

[D_TTSA]

Hello Victor (@victorjimenez)

I would like to do something similar to what you suggest here - to increase the size of DTC. I am also using the RT1064, and developing in MCUXpresso.

I wanted to know where I can find the startup_MIMXRT1064.s file? It doesn't seem to be in the project folder... does MCUXpresso do this in a different manner?

I did find the fsl_flexspi_nor_boot.c file you refer to in one of your comments on this thread.

Note: I am relatively new to embedded systems, so this is quite an advanced topic for me.

[alin_butoi]

Hi Victor,

I really appreciate the help with this issue. I did implement the assembly code you provided but I made some small modifications to it. Instead of reallocating 512kB to DTCM, I partitioned the FlexRam memory to allocate 256kB to ITCM, 192kB to DTCM, and 64kB to OCRAM. I could not find an option that allowed DTCM to be set to 512kB in the FlexRam app note (AN12077). Could you possibly elaborate a little on how you discovered that setting? I also made some changes in the linker file to accommodate for the new memory partitioning. I am attaching images of those changes for your reference.

Below see the assembly code addition in startup_MIMXRT1064.s:

Below see the Linker modifications: 

I am currently encountering a debugger warning at runtime, which suggests a fail to read memory starting with address 0x00020000. I also attached the debug log for reference.

Please advise at your earliest convenience!

Alin

[victorjimenez]

Hi Alin Butoi, 

Sorry for that, I forgot to mention another change that has to be made. In the xip folder of your project you will find a file named fsl_flexspi_nor_boot.c. Within this file you have the declaration of the IVT. The second parameter of the IVT is the image entry address, you need to change this to the Reset_Handler. You also need to declare as an extern the Reset_Handler in this file. See the below image for reference. 

 

Let me know your results! 

Best Regards, 

Victor 

[alin_butoi]

Hi Victor,

I implemented the additional changes to the fsl_flexspi_nor.c file, and also moved the assembly code within the Reset_Handler that configures the FlexRam (ITCM 256kB, DTCM 192kB, and OCRAM 64kB) to the section where the interrupts are disabled as suggested by AN12077.

Checking the .map file generated at run time, I see that 262142 bytes are placed in read only memory (text + data) which is 2 bytes short of the 262144 bytes representing 256kB. If I increase the size of data placed in read only memory beyond that, I get a linker error - which expect since this would try to allocate data past the boundary of ITCM. This shows that the ITCM memory was successfully expanded from the default 128kB to 256kB.

As I mentioned in an earlier post, I have fairly limited experience on this topic, so I would like to understand how this method of re-configuring the RAM is successful. In particular, can you explain where in the boot sequence the re-configuring of the RAM memory via the FlexRam process occurs? More concisely, when a runtime reconfiguration of RAM is performed to accommodate for the the size of an app image that exceeds the default RAM memory allocated, where in the startup sequence is the code from startup_MIMXRT1064.s performed in relation to copying the image over from flash to RAM? Is the FlexRam reconfiguration occurring before the image is loaded into RAM? Please feel free to provide an abundance of detail here since I'm still trying to piece together an overall understanding of this start up process in general.

Another behavior that I noticed is the debugger warning that it failed to verify the memory starting with address 0x00020000 when I try to load the app into flash after a HW reset. This also prevents the app from running - PC never hits main() at runtime. I attached a debug log in my previous post about that issue and mjbcswitzerland suggested that is an IAR bug with certain chips. I would like to get a better understanding about this behavior if anyone has had similar experiences before I reach out to IAR with the issue.

Why does a HW reset cause the debugger to be unable to verify the RAM memory in the RT1064 - rendering it inaccessible once the FlexRam default config has been modified? 

FYI: If I reconfigure the RAM as you described in previous posts without a HW reset, the memory re-allocation is successful and the app runs (as described in the beginning of this post).

Thank you for your continued support!

Regards,

Alin

[victorjimenez]

Hello Alin, 

Can you explain where in the boot sequence the re-configuring of the RAM memory via the FlexRam process occurs?

In the way that I explained here reallocating the FlexRAM is done in the Reset Handler. The Reset Handler is the entry address of your application so this is done directly by your application. The ROM bootloader has nothing to do with this example. 

Why does a HW reset cause the debugger to be unable to verify the RAM memory in the RT1064 - rendering it inaccessible once the FlexRam default config has been modified? 

Keep in mind that the Hardware Reset (or POR as we called it in the RM), does reset to its default values the IOMUXC registers. On the other hand, the software reset (or COLD as we called it in the RM) does not reset the IOMUXC registers. This is explained in section 21.7.1.1 of the RM. 

Regards, 

Victor 

[alin_butoi]

Hi Victor,

We are revisiting the runtime configuration of the RAM memory for the RT1064 using FlexRAM, and we are having issues running our application consistently on the evaluation hardware MIMXRT1064-EVK. As previously, our goal is to modify the memory allocations as follows: ITCM to 256kB, DTCM to 192kB, and OCRAM to 64kB. In order to stress the ITCM allocation, we are using the version of the HelloWorld app provided with SDK_2.7.0_EVK-MIMXRT1064 which we modified to include a test array of size 0x3C64C or 247372 bytes in read only memory:

Based on your previous suggestions and also consulting AN12077, we made the following changes in startup_MIMXRT1064.s:

The linker file MIMXRT1064xxxxx_ram.icf provided with the SDK was modified in the following way to allow for the new memory boundaries:

fsl_flexspi_nor_boot.c was modified to reflect the Reset_Handler as the image entry point:

We are using IAR Embedded Workbench ver 8.40 as our development environment and we are using a Segger J-Trace debugger to download and debug the application. After power up, the application builds without any linker errors but it does not reach main(). When we stop the execution, the disassembly window shows the following: 

We have had intermittent success building and running the application with the dynamic RAM configuration in the past, but it unclear to us what causes it to run normal at times and not others. Sometimes the application runs to main() if we simply rebuild and download - unless we cycle power in which case it behaves as described above. Your comments and suggestions are much appreciated.

Regards,

Alin

[mjbcswitzerland]

Alin

To configure for 512k DTC (16 banks in DTC and 0 in ITC) the settings are:

IOMUXC_GPR_GPR14 = 0x00a00000; (but not sensitive - can also be 0x00aa0000)

IOMUXC_GPR_GPR17 = 0xaaaaaaaa;
IOMUXC_GPR_GPR16 = 0x00200006;

IAR has some bugs viewing memory on certain chips. For example it can't view OCR2 on the 1064. It also makes mistakes on others when flexRAM values are changed - it shows the memory area as inaccessible but it can be used. Once just can't follow the values in the RAM directly and one has to just accept that they are there (and maybe monitor values read into registers during disassembly debugging to check details about their values). If you are a good IAR customer they may listen to you and put it right if you complain about the bugs to them.

Regards

Mark

[uTasker project developer for Kinetis and i.MX RT]

[alin_butoi]

Thank you for the help! I will try this out and report back.

[alin_butoi]

Thank you, Markus for your input!

I was unaware of the SystemInitHook function and how it can be used in the boot up procedure. I am still learning about the boot up process of this microprocessor, and in general really.

I did read in AN12077 about the two configurations but I am not sure how to modify the SystemInitHook function to leverage it for the runtime option. Could you elaborate a little more on what you suggest should be done inside of this function? 

[victorjimenez]

Hello Alin, 

Regarding your question please see my comment below.  

What is the recommended method for modifying the default static RAM configuration? From what I understand, writing to the fuse settings during manufacturing time is best? Otherwise, are there any other methods that do not require this extra step of modifying fuse settings?

Burning the fuses is a good approach. However, since this cannot be undone a lot of people don't like this method. The other approach is to reallocate the FlexRAM at the startup. Please tell me which IDE you are using and I can share with you some example code that demonstrates how to do this. 

Regards, 

Victor 

[alin_butoi]

Hi Victor,

I am currently using IAR.   

Thanks,

Alin        

[mjbcswitzerland]

Hi

The uTasker project has an integrated solution whereby its boot loader automatically configures application's ITC and DTC RAM requirements.
More details in other posts:
- https://community.nxp.com/thread/530184#comment-1302432
- https://community.nxp.com/thread/523554#comment-1301497

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]

- https://www.utasker.com/iMX/RT1064.html

[Masmiseim]

Hello Alin,

you could overload the weak SystemInitHook Function. This function is called during startup (compare system_MIMXRT1060.c).

This function is intended to use for initialization of the memory, for example the external memory interface, bevor the initialization of the memory segments (.data, .bss, …) is started. You can also use it to reconfigure the TCM.

How this is done is described in AN12077. Don’t forget to adapt also the linker file to the new changed sizes.

This has the advantage that you don’t have to change the fuses. You can change the partitioning with any software update

Best Regards