This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RM48L930: how to combine os_heap with sysmem, or eliminate one of these heaps?

Part Number: RM48L930

Support Path: /Product/Help with Device Selection/

Hello,

I am running a CCSv7 project built with HALCoGen and FreeRTOS.  In the project properties, under ARM Linker - Basic Options, the Heap Size for C/C++ dynamic memory allocation is set.  This memory is located in .sysmem and following a build the location of .sysmem  is visible in the created .map file.  The malloc() function in the runtime support library (rtsv7R4) (file = memory.c) uses this heap area.  And the C++ operator 'new' works as expected in my code.

Notice also that in FreeRTOSConfig.h the configTOTAL_HEAP_SIZE setting.  The HALCoGen code in os_heap.c uses this to create its own heap (ucHEAP[]) that is used by pvPortMalloc().  And pvPortMalloc() also works as expected.  Note that FreeRTOS uses pvPortMalloc() when creating tasks and OS objects.

So in my current setup I have 2 different heaps, which appears very wasteful of limited RAM if each is lightly used.  Why does HALCoGen have a heap separate from the runtime library?  Can I merge these 2 heaps so to minimize my memory footprint?  Do you recommend that application code never call pvPortMalloc() and instead use the malloc() from the RTS lib (memory.c)?

Thank you,

Keith

  • A follow-on question related to where the .sysmem is located in RAM.  My linker.cmd file looks like this:

    SECTIONS

    {

    .intvecs : {} > VECTORS

    /* FreeRTOS Kernel in protected region of Flash */

    .kernelTEXT : {} > KERNEL

    .cinit : {} > KERNEL

    .pinit : {} > KERNEL

    /* Rest of code to user mode flash region */

    .text : {} > FLASH0 | FLASH1

    .const : {} > FLASH0 | FLASH1

    /* FreeRTOS Kernel data in protected region of RAM */

    .kernelBSS : {} > KRAM

    .kernelHEAP : {} > RAM

    .bss : {} > RAM

    .data : {} > RAM

    /* USER CODE BEGIN (4) */

    .sysmem : {} > RAM

    /* USER CODE END */

    }

    After a build, my map file shows the sysmem is located after the .bss section but before the .data section.  I would like .sysmem to be located after the .data section.  How to configure the link.cmd file to do that?

  • Keith,

    Depending on your build process, if you have complete control over your .cmd file (not auto-created by the tools), then I can offer some suggestions:

    One way is to use the GROUP directive in the .cmd file. You can find more detail in the assembly tools user guide and may be included in your CCS Help files. The example in the manual is

    SECTIONS
    {
    .text /* Normal output section */
    .bss /* Normal output section */
    GROUP 0x00001000 : /* Specify a group of sections */
    {
    .data /* First section in the group */
    term_rec /* Allocated immediately after .data */
    }
    }

    You can remove the 0x00001000 to let the linker put the group where it wants to, but the order will be as specified within the GROUP {}.

    Regards,
    RandyP
  • Hello Keith,

    I am not aware of a way to combine the heaps for both the system and the RTOS. The RTOS is a third party SW based product that, I believe, relies on the specified definition that is fulfilled by Halcogen. If you were to do your own integration of an RTOS, you would also have to insure the allocation of the RTOS specific heap area. If you feel the sizes are wasteful, simply reduce the sizes to a size more appropriate to your application and use requirements.

    In regard to placement of the sections, I believed this was based on the order defined in the linker command file. The normal command file included by Halcogen has the order you mentioned you are seeing so I am curious if you have disabled the original command file or removed it from the project? If this is the case, I would suggest posting to the CCS forum or trying the suggestion from Randy below to see if this works.
  • Ok, thanks Chuck.