• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 101 subscribers
  • Views 1093 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.

How to interpret ROV HeapMemMP data

Geraldine Maclear
Expert 2145 points

Other Parts Discussed in Thread: SYSBIOS

Hello,

I am writing the C674x DSP code for a DM816x.  We're using sysbios 6.32.05.54, ipc 1.23.05.40 and CCS 5.1.0.09000.

I am looking for the cause of this error:

[C674X_0] ti.sdo.ipc.heaps.HeapMemMP: line 740: E_memory: Out of memory: handle=0xf80edae0, size=1184

This error happens after a call to "MessageQ_Msg MessageQ_alloc(UInt16 heapId, UInt32 size);" in ipc_1_23_05_40\packages\ti\ipc\MessageQ.h.

I have examined the heaps by stopping the processor using JTAG and loading the ROV view. I click on the HeapMemMP option and I see the data in the attached .bmp file.

How should the all the fields (especially "address", "buf" and "totalSize") be interpreted? The values don't look good to me, somehow:

addr         buf        totalSize

0xf80ed428  0x87000680  0xfff980

0xf80ed458  0x9f900080  0xfff80

0xf80eda00  0x8700a500  0x10080

0xf80edae0  0x8701a580  0x10080

If I change BIOS.heapSize from  0x2000000 to 0x3000000 in my project .cfg file, the values in the ROV HeapMemMP view do not change.

These are heap-related settings in my .cfg file:

var HeapMem = xdc.useModule('ti.sysbios.heaps.HeapMem');
var heapMemParams = new HeapMem.Params;
heapMemParams.size = 0x4000;
heapMemParams.sectionName = "IRAM";
Program.global.roomProcessHeap = HeapMem.create (heapMemParams);  

var HeapMemMP = xdc.useModule('ti.sdo.ipc.heaps.HeapMemMP');
SharedRegion.setEntryMeta(SHAREDREG_1_ENTRYID,
    {
      base:        SHAREDREG_1_MEM,
      len:         SHAREDREG_1_MEMSIZE,
      ownerProcId: SHAREDREG_1_OWNERPROCID,
      isValid:     true,
      name:        "shared_region_1",
      createHeap:  true
    });

Thanks,

Annie

 



  • 0
    TI__Mastermind 30830 points

    BIOS.heapSize defines the size of the HeapMem instance created by SYS/BIOS for use when dynamically creating SYS/BIOS objects (ie Tasks, Semaphores, etc).

    You will see changes you make to BIOS.heapSize reflected in one of the HeapMem ROV instance views.

    I believe the error you're getting is associated with the HeapMemMP instance that uses the SharedRegion configuration you show.

    To increase the size of this HeapMemMP instance, I think you need to find the declaration of SHAREDREG_1_MEMSIZE in your config file and increase its value.

    Alan

  • 0 in reply to Alan DeMars
    Expert 2145 points

    Alan - thanks for your reply. I will try changing the shared region config.

    I'd still like to know how all the fields in the ROV display (especially "address", "buf" and "totalSize") should be interpreted? With the values in my display it looks like the heaps will be stomping on each other. Is that right?

    Thanks,
    Annie

  • 0 in reply to Geraldine Maclear
    TI__Mastermind 30830 points

    Yes, there certainly seems to be a conflict between the first region and the third and fourth regions.

    Can you share your config file? Or at least everything pertaining to HeapMemMP?

    Alan

  • 0 in reply to Alan DeMars
    Expert 2145 points

    Hi Alan - I am attaching my complete .cfg file.

    0728.myCfg.cfg

  • 0 in reply to Geraldine Maclear
    TI__Mastermind 30830 points

    Can you also provide your platform's memory region definitions?

    I don't see where the other two HeapMemMP buffers are coming from.

    Alan

  • 0 in reply to Alan DeMars
    Expert 2145 points

    Alan, I am having trouble find this.

    The "HeapMemMP" variable defined in the .cfg file is not used elsewhere in the project.

    The linker command file which I have created only defines where some sections are placed in memory.

    The generated "linker.cmd" file has only this line related to HeapMemMP:

    --symbol_map ti_sdo_ipc_heaps_HeapMemMP_isBlocking__E=ti_sdo_ipc_heaps_HeapMemMP_isBlocking__F

    I have looked at the platform using Tools, RTSC Tools, Platform, Edit/View  and it just defines the big chunks of memory.

    Could you tell me where else to look?

    Thanks,
    Annie

  • 0 in reply to Geraldine Maclear
    TI__Mastermind 32475 points

    Annie,

    How many SharedRegions are there in your app (You could use ROV to view this too)?  A HeapMemMP heap is created for each SharedRegion by default.

    In your app are you doing a HeapMemMP_create() or HeapMemMP_open() at any point?

    Judah

  • 0 in reply to judahvang
    Expert 2145 points

    Judah, we have two shared regions defined in the .cfg file (the full .cfg file is attached to this issue). I assume the documentation will give details about the default HeapMemMP created for these?

    Yes, I see that we are doing a HeapMemMP_open in one of the files. I will follow that lead to see if we're using sensible values for it.

    I'd still like to know how all the fields in the ROV display (especially "address", "buf" and "totalSize") should be interpreted? Could you provide these details, then I'll resolve this issue.

    Thanks,
    Annie

  • 0 in reply to Geraldine Maclear
    TI__Mastermind 32475 points

    Annie,

    Each SharedRegion has a HeapMemMP created for it by default.  If you don't want a heap in it, you can tell it to not create heap when you add the SharedRegion in your .cfg file.

    "address" - this is the address of the HeapMemMP instance

    "buf" - This is the heap in shared memory

    "totalSize" - The length of the heap.

    From the ROV view, I do see that you have 4 HeapMemMP instances.  However, it looks like the last 2 instances are created within the 1st HeapMemMP  I think what it looks like is that you have a huge SharedRegion0 which contains a HeapMemMP.  Then you allocate a portion of the HeapMemMP from SharedRegion 0 and you create a smaller HeapMemMP instance from it.  Looks like this is done twice.  The error you are getting seems to state that the last HeapMemMP instance you created has ran out of memory.

    Judah

  • 0 in reply to judahvang
    Expert 2145 points

    Alan and Judah - thanks for your help. I have enough information to investigate this now.

    Annie.