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.

Memory_alloc fails to allocate heap

Other Parts Discussed in Thread: SYSBIOS

I'm trying to get some code working on c6670 and c6678 and somehow I'm good in 70 but failing before main() in 78.

In Memory_alloc (also shows on the stack as ti_sysbios_heaps_HeapMem_alloc__E) in xdc\runtime\Memory.c it fails allocating a heap of size 265 saying

Error_raise(eb, Error_E_memory, (IArg)heap, (IArg)size);

where Error_E_memory is "out of memory error"

I've tried increasing the size of SRAM for L2, MSMC and DDR but it is not getting me any further.

What heap is this, what memory does it come from and why am I running out of space?

  • Hi James,

    Please refer below thread to set and check heap size in sysbios.

    http://e2e.ti.com/support/embedded/bios/f/355/t/165630.aspx

    Thanks.

  • Hi Rajasekaran

    I still don't know what is going wrong.

    This is how I set up the heap

    /* Create a Heap. */
    var heapMemParams = new HeapMem.Params();
    heapMemParams.size = 0x8000000;
    heapMemParams.sectionName = "systemHeapMaster";
    Program.global.heap0 = HeapMem.create(heapMemParams);
    Memory.defaultHeapInstance = Program.global.heap0;

    ...
    Program.sectMap["systemHeapMaster"] = "DDR3";
    Program.sectMap[".cinit"] = "MSMCSRAM_MASTER";
    Program.sectMap[".const"] = "MSMCSRAM_MASTER";
    Program.sectMap[".text"] = "MSMCSRAM_MASTER";
    Program.sectMap[".far"] = "DDR3";

    This is what the linker does in the mapfile

    name origin length used unused attr fill
    ---------------------- -------- --------- -------- -------- ---- --------
    L2SRAM 00800000 00060000 0001e12e 00041ed2 RW X
    MSMCSRAM_MASTER 0c000000 00100000 000e9d22 000162de RW X
    DDR3 80000000 10000000 0802d7a0 07fd2860 RW X

    ...

    80000000 80000000 08000000 00000000 rw-
    80000000 80000000 08000000 00000000 rw- systemHeapMaster
    88000000 88000000 0002d7a0 0002d7a0 rw-
    88000000 88000000 0002d7a0 0002d7a0 rw- .far

    And this is what is shown in my ROV 

    What is going wrong? Why isn't it allocating? How do I figure this out?

  • Again, this is all happening before I get to main.

    I put a break at EVM_init (which is the only part of my code before main) and the heap already has totalFreeSize 0.

  • Hi James,

    Thanks. 

    We are moving your thread to TI-RTOS forum for correct response.

  • Here are my OUT and ROV for core 0. 

    4336.evmc6678l_master_pe66.rov.xs.gz

    2337.exec-host.out.gz

    I don't know how to debug this. I am using CFG and custom platforms that have worked for me in the past. That are near matches to those for the 6670 which continues to work.

  • I stripped out some of the program.  It makes it to main but by the time I get to main the ROV is flashing red in the totalFreeSize of the Heap and the error is 

    "Corrupted free list header next ptr (0x80000000) at freeList entry 0x80000018"

    How could this happen before the main routine?

  • HI Jim,

    Are you taking care of the smaller L2 in C6678? The L2 size is in C6678 is half the size of L2 in C6670.

    Thanks,

    Arun.

  • Hi Arun,

    Yes, the L2 is correctly sized for the 78 and the program still fits.

    I am thinking this is actually a hardware error. I tried the image processing demo's master binary and it gives me the same problem.

    Is there any way to test the HW specifically the DDR?

    Jim

  • HI Jim,

    You can try POST in the MCSDK. Are you running the gel file when loading to initialize the DDR?

    Thanks,

    Arun.

  • I had an older c6678 at the office and tried this morning.  It worked fine.

    I ran post and it appears to pass (the failure counter in the source is never incremented).

    I don't run any gel, but both EVMs are loaded with IBL, and I didn't have problems with the board in question until recently. (It was making progress with it, then switched to c6670 to make a delivery, then switched back to c6678 and it failed as above.)

    Still convinced it is a hardware problem of some sort. If the old board works then maybe it doesn't matter, I can just put this one away.

    Thanks

    Jim