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.

HeapMem out of memory

Other Parts Discussed in Thread: SYSBIOS, TMS320C6670

I got HeapMem out of memory message as below.

ti.sysbios.heaps.HeapMem: line 307: out of memory: handle=0x878638, size=3936
xdc.runtime.Error.raise: terminating execution

I assigned 16MBytes default Heap memory on DDR3 in the .cfg file

var heapMemParams                   = new HeapMem.Params;
//heapMemParams.size                  = 0x927C0;      // 600KBytes
heapMemParams.size                  = 0xF42400;       // 16MBytes
heapMemParams.sectionName           = "systemHeap";
Memory.defaultHeapInstance          = HeapMem.create(heapMemParams);
//Program.sectMap["systemHeap"]       = Program.platform.dataMemory;
Program.sectMap["systemHeap"]       = "DDR3_C1";

And, there's enough memory on the DDR3 Heap memory area.

Memory configuration of the map file is like this.

MEMORY CONFIGURATION

         name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
  L2SRAM                00800000   00100000  00098d1c  000672e4  RW X
  MSMCSRAM              0c000000   00200000  001037fc  000fc804  RW X
  DDR3_C0               80000000   04000000  00000000  04000000  RW X
  DDR3_C1               84000000   04000000  00ff0a78  0300f588  RW X
  DDR3_C2               88000000   04000000  00000000  04000000  RW X
  DDR3_C3               8c000000   04000000  00000000  04000000  RW X
  DDR3_TX               90000000   04000000  00000000  04000000  RW X
  DDR3_RX               94000000   04000000  00000000  04000000  RW X
  DDR3_IF_C0            98000000   02000000  00000000  02000000  RW X
  DDR3_IF_C1            9a000000   02000000  00000000  02000000  RW X
  DDR3_IF_C2            9c000000   02000000  00000000  02000000  RW X
  DDR3_IF_C3            9e000000   02000000  00000000  02000000  RW X

In the ROV(HeapMem), I found something strange.

The Heap memory buffer starts at 0x84000000 with total size of 0xf42400(16M)

But, the FreeList says theres only 0x2 size if free

Did I miss something to do when assign Heap on DDR3?

 

Regards,

Hoon Lee.

  • We have exactly the same problem. Sometimes, we do not get a ti.sysbios.heaps.HeapMem message bur our application crashes with a register dump. The problem seems to disappear when using L2SRAM as heap memory. For now, this is sufficient, but in future we will need much more heap space, so we have to use DDR3.  So it would be fine to find out what is going wrong here.

    Regards

    Marcus

  • The combination of your two posts makes me wonder if DDR3 memory and/or timing is being setup properly.  The ROV tool is reading memory to display its values, so it looks like it is seeing some sort of corruption for the free list too.  But by moving to static memory (L2SRAM) the issue Marcus saw was resolved.

    What platforms are you running on?  Are you initializing and setting proper timing for DDR3?  Either at runtime or with a GEL file?  Are you using this memory region for other purposes without issue?

    Scott

  • I used TMDXEVM6670L board with GEL file TI supplies.  There's no change to the GEL file.

    The changed are endianness to big and DDR3 memory map as you can see in my first post.

    So, there might be no corruptions I guess.

     

    Regards,

    Hoon Lee.

  • We have the same issues on a EVM6678 board as well as on our own board with an architecture based on the EVM. For the EVM, we use the GEL provided from Advantec without modifications. For our own board we have the GEL file adapted and we have reduced the DDR3 speed to 400MHz. We have done extensive memory testing of the DDR3 and other applications run without any problems.

    As far as I can say for now, the problem seems to be closely related to the use of MessageQ module for core communication. We open and close again message queues, and after some time, the heap gets messed up by one of these operations.

    Regards

    Marcus

  • Hoon, Marcus,

    OK, thanks for clarifying.  It is still curious why the problem goes away for Marcus when using L2SRAM instead.  There are obvious timing differences versus DDR3 though, so maybe that is part of the key.

    When the apps get in this state do you see anything else in ROV that looks wrong?  All stacks still have space available, etc.?

    Do you have a test case that we could run to reproduce the issue?

    Which versions of SYS/BIOS and XDCtools are you using? 

    I don’t know of any outstanding issues, but I will check with others…

    Thanks,
    Scott

  • Scott,

    My project uses SYS/BIOS 6.34.2.18, MCSDK PDK TMS320C6670 1.0.0.17 and IPC 1.25.0.04

    Currently, I removed some Memory_alloc() from my source and it works because the dynamic memory does not exceed the assigned Heap memory size.

    When the problem occurs, I'm not pretty sure but,  didn't see any specific messages from ROV except HeapMem.

    Unfortunately, I added some functions and modified source code. And, it is difficult to go back to the point of this problem occurs.

     

    Marcus,

    Do you have the test case that Scott want? I hope you have one.

     

    Regards,

    Hoon Lee.

  • Since you are on the 6670, are your applications using multicore (I would assume so, otherwise, why would you be using a 6670)?

    If they are multicore application, have you built multiple executables to be loaded on different cores or is it a single executable loaded on all cores?

    Someone mentioned that if using L2SRAM things work but when moving to DDR3, things don't work.  The most common problem why this is the case
    is that, each core has its own L2SRAM so when placing a heap in L2SRAM, each core's allocation does not affect another core's allocation.
    DDR3 on the other hand is shared, therefore you must make sure the Memory_alloc() don't clobber one another.  This can be done in 2 ways:

    1.  Use a multicore aware heap like HeapMemMP or HeapBufMP [Note the "MP" to denote MultiProcessor aware]

    2.  Slice your DDR3 yourself so that DDR3 is split among your different processors in the system and don't collide.

    Judah