RT1064 with non-cacheable area in HyperRAM problem

[carstengroen]

I have a system with a RT1064 and HyperRAM (same chip as EVK). This works perfectly, I have run RAM tests for weeks and weeks, all checks out fine.

But, if I place the non-cacheable area in the HyperRAM, things go downhill quickly.....I get hardfaults (and sometimes debugger "dies" when debugging). I have been working with this for some days now, and it seems that the triggering factor is if one of the following is true:

a) The whole 8 MByte of HyperRAM is defined as non-cacheable in the MPU (buffered, non-cacheable)

or

b) The last part of HyperRAM (2 MByte) is defined as non-cacheable

Now, in case of b), if I just move the non-cacheable are to some other place like OCRAM2, all is ok (and all other data is in the first 6 MByte of HyperRAM).

So, it seems that if the HyperRAM or part of the HyperRAM is set as non-cacheable and that part is used, I will get hardfaults.

I have a identical system with SDRAM, and there the same application behaves as expected, I can place the non-cacheable area at the end of SDRAM, and all works perfect.

Are there any problem in placing non-cached data in HyperRAM (or am I fighting something else) ??

[carstengroen]

Victor,

I'm fully aware that the HyperRAM is slower than the DTCM, OCRAM etc, but the real issue is what precisely make the system fail _just_ because the "non-cacheable" areas are placed in HyperRAM, but NOT when placed in SDRAM (or any other memory type for that matter).

There must (maybe?) be something that is special with the HyperRAM interface/statemachine etc. that makes it fail if there is no cache active for the area.

I will do some more testing once I get this to the top of my list

[victorjimenez]

Hello Carsten, 

Can you try disabling the AHBCR[prefetchen] for flexspi0 to see this helps with stack and USB buffer in HyperRAM? 

Regards,
Victor 

[carstengroen]

Victor,

I'm really sorry to not have been on this yet, I will in the near future. I have been hung up on other projects, but will have a shot at the HyperRAM/non-cachable very shortly again.

Again, I'm sorry for the delay, hope you have a little more patience with me

Regards,

Carsten

[nxp16]

FYI, make sure you enable the trace lines in the pinmux for the Segger J-Trace to work properly.  Depending on which line you use for SWO:

IOMUXC_SetPinMux( IOMUXC_GPIO_B0_13_ARM_TRACE_SWO, 0U);
IOMUXC_SetPinConfig( IOMUXC_GPIO_B0_13_ARM_TRACE_SWO, 0xf9u);
IOMUXC->SELECT_INPUT[kIOMUXC_SW_MUX_CTL_PAD_GPIO_B0_13] = 0b10;

or

IOMUXC_SetPinMux( IOMUXC_GPIO_AD_B0_10_ARM_TRACE_SWO, 0U);
IOMUXC_SetPinConfig( IOMUXC_GPIO_AD_B0_10_ARM_TRACE_SWO, 0xf9u);
IOMUXC->SELECT_INPUT[kIOMUXC_SW_MUX_CTL_PAD_GPIO_AD_B0_10] = 0b1001;

-m

[carstengroen]

Yes,

already got it working from the debug scriptfile in Ozone. Works perfect so far using TRACEDATA 3..0 and TRACECLK.

Only thing missing is the ability to place "trace data start" and "trace data stop" markers, according to Segger this is missing for M7 in Ozone for the time being.

You can't have it all

(oh, and I'm missing support for RTOS (RTX5), you don't happen to have that by any chance?)

[nxp16]

How are you placing it in the HyperRAM?  Via MCU settings?  You should also look at the board.c MPU settings because there are some defaults there that I think don't change based on MCU settings.  It might be crashing due to the MPU.

[carstengroen]

I got that under control, MPU is being set correctly, and loading in the different sections is done in scatterfile (using Keil). All the stuff is placed where I tell it to (checking map file), and as I wrote, I have an identical system where the only difference is SDRAM instead of HyperRAM, and that one works perfect.

When I check the 2 map files, the only difference is that the non-cacheable area is sitting at 0x81E00000 in the SDRAM system (2 MByte big), and at 0x60600000 in the HyperRAM based system (2 MByte big).

And as I also wrote, the moment I move the non-cacheable stuff to f.ex OCRAM2 (and make that area non-cacheable in the MPU) the HyperRAM works also fine. If I then disable caching for the HyperRAM in the MPU, it crashes.

If I do the same in the SDRAM system, it just runs slower, but works perfectly fine.

So far, the only real thing that seems to trigger the problem is if a part of the HyperRAM that is in use, has caching disabled.

[nxp16]

That's really odd.  Maybe there is something about the 0x60000000 address space that we don't know.  I only say this because our project accesses an FPGA via SEMC as SRAM and when we put it where we thought it should go in the address space (I forget where, maybe 0x90000000), it was cached and didn't work.  NXP told us to move it to 0xA0000000 because somehow that address space is magically not cached.  What happens if you try to move HyperRAM to 0x80000000?

[carstengroen]

I can't move the HyperRAM, its sitting on FlexSPI1 which has the address space located at 0x60000000. The RT1064 has internal NOR Flash on FlexSPI2 which is located at 0x70000000

[nxp16]

I thought you could actually specify the address in the SEMC config in peripherals.c.  At least that's how we changed the address to our FPGA.