Reallocating the FlexRAM - Reset vector does not work

[kl]

Hi

I have followed the guide on:

https://community.nxp.com/t5/i-MX-RT-Knowledge-Base/Reallocating-the-FlexRAM/ta-p/1117649

And read a lot of post on this forum. But I can still not find anyone with a problem like the one I got.

I got a custom board with a RT1064DVL6. Using a J-link debugger on the SWD I/F. Boot config is configured by external resistors to boot on internal flash.

I want to maximize the amount of DTCM, and just a little ITCM and no extra OCM.

The fist attempt worked 100%. I committed the code, and the next day nothing worked. I verified the memory areas in the debugger, and all was OK. At that time I did NOT change the reference in XIP to ResetISR(). But it still worked.

The symptoms are following: The code does not run to main when debugging. When asking the debugger not to run to main, it does not start at ResetISR() as normal. If I look at the PC it reads something like 0x21aac8 (Part of the ROM code?)

If I manually change the PC to 0x70002350 = ResetISR, the application starts and runs perfectly.

If I compare the first 0x2000 bytes in the hexfile from a working application with the faulty one, it only differs on the changed reference to ResetISR() in the image_vector_table.

I can reload a backup of the memory layout to the project file, and the debugger runs perfectly to main().

Any hints?

Question: It seems odd to change the reference in image_vector_table from a pointer to an array (g_pfnVectors) to a pointer to a function. And why does the changed memory layout for the FlexRAM needs this change? If I omit this change the code end up in a really bad state where all the CPU registers is "0xdeadbeef". Today!!! but not yesterday as described at the top.

Regards Kasper

[victorjimenez]

Hello Kasper, 

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. You've happened upon the other danger with pointing the stack into RAM locations that are moving and/or invalid. This is why you need to change the entry address of the image. At the end of the community document, I mentioned that this is not needed when you reallocate the FlexRAM through the fuses. This is why we recommend that once you find the proper configuration you apply it through the fuses. 

Regarding the stack, you are right. The stack is placed at the end of the DTCM, but since you are increasing the DTCM, this might cause some problems. To prevent this from happening, you will need to place the stack at the beginning of the DTCM. 

I will add this information to the community document within the next days. 

Regards,
Victor 

[kl · Accepted solution]

I might have found something.

As I wrote, I want to maximize the amount of DTCM. 

BUT, the stack is defined to be in the top of DTCM.

I have tried to set a break point at the reset vector at the beginning of ResetISR(). At it seems that (in default memory configuration) the stack has already been used at this point.

0x2001FFE0 00000000 00000000 00000000 00000000 00000000 00000000 70002000 00215329
0x20020000 ??????FF ???????? ???????? ???????? ???????? ???????? ???????? ????????

By the way, I think I found one of the problems. In the  "fsl_flexspi_nor_boot.c" file I had placed the prototype for ResetISR() after the section attribute. I cannot figure out why it compiles differently, but the image_vector_table[] was not correct.

I will continue testing.

[crist_xu]

Hi,

    I think that, if you set the ResetISR() to this stuct: image_vector_table, rom will directly set the PC to the ReserISR, but without setting the stack, so you need to set the SP in the ResetISR function. But if you set set Vector_table's adress, the rom will help to set the SP and PC both, so that you will not need to configure the SP in your code.

Regards,

    Crist