• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 98 subscribers
  • Views 3017 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Using malloc() and calloc() in Bios 6?

MikeH
Guru 15580 points
Other Parts Discussed in Thread: SYSBIOS

My bios 6 application references a library that uses malloc() and calloc() functions. Will there be a problem with this? If I define a HeapStd will my library calloc's use this heap?

thx

MikeH

 

  • 0
    TI__Mastermind 20805 points

    Which exact version of BIOS 6 are you using?

    Starting with 6.31, we now provide malloc/calloc functions with BIOS that internally use ti.sysbios.heaps.HeapMem.  HeapMem has advantages since you can use ROV tool to review the HeapMem status and see the free list and such to help look for fragmentation problems and/or memory leaks etc.

    HeapStd actually uses the compiler's C runtime support library's malloc and free.

  • 0 in reply to Karl Wechsler
    Guru 15580 points

    Karl,

    I'm using bios_6_30_02_42 but it appears to include HeapMem. Is this correct? Do I need to upgrade?

    Thanks!

    MikeH

     

  • 0 in reply to MikeH
    Guru 15580 points

    I am trying to create a rather large heap (150k) in my application and have created the following code:

     

    var xdc_runtime_HeapStd = xdc.useModule('xdc.runtime.HeapStd');

    var instxdc_runtime_HeapStd0Params0 = new xdc_runtime_HeapStd.Params();

    instxdc_runtime_HeapStd0Params0.size = 150000;

    var instxdc_runtime_HeapStd0 = xdc_runtime_HeapStd.create(instxdc_runtime_HeapStd0Params0);

    Memory.defaultHeapInstance = instxdc_runtime_HeapStd0;

    However, I get the following error:

     

    TypeError: Cannot read property "defaultStackSize" from null (C:/Program Files (x86)/Texas Instruments/xdctools_3_20_03_63/packages/xdc/om2.xs#176) ARM_init_SYSBIOS ARM_init_SYSBIOS.cfg Configuration Validation 1302526551339 5963

    But, I have included the Memory module as follows:

    var xdc_runtime_Memory = xdc.useModule('xdc.runtime.Memory');

    What am I doing wrong?

    Thx,

    MikeH

     

     

     

  • 0 in reply to MikeH
    TI__Guru* 96960 points

    Hi Mike,

    What is your Program.heap setting? This value specifies the size of the malloc pool. If it is < 150000, you'll get a build error, but not the one you are getting.

    Are you wanting to use HeapStd or HeapMem? Based on the previous posts, it appears that you wanted to use HeapMem, but not change existing code that is using malloc.

    Todd

  • 0 in reply to ToddMullanix
    Guru 15580 points

    Todd,

    Sorry for the dupe posts, but I need to get past this issue quickly.

    ToddMullanix said:
    Are you wanting to use HeapStd or HeapMem? Based on the previous posts, it appears that you wanted to use HeapMem, but not change existing code that is using malloc.

    Actually, I am still quite confused about which to use. Based on the User Guide (sect 5.6.5)

    "The XDCtools xdc.runtime.HeapStd heap implementation uses malloc() and free()."

    which is why I was trying to use HeapStd. But, it also says:

     

    In addition to allocating from Heaps created with SYS/BIOS modules, your

    application can use the standard runtime library malloc() and free() functions.

    These allocate and deallocate memory from a separate heap.

    What does it mean by "separate heap"? Is this a heap that *I* need to create with HeapStd? Or is this a hidden heap that is defined is some other way? It appears that this "separate heap" has a size that is controlled by Program.heap = xxxxx (size).

    And where is "Program" documented? I find vague references to "Program" throughout the User Guide, but there is no specific definition of it or it's API calls.

    So, bottom line, if I want to, as you correctly surmised, not change my existing code (library) that uses malloc, I should set Program.heap = 150000 and not use HeapMem or HeapStd?

    Thx,

    MikeH

     

     

  • 0 in reply to MikeH
    TI__Guru* 96960 points

    Hi Mike,

    First of all, an application can have multiple runtime heaps. This is to allow separation of dynamic memory between its components. To allow even more flexibility, there are different Heap implementations (each with its pros and cons).

    Existing heaps in XDC and SYS/BIOS
    xdc.runtime.HeapStd: based on malloc/free. Pros: simple...everyone understands malloc/free. Cons: little heavy implementation, external fragmentation

    xdc.runtime.HeapMin: variable length heap with no free(). Intended for apps that want to allocate but never free memory. Pros: fast. no fragmentation Cons: cannot free memory.

    ti.sysbios.heaps.HeapMem: variable length memory heap (similar to malloc). Pros: better performance than malloc and less footprint Cons: external fragmentation

    ti.sysbios.heaps.HeapBuf: fixed size heap. Pros: Fast, small footprint, no external fragmentation Cons: potential internal fragmentation

    ti.sysbios.heaps.HeapMultiBuf: multiple fixed size heap (manages multiple HeapBufs for you). Pros: Fast, small footprint, no external fragmentation Cons: potential internal fragmentation.

    Memory.defaultHeapInstance
    Most apps want a heap, one is created for you automatically (can be turned off...different thread). You can specify the defaultHeapInstance if you want via the Memory.defaultHeapInstance config parameter. If you just want the size of the default increased, but still created for you, change the Memory.defaultHeapSize parameter.
    You can access the defaultHeapInstance by using NULL in the Memory APIs. For example

    Memory_alloc(NULL, mySize, myAlign, &eb); // eb is an error block

    Program.heap (note: Program is really xdc.cfg.Program)
    On platforms that enable control of the size of the heap managed by the run-time support function malloc(), this parameter specifies its initial size (in units of chars).

    HeapStd Instance
    You can have multiple instances for HeapStd...what does not mean since it is based on malloc whose size is determined by Program.heap? When a HeapStd instance is created, a size is specified (e.g. 0x1000). The Program.heap value is checked to make sure there is enough space in malloc to support this. Let's say Program.heap was 0x4000. 0x1000 <= 0x4000...no problem. I cannot now create another HeapInstance of size 0x3500 since 0x1000 + 0x3500 is not less than 0x4000.  This was done to help developers catch cases where the Program.heap was too small. Note: this does not factor in any calls to malloc directly.
    I don't think this is an issue for you, but I'm putting it here for completeness.

    SYS/BIOS pre-6.31
    1. The defaultHeapInstance was a HeapStd instance if the app did not create one and plug it in.
    2. malloc() was the normal malloc()

    SYS/BIOS 6.31 and later
    To help simplify things...
    1. If the app did not specify a defaultHeapInstance, SYS/BIOS create a HeapMem for you and plugs it into memory. It uses the BIOS.heapSize parameter if the app did not set the Memory.defaultHeapSize.
    2. If the defaultHeapInstance is HeapMem (because SYS/BIOS set it or the app did), SYS/BIOS adds a malloc function that calls uses the defaultHeapInstance. It also adds the calloc, etc. functions. So the RTS malloc is not in the app. We did this to reduce footprint and improve performance.

    Hopefully this answers some of your questions.
    Todd 

  • 0 in reply to ToddMullanix
    Guru 15580 points

    Todd,

    Good stuff. Would be a great Wiki....:)

    In my app I have simply set Program.heap = 0x25000, which appears to allow my library to successfully call calloc() which allocates memory from the memory location I specified by 

    Program.sectMap[".sysmem"] = "ARM_DDR";

    Is this correct? Am I interpreting your comments correctly?

    Thx

    MikeH