Moving Heap to SDRAM

[mspenard603]

Hi Gents,

 I've moved heap to SDRAM at 0x8000000 as seen below. And I have nothing but problems with malloc()ing FATFS* fs; pointers. Is this address space forbidden? If I specify the Linker Script to put heap at "End", which is in the non-cached region, all works fine with FatFS. Why would this be?! Or is there some limitation with fsl_sd_disk.c ?

[carstengroen]

Have a look here: https://community.nxp.com/t5/i-MX-RT-Knowledge-Base/Using-NonCached-Memory-on-i-MXRT/ta-p/1183369

[mspenard603]

This describes how to work around the issue by using OCRAM instead of SDRAM that is cached. But it also states "The cache brings a great performance boost, but the user must pay attention to the cache maintenance for data coherency." implying there is a process for using cached SDRAM for FAT and driver variables. What would that be?

[nxp16]

One way to deal with this would be to create a special non-cacheable section in whichever memory you want to use for particular buffers/structures that need to be used by DMA, and then put those structures in this area using __attribute__((section("..."))).  You would do this by adding another entry to the memory table in MCU settings, and then you can set it to non-cacheable in the MPU (in board.c), e.g.:

MPU->RBAR = ARM_MPU_RBAR(region, 0x80000000U);
MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 0, 1, 0, 0, 0, ARM_MPU_REGION_SIZE_32MB); // make entire thing is non-cacheable but shareable so fatfs ramdisk will work

in that case I've made the entire SDRAM non-cacheable, but you can choose a smaller range/different address.

Another method would be to find wherever these buffers/structures are used by DMA in the code and immediately after DMA finishes invalidate the cache for that memory, e.g.:

__DSB(); // Ensure all memory is written first
DCACHE_InvalidateByRange(address, size);

[nxp16]

I'm having a similar problem, but with fatfs using SDRAM as a pre-fat-formatted ram disk for MSC access. If my SDRAM is cacheable, windows doesn't see the disk as formatted, but I am able to create files and read them back after formatting it.  If I change the MPU settings in board.c to make the SDRAM that fatfs uses as its ram disk to be non-cacheable, then windows sees the drive as already formatted (like it's supposed to).  This is really weird.  If NXP is going to supply a fatfs library with their SDK you'd think they'd test these kinds of things out and document or fix them.

[FelipeGarcia]

Hello,

Did you add the following to the preprocessor symbols?

• XIP_BOOT_HEADER_DCD_ENABLE=1
• SKIP_SYSCLK_INIT

This allows the boot ROM to initialize the SDRAM successfully.

Regards,

Felipe

-------------------------------------------------------------------------------

Note:

- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored. Please open a new thread and refer to the closed one, if you have a related question at a later point in time.

------------------------------------------------------------------------------ 

[mspenard603]

Hi, yes, I have these specified:

[FelipeGarcia]

Hi,

You can also import the Hello World example from the SDK. This example initialize the SDRAM so you can use it as a starting point.

Best regards,

Felipe

[mspenard603]

What part of HelloWorld are you talking about specifically? board.h?