Synergy - how can I setup the heap to use SDRAM?

PE-HMI1

SDRAM = MT48LC16M16A2B4 256Mb (16M x 16) 

eMMC = MTFC2GMVEA 2GByte 

 

I am using the FileX fx_media_check() API that needs 500000 Bytes. This much temporary memory can't be allocated from RAM, so it must be allocated from SDRAM.

I can statically allocate it like below:

static UCHAR sratch_memory[SCRATCH_MEMORY_SIZE] __attribute__ ((section(".sdram")));

 

The default heap is using only the MCU's RAM. So, if I use malloc(), it will fail because there is not enough free space in the heap.

Has anyone setup the linker file with 2 heap sections, one for RAM and the other for SDRAM?

Thanks,

Bruce

  • Bruce,

    I would never recommend using the heap for storage on a real time system. There are byte pools and block pools available. You statically allocate the memory for the entire pool as you did above, then create the byte pool using tx_byte_pool_create(TX_BYTE_POOL *pool_ptr, CHAR *name_ptr, VOID *pool_start,
    ULONG pool_size, UINT pool_control_block_size);

    The normal c heap is not thread safe or deterministic in behavior but if you must, you can modify the linker script to move the .heap area into SDRAM. Note that the SDRAM must be initialized before _sbrk() is called by the BSP.

    -Gary
  • In reply to garyj:

    I think I will try avoid the memory allocation problem by creating small partitions in the eMMC device, instead of making a huge 2GByte partition.
  • Are you using iar or gcc for linking?
  • In reply to bgraham:

    Bruce,

    Filex uses byte pools internally anyway - the original solution that you came up with was fine. I was only mentioning creating a byte pool of your own for runtime allocations of heap like memory in a deterministic thread safe manor. After the pool is created you can use tx_byte_allocate() and tx_byte_release(). You can define macros for malloc and free that use these functions for portability.


    -Gary
  • In reply to garyj:

    As you suggested, I really need to avoid using malloc and free. My applications are using C++.

    I think the gcc compiler's linker file will need to be modified so that the heap can use SDRAM. Then new and release will be able to SDRAM without any extra effort.

    But, expanding the heap to use SDRAM will not help load a apps initialized data from FLASH to SDRAM. It appears that the Synergy startup code is hard coded to load initialized data only to SDRAM.

    Has anybody figured out how to expand gcc's heap to include the SDRAM?
    Has anybody figured out how to get the Synergy startup code to load initialized data to SDRAM?

    Thanks,
    Bruce
  • In reply to bgraham:

    Bruce,

    You need to initialize the SDRAM before the c-runtime system is initialized. The BSP code uses SRAM because it does not have to be initialized. You will need to setup the clock tree and the I/O pin muxing before the SDRAM is initialzied. If you generate a simple blinky hal project and set the optomization to -O0 (no optimization) you can step through reset to see the order that things are currently done in setting up the MCU and the c runtime system. You have th source code for all this and can modify it to suit your requirements.

    -Gary
  • In reply to garyj:

    I stepped through the generated code to determine how the heap and initialized variables are managed. I am sure I could rewrite the code, but.... I don't think I have the time.

    Am I correct in assuming that in order for the Synergy software to use the SDRAM, a memory section must be added to the project's linker file, and then use the memory section's name where memory is allocated?

    Since the most likely use of SDRAM is to use it like MCU RAM is used, why does the BSP section of the configurator not provide a setting to generate code that sets this up auto-magically?

    Thanks,
    Bruce
  • In reply to bgraham:

    Use the BSP included for PE_HMI. It includes bsp_sdram.c/h, which has everything you need. The PE_HMI has 4GB of SDRAM. That's where I got the linker script that showed how to move the heap section of SRAM to the SDRAM section.
  • In reply to larry_c_Mass:

    My project is using the PE-HMI1. I have the PE-HMI1 selected in the configurator.
    The S7G2.ld file is directing the heap to RAM.

    .heap (NOLOAD):
    {
    . = ALIGN(8);
    KEEP(*(.heap_d1))
    . = ALIGN(8);
    __HeapBase = .;
    __end__ = .;
    end = __end__;
    KEEP(*(.heap*))
    __HeapLimit = .;
    } > RAM

    So, all I have to do is change RAM to SDRAM?

    Thanks,
    Bruce
  • In reply to bgraham:

    I think that's all it should take. The heap will be available after the BSP sets it up. This is not going to give to you an extension to the original SRAM heap - it'll just move it all to SDRAM.

    lc
  • In reply to larry_c_Mass:

    Larry & Bruce,

    No, that's not all - please not that the SDRAM initialization occurs AFTER the c startup. This won't work. You need to initialize the SDRAM after the I/O and Clock tree is initialized and before the c startup stuff.

    -Gary
  • In reply to garyj:

    If the SDRAM had been placed just after the RAM in the ARM's address space, then memory usage would have been much simpler. The linker file's RAM section would only need to be adjusted for the extended memory.

    Gary,
    Does Renesas have a working example that use both RAM and SDRAM for the C Run Time's initialized variables and heap?

    Thanks,
    Bruce
  • In reply to bgraham:

    I think these types of "advanced" linker techniques are covered in a nice paper by TI at www.ti.com/.../spraa46a.pdf

    It's written for Code composer studio, but they use the gcc linker like E2.

    If you're using IAR, IAR has some appnotes as well.

    I think you can but the bss in multiple sections - the heap may be difficult as it needs to assign blocks from contiguous memory. But a lot of stuff in Renesas come from "pools" vs the heap, so you may be able to get the effects you want.

    Good luck,
    Larry (Not Renesas)
  • In reply to bgraham:

    Bruce,

    No, there is no example code for a custom BSP that does that.

    -Gary