RT1170 EVK FLexRAM allocation

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

RT1170 EVK FLexRAM allocation

1,924 Views
dloub
Contributor I

Good day all.

It is my first time configuring FlexRAM. I am trying to change the FlexRAM memory allocation on the RT1170EVK board. I have followed the steps from the NXP post Reallocating the FlexRAM - NXP Community and the application note "Using the i.MX RT FlexRAM Rev 3". I would like to only use SRAM_DTC, i.e. 512kB DTCM and 0kB ITCM and 0kB OCRAM.

I have modified the following registers at their corresponding addresses (obtained from the i.MX RT1170 Processor Reference Manual Rev 1):

IOMUXC_GPR_GPR16 - 0x400E4040

IOMUXC_GPR_GPR16 - 0x400E4044

IOMUXC_GPR_GPR16 - 0x400E4048

I edited the ResetISR(void) function in 'startup_mimxrt1176_cm7.c" to be:

dloub_0-1624258916845.png

I replaced 'IMAGE_ENTRY_ADDRESS' in 'fsl_flexspi_nor_boot.c' with '(uint32_t)ResetISR' as per the instructions:

dloub_1-1624259041774.png

This resulted in a mupltiple definitions error, therefore I had to comment out 'extern uint32_t ResetISR[];' in 'fsl_flexspi_nor_boot.h':

dloub_6-1624259816175.png

I changed the linkerscript to correspond to the new DTC size:

dloub_2-1624259101885.png

And in board.c I modified the MPU (BOARD_ConfigMPU) to match the new memory sizes (based on the assumption that region 4 is the ITC and region 5 is the DTC):

dloub_3-1624259210934.png

With this configuration and modifications my project compiles fine:

dloub_4-1624259285519.png

But when debugging, my program just stalls and never offers the 'play' option:

dloub_5-1624259459384.png

What am I doing wrong?

Labels (1)
Tags (2)
0 Kudos
9 Replies

1,836 Views
dloub
Contributor I

Thank you for the responses.

I have tried all the above suggestions. It seems that moving the stack pointer to the start of the DTCM memory solved the problem. However, a new problem now is that I cannot debug the board more than once during its power cycle, i.e if I am doing the following it works: build  -> debug (this works) -> terminate debug session, build -> debug -> error window. I then need to switch the board on and off to get this error window to dissapear: build -> debug ->  terminate debug session -> switch board off -> switch board on -> build -> debug -> works.

Pressing the reset button between debug sessions did seem to rid me of turning the board on and off again, but only for single core projects. When I try to do a multicore example, such as the rpmsg_lite_pingpong_rtos example, and I use the above flexram configurtation, the 'reset' or 'turn-off and off' method does not solve a problem since a new error window occurs:

Screenshot.png

 This error can only be fixed if I mass erase the board using the GUI flash tool. Clearly there is a bigger underlying problem here. Especially the flexram configuration of the M7 calling the M4.

Thank you for your responses and assistance so far.

0 Kudos

1,811 Views
victorjimenez
NXP TechSupport
NXP TechSupport

Hello John, 

I made some tests on my end, and I wasn't able to replicate the behavior that you mentioned. So, this has nothing to do with the reconfiguration of the FlexRAM through software. In the past when I have seen this type of behavior is normally because of a misconfiguration of a clock or because the application is trying to access an address of the memory that doesn't exist. 

Regards,
Victor 

0 Kudos

1,806 Views
johnvanmaanen
Contributor I

Hello Victor,

 

Thank you for your time. We will look into it further. It is strange that we have the problems with a demo project, where we only change the FlexRAM configuration. Did you work on the document about configuring the FlexRAM on the RT 1176?

 

Kind regards,

 

John

0 Kudos

1,761 Views
victorjimenez
NXP TechSupport
NXP TechSupport

Hello John, 

I'm working on making the proper changes in my community document. Are you still facing the same behavior? If you make these changes in a non-multi-core project, do you face the same behavior? 

Regards,
Victor 

0 Kudos

