i.MX RT1024 FlexRAM modify size issue

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX RT1024 FlexRAM modify size issue

Jump to solution
954 Views
Felix_ar
Contributor III

Hi All,

Hardware: MIMXRT1024-EVK

Software: SDK2.13

My customer follow this post https://community.nxp.com/t5/i-MX-RT-Knowledge-Base/Reallocating-the-FlexRAM/ta-p/1117649 modify FlexRAM size, but after modification the board can't boot up.

default  "OCRAM 128KB, SRAM_DTC 64KB, SRA_ITC 64KB"

change to "OCRAM 64KB, SRAM_DTC 128 KB,  SRA_ITC 64KB"

attached file is all project, please give some advice.

thanks.

Labels (1)
0 Kudos
Reply
1 Solution
889 Views
Felix_ar
Contributor III

Hi Mark

I had found a solution, thank you reply.

View solution in original post

Tags (1)
0 Kudos
Reply
3 Replies
933 Views
mjbcswitzerland
Specialist V

Hi

I also just checked your code:

#if 1
"LDR R0,=0x20001fff\n" //load initial value of stack pointer into R0
"MSR MSP,R0\n"//re-initialize stack pointer by new value
#endif

"LDR R0, =0x400ac044\n"//Address of register IOMUXC_GPR_GPR17
"LDR R1, =0xfaa5\n"//FlexRAM configuration DTC = 265KB, ITC = 128KB, OC = 128KB
"STR R1,[R0]\n"


The comments are incorrect and should be
"LDR R1, =0xfaa5\n"//FlexRAM configuration DTC = 128KB [2,3,4,5], ITC = 64KB [6,7], OC = 64KB [0, 1]

Since it is setting the stack pointer at 128k into the DTC, which will be OK after the FlexRAM change I see no problems (as the code is in assembler and there are no interrupts).


#if 1
"LDR R0, =0x400ac038\n"//Address of register IOMUXC_GPR_GPR14
"LDR R1, =0x980000\n"//New size configuration for the IOMUXC_GPR_GPR14 register
"STR R1,[R0]\n"
#endif

should however be


"LDR R1, =0x870000\n"//New size configuration for the IOMUXC_GPR_GPR14 register [128k DTC / 64k ITC]

although I don't know that it will be an actual issue.

If it isn't that it will more likely be that the following code tries to use a no longer existing bank in RAM so check that the linker scrip reflects the layout and it doesn't try to put variables (or heap) into non-existent banks.
I expect that the debugger will be able to break after the FlexRAM reconfiguration and then you can step to see where it subsequently fails.

Regards

Mark

0 Kudos
Reply
937 Views
mjbcswitzerland
Specialist V

Hi

Check where the stack pointer is set to and that the code used to modify the FlexRAM doesn't cause the location of the stack to move to a different address (if the modification is performed without the use of stack it can also be followed by additional code (that doesn't use the stack) to set the stack pointer to the new location in DTC.

Note that, since exactly how instruction code works (with or without stack) may be compiler version dependent and such things can start failing when the optimisation is changed or a new compiler version is used. To avoid this it is a good idea to ensure the code segment is forced to make use of internal registers and not stack variables and optimisation, in-lining, etc. disabled.

See also chapter 17 of  https://www.utasker.com/docs/iMX/i.MX_RT_1024_uTasker.pdf for a method of effecting FlexRAM changes on-the-fly while retaining stack content or use the uTasker boot loader with the project, which will configure the FlexRAM on-the-fly to suit the application.

Regards

Mark


RT1024 pin-muxspread sheet: https://www.utasker.com/iMX/iMXRT1024/iMX_RT_1024.xls

For our discounted i.MX and Kinetis production stock availability see https://www.utasker.com/Shop/semi.html

0 Kudos
Reply
890 Views
Felix_ar
Contributor III

Hi Mark

I had found a solution, thank you reply.

Tags (1)
0 Kudos
Reply