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.

RTOS/CC1310: Removing the malloc Heap

Part Number: CC1310
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI-RTOS

Champs,

BIOS user guide chapter D.2.1 discusses the possibility of removing malloc Heap to save RAM. Customer is implementing this option but it is not at all clear what function calls must be avoided when using this option. In other words there is no explicit list of SYSBIOS APIs that make use of malloc heap and may fail when the heap is absent. In looking through SYBIOS documentation I found the BIOS_runtimeCreatesEnabled flag.

It looks like one possible way to safely remove malloc heap is to turn the flag off thus ensuring that all potential malloc calls would take place during initialization and once fixed (i.e. explicit and hidden allocation are done as required) it is virtually guaranteed that no spurious API call attempts malloc. 

Does the above make sense? Can you suggest any other ways to remove malloc heap while ensuring that no API requiring malloc slips to the application's run-time?

thank you

Michael

  • Hi Michael,

    First let's make sure we are talking the same language....
    - heap: (generally) a buffer that is used for dynamic memory allocation.
    - malloc: an API that is used for allocating memory from a heap

    The kernel supports the ability to not have a heap, but for the C13xx/C26xx devices, we provide a version of the kernel in the ROM. The ROM kernel has heap support in it, so if you use the ROM kernel, you must have a heap. You could put the kernel in flash, but the savings you get for the lack of a heap is greatly outweighed by the additional code in the flash now.

    You can reduce the heap to a very small size (e.g. 8 bytes) if you want to save RAM, but for flash, there are no tricks you can do.

    Note: malloc should not be in your application unless someone is calling it. The kernel generates a malloc call, but nothing in the kernel calls it. So if it is your mapfile, it's your application (or some middleware) pulling it in.

    Todd
  • Todd,

    customer is looking into removing the heap altogether, i.e. setting BIOS.heapSize = 0; as explained in the user guide. I do not think ROM based kernel prevents it, unless I misunderstand. The concern is with the following statement in the UG:

    Applications that remove the heap cannot dynamically allocate
    memory. Therefore, such applications should not use the SYS/BIOS Memory module APIs or other
    SYS/BIOS APIs that internally allocate memory from a heap.

    There is no explicit list of "other SYS/BIOS APIs that internally allocate memory from a heap". We know that _construct functions for example do that. We need a way to ensure no API that may request heap memory would be called when BIOS.heapSize = 0; Setting the BIOS_runtimeCreatesEnabled =0; seems like a reasonable way to achieve it since any SYSBIOS object creation call will return an error instead of trying and failing to get memory from heap. 

    what do you think?

    thanks

    Michael

  • Michael,

    It looks like you can set the heap size to 0. I tried it with the driver's empty example and it seems to work. I just set the following to zero in the linker file. Note: the __primary_heap_start__ and __primary_heap_end__ symbols are used in the .cfg file to set up the heap,

    HEAPSIZE = 0x0; /* Size of heap buffer used by HeapMem */

    Note: ROV is not happy. If you look at the detailed view, it shows red.

    Todd
  • Todd,

    so if there are no malloc calls in the application code but there is still malloc present in the .map file - how would you go about finding out what pulls it in?

    thanks

    Michael

  • Michael,

    Can you set a breakpoint on it and see if it called?

    Which compiler are you using? I know the TI compiler has call_graph which shows whom is calling whom.

    Todd
  • Michael,

    Did this get resolved?

    Todd