FlexRAM Unexpected Behaviour

[briancarrigan]

I am having an issue with configuring and using the FlexRAM on the iMXRT1061. I desire to configure the block to 128KB OCRAM at the start, 128KB D-TCM next, and 256KB I-TCM at the top, meaning all banks are used. I have reviewed the AN12077 as well as the informational 1117649 on this forum. Both of these notes raise an issue with registers and register fields that are accessed but are not documented in the RT106x TRM. Specifically, the usage of IOMUXC_GPR14 and IOMUXC_GPR16 for disabling the I/D-TCM operations.

My problem has to do with FlexRAM operations. During my intial debug, the FlexRAM was behaving erratically at best. Once I had disabled the D-Cache, the problem became much more obvious. Specifically, any FlexRAM bank that is configured as OCRAM is fully functional, but any FlexRAM bank that is configured as I- / D-TCM only reads back value 0. (Or, perhaps it only writes value 0; it is difficult to tell which.) I verified that the FlexRAM memory it self was OK by setting all banks to OCRAM and testing them. I also experimented with FLEXRAM->TCM_CTRL to set the clock always on and to change the read/write to 2 clocks, but this had no apparent effect. it is also not really clear when it would be desired to use the 2-clk setting, if ever. I also verified that the FlexRAM clock was enabled from CCM->CCGR3 with CG9_MASK set. I also have this:

MPU->RBAR = ARM_MPU_RBAR(8, 0x20280000U); // FlexRAM-OCRAM
MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 0, 0, 1, 1, 0, ARM_MPU_REGION_SIZE_512KB);

My main question is what could be causing this non-responsiveness of the FlexRAM in TCM mode? If you could shed some light on this mystery, I would appreciate it.

[briancarrigan]

I have been deferring this issue while doing other software development. However, I have discovered that after I programmed the fuses, specifically the BT_BOOT_SEL and the SPIFLASH AUTO PROBE fuses only, then the issues with access to the FlexRAM resolved itself. This is unexpected, but may provide a clue to the underlying operation.

[briancarrigan]

Daniel, FYI, I ran that experiment whereby I pre-loaded the FlexRAM with data while in OCRAM mode, then switched to TCM mode, which involved only changing IOMUXC_GPR->GPR17 (with barriers before and after), then verified that the data read-back all-0. Then switched back to OCRAM mode again and verified that the data was still valid. This proves that the reading is being affected, and suggests that the writing may not be. -Brian

[DanielRuvalcaba]

If you set FlexRAM in another configuration, do you still have the same behavior? Could you please take a look to the following article and tell me if it works for you? https://community.nxp.com/t5/i-MX-RT-Knowledge-Base/Reallocating-the-FlexRAM/ta-p/1117649

[briancarrigan]

Daniel, As I mentioned in the original post, I did work through the forum article 1117649, but it doesn't really show any more illuminating information, except to emphasize the potential for problems if the FlexRAM is reconfigured while the software accesses it for stack or user space. In my application, the software stack and user space is all in OCRAM2, so there should be no interference.

[DanielRuvalcaba]

I took al look to your code and I it seems that you are making the FlexRAM configuration after the ResetISR, is this right? If this is the case, could you please try the configuration at the beginning of the RestISR?

If this still not working, could you please help me importing a new test project from the SDK (e.g. blinky or hello world) and follow these steps? This will make easier to us to track your steps and try to see if something is missing while allocating the FlexRAM.

• Please make the FlexRAM configuration (IOMUXC_GPR_GPR16 and IOMUXC_GPR_GPR17) directly in the ResetISR function and in assembly language as shown in the article I shared with you. Also, please write the direct value to the registers without macros.
• Please verify that you updated the linker with the new memory sizes.
• Verify that you modified correctly the Memory Protection Unit according to the size of your memories.
• Update the entry address of the Vector Table with the ResetISR.

As you might noticed, these are the same instructions as in the previous article, but I believe that in this way it might be easier to try to find a possible problem.

I tried these instructions in an RT1060-EVK and it seems to be working on my side.

Please let me know if this works for you.

[briancarrigan]

Daniel, I have attempted to import a simple example from the SDK (led blinky, in this case) but it refused to work on my board. There seems to be too many pieces that were either missing or different from the Eval board. To simplify things as much as possible, I have stripped out all of the code related to my application, with the exception of some GPIO, but have retained the MPU, Clock, LPUART1 (for console) and FlexRam. The entire program is contained within this attached ZIP file, with the exception of the standard CMSIS directory of include files, which need to be accessed for compilation. If you notice, I have moved the FlexRAM setup immediately after the "disable interrupts" line in the ResetISR. This had no effect on the outcome.

[DanielRuvalcaba]

There might be a hardware design issue, could you please help me verifying your hardware design ?.

In the code you shared with me, at least in the FlexRAM allocation configuration parts I saw, I didn’t find anything weird. I just didn’t find the update of the Vector Table and in my case, I have the modifications for regions 5, 6 and 7 in board.c. Also, I’m not sure that if the flow of your application can affect the configuration, that is why I asked you to try it in a hello_world or blinky project since in this way I can try it with a similar setup and discard a possible hardware problem. Just to let you know I tried it in the hello world project and I didn’t do any other modification that is not mentioned in the article, could you please try it like that as well? There is an attached file with the code of the startup function in the article that you can try.

I strongly recommend you to base your hardware design in the EVK. You can find it in here.

Best regards, Daniel.

[briancarrigan]

So I imported the "hello world" example and got it to run on my board. I had to change the linker memory to remove the SDRAM, which doesn't exist on my board, and to link all data to the OCRAM2 ($20208000) which is actually part-way through the OCRAM2 section. I then modified the setup for the FlexRAM and got exactly the same results as on my board. I moved the FlexRAM configuration lines, which is a very short piece of code, to various places in the application, with no difference in behaviour. I modified the MPU section to make the region encompassing FlexRAM be 512KB instead of 256KB. This also had no noticeable effect.

As for a hardware issue, it could be, but according to the illustration in TRM Figure 16-1, the FlexRAM and the M7 Core are on the same power rails. There is a schematic switch to FlexRAM which I believe to be the FUSE that shuts off the upper banks. There is another switch to CORE which may be to put the device in low power mode. I have not modified the power control registers in any way. The circuit to support the built-in switching regulator on my board was taken from the EVK schematic. In any case, the behaviour is not consistent with a power brown-out condition.

[DanielRuvalcaba]

Hi,

I´m sorry for the late reply.

Could you please help me with the following information to understand better your problem and setup?

• The problem is that when you configure FlexRAM as OCRAM (128 kB), DTCM (128 kB) and ITCM (256 kB), the content of ITCM and DTCM is always 0, no matter what you write on that section. Is my understanding correct?
• Could you please share with me the specific steps you execute to set this FlexRAM configuration?
• Are you using a custom board? And if that is the case, have you tried the same configuration on an EVK?

Best regards, Daniel.

[briancarrigan]

Daniel,

Your first point is correct. I have devised an experiment to determine if data written in OCRAM mode will then show up in TCM mode, but I have not executed that experiment yet.

For your second point, I am attaching a subsection of my startup code. There may be some defines that are not available, but in general it should be relatively easy to follow. Specifically, the part where I configure either as TCM or OCRAM is close to the top of the file.

I am using a custom board. The board was not really designed based on the EVK, but I did try to use the default peripherals where possible. For example, it boots to FlexSPI and runs that in XIP mode. I have not attempted to run the program on an EVK for the main reason because I do not have one. However, the code was developed with extensive references to the example projects within the SDK (2_11_1_EVK-MIMXRT1060).

Regards, Brian