1,887 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi @dloub ,

   Please check this application note at first:

https://www.nxp.com/docs/en/application-note/AN12077.pdf

The minimum configuration of OCRAM is 64 KB (see Table 1). This is required due to ROM code requires at least 64 KB of RAM for its
execution. The minimum OCRAM requirements can be device dependent.

So your :only use SRAM_DTC, i.e. 512kB DTCM and 0kB ITCM and 0kB OCRAM.

It is not supported.

Please choose other configuration, please also note:

The Arm Cortex-M7 specifications require the size of ITCM/DTCM to be a power-of-two number, which can conflict with the FlexRAM
configuration capability (see configurations 7, 10, 11 in Table 1).

 

Wish it helps you!

Kerry

0 Kudos

1,880 Views
johnvanmaanen
Contributor I

Hello @kerryzhou ,

 

The RT 1176 always has OCRAM besides the flexram. Default configuration of the flexram is 256kB DTCM, 256kB ITCM and 0kB OCRAM. Is there more information specific to the RT 1176, because the process described in AN12077 if not working for us.

 

Kind regards,

John

 

0 Kudos

1,846 Views
victorjimenez
NXP TechSupport
NXP TechSupport

Hello John, 

I was discussing this internally with Kerry, and there are other things to take into consideration. Keep in mind that the community document was made for the RT10xx parts. The steps for the RT1170 are not the same. 

In the RT1170, you don't need to modify the file fsl_flexspi_nor_boot.c. Please delete the line of code where you declared the ResetISR as extern and uncomment the line on fsl_flexspi_nor_boot.h. This step only applies to the RT10xx parts. 

You also need to reallocate the stack pointer.  As I mentioned in the community document, there are lots of dangerous areas in reconfiguring the FlexRAM in code. It pretty much all boils down to the fact that any code/data/stack information written to the RAM can end up changing location during the reallocation. To overcome this you'll need to place the stack at the start of the DTCM memory and change the size. This applies to all the RT parts. I'm working on updating the community document to add this information. 

victorjimenez_0-1624557596640.png

After doing this you also have to add a couple of instructions inside the reset handler to reallocate the SP. Here are all the instructions that you need. 

    /* Reallocating the FlexRAM */
    __asm (".syntax unified\n"

    		"LDR R0, =0x20001fff\n" //Reallocating the stack pointer
    		"MSR MSP,R0\n"

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

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

    		"LDR R0,=0x400e4040\n"//Address of register IOMUXC_GPR_GPR16
    		"LDR R1,[R0]\n"
    		"ORR R1,R1,#4\n"//The 4 corresponds to setting the FLEXRAM_BANK_CFG_SEL bit in register IOMUXC_GPR_GPR16
    		"STR R1,[R0]\n"

    ".syntax divided\n");

    __asm volatile ("MSR MSP, %0" : : "r" (&_vStackTop) : );

You need to add these instructions right after disabling the interrupts inside the ResetISR. 

As Kerry mentioned to you already, you also need to modify the connect script to match the new value of the FlexRAM. I will add this in the community document as well since this applies to all the RT parts. 

The changes that you made in the MCU settings and the MPU are correct. I made some tests on my end, and I was able to debug this without problems. 

Regards,
Victor 

0 Kudos

1,875 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Thanks for your nitification!

Another factor: flashloader .cfx put in the memory whichyou have disabled!

   Please don't worry, tomorrow, I will test your situation on my side directly, then give you feedback!

 

Please keep patient!

Best Regards,

Kerry

0 Kudos

1,562 Views
johnvanmaanen
Contributor I

Hello Kerry,

It's been a while since your last message. As we only changed the size of the memory after flashing (from our own code), we didn't have problems with flashing. Up to now. 

We used the eFuses to reconfigure the memory now and are not able to program the flash anymore. You mentioned that the flashloader uses ITC. Do you have more information about this? Is there a way to program the fuses for 512kB DTC and stil being able to program the flash memory?

Kind regards,

 

John

 

John

0 Kudos