heap and the stack on the SDRAM on MIMXRT1064 Evaluation Boar

[jamesk]

Has anyone figured out a working solution to put the heap and the stack on the SDRAM on MIMXRT1064 Evaluation Board?

I thought this would have been so easy to find an answer to since this is such a common configuration for this level of micro-controller. However, amazingly this has not been the case.

I did find some threads on this matter but have not found a solution that works yet.

It would be nice if NXP provided a straight forward working solution.

Below is what I have tried so far but does not fully work.

The behavior between when the heap & stack is placed in SRAM_DTC and when they are placed in SDRAM is different.

The SDK example used is lwip_mqtt_freertos which is included with SDK v2.6.1.

With the heap & stack placed in SRAM_DTC, the example connects to the test mqtt broker and subscribe/publish works.

However, when the heap & stack is placed in SDRAM, following the configurations described below, the example only attempts to connect to the test mqtt broker and nothing happens, with everything remaining the same as SRAM_DTC setup.

1) Add the following to Compiler options:

XIP_BOOT_HEADER_DCD_ENABLE=1

SKIP_SYSCLK_INIT

2) Modify the Memory  Configuration as below:

3) Explicitly specify the heap/stack placement. (this may be optional but some suggest that there may be a bug

in MCUXpresso and this has to be explicitly specified)

Help would be greatly appreciated

Regards,
James

[jamesk]

While I am still waiting for Jeremy's reply to my questions above, I was able to find an alternative solution to my issue of not being able to run lwip_mqtt_freertos demo with the heap placed on the SDRAM (instead of DTC_SRAM).

Instead of disabling D-cache and I-cache as Jeremy suggested(which was proven to be a solution but not too desirable for we may want to use cache-ing capability), modifying the lwip code to use non-cacheable area in the SDRAM(i.e. the last 2MB in the SDRAM is reserved for non-cacheable data through BOARD_ConfigMPU()) worked.

enet_ethernetif_kinetis.c line 546:

//    SDK_ALIGN(static rx_buffer_t rxDataBuff_0[ENET_RXBD_NUM], FSL_ENET_BUFF_ALIGNMENT);
//    SDK_ALIGN(static tx_buffer_t txDataBuff_0[ENET_TXBD_NUM], FSL_ENET_BUFF_ALIGNMENT);
    AT_NONCACHEABLE_SECTION_ALIGN(static rx_buffer_t rxDataBuff_0[ENET_RXBD_NUM], FSL_ENET_BUFF_ALIGNMENT);
    AT_NONCACHEABLE_SECTION_ALIGN(static tx_buffer_t txDataBuff_0[ENET_TXBD_NUM], FSL_ENET_BUFF_ALIGNMENT);

I found out that the following change in the linker configuration must be accompanied for the demo to work as expected:

[jeremyzhou]

Hi james kim ,

Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
Firstly, the steps of enabling the Device Configuration Data (DCD) feature are correct, it can allow the boot ROM to initialize the SDRAM successful.
I had encountered a similar issue before, I found that disabling the Cache feature via the comment out the below code in the BOARD_ConfigMPU(void); to get rid of this issue.
AE team and I consider that this issue may be caused by the memory management mechanism of LwIP against the cache feature.
    MPU->RBAR = ARM_MPU_RBAR(8, 0x81E00000U);
    MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 1, 0, 0, 0, 0, ARM_MPU_REGION_SIZE_2MB);

    /* Enable MPU */
    ARM_MPU_Enable(MPU_CTRL_PRIVDEFENA_Msk);

    /* Enable I cache and D cache */
    //SCB_EnableDCache();
    //SCB_EnableICache();

Have a great day,
TIC

-------------------------------------------------------------------------------
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.
-------------------------------------------------------------------------------

[jamesk]

I really appreciate your answer, Jeremy.

Let me try your suggestion and let you know.

While we are at this, do you think you can answer these questions also?

1) In the context of FreeRTOS, the stack for a task being created is allocated from the heap location specified below.

What is then "Slack" specified below used for?

2) In the case where FreeRTOS is used with 3rd party libraries that use C standard version of malloc & free,

where is malloc allocating the memory from? I understand FreeRTOS's pvPortMalloc gets it from ucHeap, which

is Heap + Post Data as specified in the picture 1) above.

Does the MCUXpresso compiler provides thread safe malloc & free?

If not, how do we deal with reentrancy issue with this?

3) I have seen a few NXP demos with the following usage of extra linker script input.

Does this mean .data & .bss will be placed in SRAM_DTC instead of the first RAM region specified in Memory Configuration?

4) Is there a document that elaborates on the code inside BOARD_ConfigMPU()?

I am quite confused about shareable, cacheable, & non-cacheable memory region.

Obviously I also don't understand what this 2MB reservation at the end of SDRAM is for.

    MPU->RBAR = ARM_MPU_RBAR(8, 0x81E00000U);
    MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 1, 0, 0, 0, 0, ARM_MPU_REGION_SIZE_2MB);

Thank you so much for your support!

Regards,

James

[jeremyzhou]

Hi james kim ,

Sorry for reply late.
1) In the context of FreeRTOS, the stack for a task being created is allocated from the heap location specified below.
What is the "Stack" specified below used for?
-- It's mainly used to store parameters of the called function and the local variable value.
2) In the case where FreeRTOS is used with 3rd party libraries that use the C standard version of malloc & free, where is malloc allocating the memory from? I understand FreeRTOS's pvPortMalloc gets it from ucHeap, which is Heap + Post Data as specified in picture 1) above.
-- Actually, both of the malloc() and pvPortMalloc() have the same prototype actually, and they will allocate the memory from the heap area.
3) Does the MCUXpresso compiler provide thread-safe malloc & free?
-- For the IDE, it just provides the 'standard' version of malloc and free mechanism, in the lwip_mqtt_freertos demo, it uses Heap_3.c mechanism and it just as same as the 'standard' version of malloc and free mechanism.
4) I have seen a few NXP demos with the following usage of extra linker script input. Does this mean .data & .bss will be placed in SRAM_DTC instead of the first RAM region specified in Memory Configuration?
-- No, it won't.
5) Is there a document that elaborates on the code inside BOARD_ConfigMPU()?
-- I've attached an application note: AN12042 which introduces the basic technology of the cache system that includes the L1 cache, memory types, attributes and MPU (Memory Protection Unit).

Have a great day,
TIC

-------------------------------------------------------------------------------
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.
-------------------------------------------------------------------------------