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.

CCS/TMS320C6678: SYSBIOS Heap size problem.

Part Number: TMS320C6678
Other Parts Discussed in Thread: SYSBIOS

Tool/software: Code Composer Studio

phenomenon:

  1. In baremetal project, the linker can allocate space correctly for heap with the size that is specified in the argument "-heap HEAPSIZE". The size here can be set to as large as 0x7FFFFFF8, and I can see the allocation information in the .map file.
  2. In SYSBIOS project, when I make the default heap size >= 0x20000000 (512MiB) using codes like 'BIOS.heapSize = 0x20000000; I cannot find the allocation for heap space in the .map file of the final outputed executable. The used size of the DDR3 is 0x0.
  3. In SYSBIOS project, when I smaller the heap size, like 0x1FFFFFF8, then I can see the allocation of the heap section in the .map file.
  4. tried c6000 CGT 8.1.3 and 7.4.21, the same.
  5. tried SYSBIOS 6.45 / 6.50, the same.

I've check the links below:

In that link, it says this problem is caused by linker's bug that cannot allocate space for very large array.

Question:

  1. It's been 4 years, has the linker's bug been fixed?
  2. It looks like the linker can treat the argument '-heap' correctly, so is there any workaround for the SYSBIOS that it can make use of the argument '-heap' of the linker to allocate the default SYSBIOS heap? Because by default, SYSBIOS set the '-heap 0x0' in the generated linker.cmd file.

  • Can you look in the mapfile and let us know how big DDR3 is?

    Todd
  • canfoderiskii,
    there are two different concepts discussed here. One is the system heap, which is allocated to the section ".heap" and that's where the memory is allocated from when you call malloc() in baremetal apps.

    In SYS/BIOS apps, that heap is not used and that's why -heap option is always set to 0. SYS/BIOS heap, defined by setting BIOS.heapSize, is a buffer kept in a different section. For example, by default you would use a HeapMem instance as your heap, and in the memory map you would see a buffer with the name ti_sysbios_heaps_HeapMem_Instance_State_0_buf__A in the section ".far".

    Now, when you say that you can see that the heap is correctly allocated when smaller that 0x20000000, do you mean that you can see a buffer of the right size in the section ".far" (or any other section, if you changed the buffer's section)? That would mean that the linker bug was fixed, although when I check the bug database for that bug, it appears that the bug is not being fixed yet.

    SYS/BIOS can't use -heap to work around the linker bug because it doesn't matter which section is used for the heap buffer, if the linker cannot allocate a large buffer.
    But, not all heaps use buffer. I know there is HeapCallback module in SYS/BIOS, where you can implement your own function to allocate memory, and that function can just call malloc() but I am not familiar what you have to do to use it, so I would have to ask someone if you think you want to use it.

    So, let me know which heap manager you are using, and what are you seeing in the memory map when the heap size is smaller than 0x20000000, and we can work from there.
  • 0x40000000, 1GiB
  • Hi, Sasha.

    1. I didn't change the default heap instance, so it is HeapMem.
    2. I used 'BIOS.heapSection = ".sysheap";' to change the section of the default heap.
    3. When I use "BIOS.heapSize = 0x20000000", in the .map file SEGMENT ALLOCATION MAP, there is no section named .sysheap. But in the SECTION ALLOCATION MAP of the .map file, I can find the .sysheap of which the origin/length are 0x80000000/0x0. And its attribute is UNINITIALIZED and no inputed section information.
    4. When I set the default heap size to 0x1FFFFFF8, in the .map file SEGMENT ALLOCATION MAP, the section .sysheap is listed there with run/load/length are 0x80000000/0x80000000/0x1FFFFFF8. In the SECTION ALLOCATION MAP, .sysheap has its origin/length being 0x80000000/0x1FFFFFF8 and its attribute/inputed section are UNINITIALIZED/lib_pe66.oe66 (.sysheap).
  • I was able to replicate your problem on a much smaller example that doesn't involve SYS/BIOS. The source code is below, and it seems that the compiler bug in the linked thread is not fixed yet. So, you can't use HeapMem for heaps of size 0x20000000 or larger because that requires a buffer of that size and that's when you encounter that compiler bug. If you need a heap of that size, you would have to use a heap manager that doesn't use buffers, and the only such manager in SYS/BIOS is HeapCallback, where you basically have to implement HeapCallback_malloc. The easiest implementation of that would be to call malloc() from the runtime library.

    Unfortunately, I don't see any other workaround that would combine SYS/BIOS heap managers and heaps of that size.

    This is the code that demonstrates the problem, where you can choose the size of the large buffer and observe the memory map:

    //char bigBuf[0x1ffffff8];
    char bigBuf[0x20000000];
    #pragma DATA_SECTION(bigBuf, ".mysection")

    int main(void) {
        bigBuf[3000] = 'i';
        return 0;
    }

     

  • Hi Sasha, thank you for the reply.

    Can I use HeapStd to replace HeapCallback in the situation that linker's heap section is to be used?
  • xdc.runtime.HeapStd should work too, but it is rarely used with SYS/BIOS. It is worth trying, I think.