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/SW-EK-TM4C1294XL: TI-RTOS Object View (ROV)

Part Number: SW-EK-TM4C1294XL
Other Parts Discussed in Thread: SYSBIOS

Tool/software: Code Composer Studio

After running the example of memory_EX_TM4C1294XL_TI. I don't understand how to interpret the results or their relationship: one is from the Console and the other is from ROV. 

1).Why they are different from each other in all the sizes;

2) Why in the ROV view, all the 3 sizes are always the same without changes?

Thanks,

different sizes.docx

  • Hi Neil,

    The first row in ROV->HeapMem is the system heap that is not being used in the example. The second row is the HeapMem heap that is used by task1Fxn. I expect the you looked at ROV after the test was ran. The 2nd HeapMem free and largest where 512 at the beginning and went lower during the allocation, but returned to those levels after all the allocated memory was freed.

    The expected you looked at ROV in main before the 2nd HeapMem was constructed. So when you ran to completion, the numbers in ROV changed (thus the red lettering).

    Note: task0Fxn uses a HeaBuf heap.

    Todd
  • Thank you, Todd, for your timely response, but I am still confused as follows:

    1. How can you tell the first row is system heap?  Is first row always system heap?  or by the address in .cfg. file? or something else you can quickly know it is system heap?

    2. Can ROV show different values among totalSize, totalFreeSize, and LargestFreesize?

    2. 2nd row is allocated 512 bytes with red color, and here is my 2nd question: 1) why the LargestFreeSize = 32 for both Initial task0 heap status and Final task0 heap status?  I understand Initial should be before the memory is allocated for the buffer and it should be 64, instead of 32.  we understand the Final should be after the memory has been taken and it should be 32.

    3. For question 2, after spending a few hours to trace the original code, and finally figure out the "LargestFreeSize" in the example memory_EK_TM4C1294XL_TI is a miss leading and it should be "Largest Block Size" as the code shows "stats->largestFreeSize   = (obj->numFreeBlocks > 0) ? obj->blockSize : 0;" .

    4. Does ROV have the same issue like Question 3, use Largest Block Size as Largest Free Size?

    Thanks.

  • Neil Lu said:
    1. How can you tell the first row is system heap?  Is first row always system heap?  or by the address in .cfg. file? or something else you can quickly know it is system heap?

    No. The order in ROV is order of creation. I knew the system heap was statically created, so it would be first.

    Neil Lu said:
    2. Can ROV show different values among totalSize, totalFreeSize, and LargestFreesize?

    Yes. Do a couple allocs and you will see the values change accordingly.

    Neil Lu said:
    2. 2nd row is allocated 512 bytes with red color, and here is my 2nd question: 1) why the LargestFreeSize = 32 for both Initial task0 heap status and Final task0 heap status?  I understand Initial should be before the memory is allocated for the buffer and it should be 64, instead of 32.  we understand the Final should be after the memory has been taken and it should be 32.

    Task0 is using HeapBuf. You are looking at HeapMem. Look at HeapBuf and those values should match up. HeapBuf manages fixed size buffers, so the largest is a single fixed size. The example creates the HeapBuf with a fixed size of 32 (TASK0BUFSIZE).

    Neil Lu said:
    3. For question 2, after spending a few hours to trace the original code, and finally figure out the "LargestFreeSize" in the example memory_EK_TM4C1294XL_TI is a miss leading and it should be "Largest Block Size" as the code shows "stats->largestFreeSize   = (obj->numFreeBlocks > 0) ? obj->blockSize : 0;" .

    ?

  • Neil,

    Did the above answer your questions?

    Todd

  • Thank you, Todd, I am satisfied for your answers, but there still are some questions about these terms, which are very confusion.  Let us look the HeapBuf picture  I got: 

    Q1: he HeapBuf_construct fun creates 2 block heapBuf.  the Block size is 32, but the "numberAllocatedBlocks" is 0, instead of 2 as we know it just allocated 2 heap buffer blocks.

    Q2.Why is "maxAllocatedBlocks" 0, instead of 2 or some other number the system can handle?  What is the meaning here?  

    Thanks, 

  • Hi Neil,

    Here is the full construct code

    #define HEAPBUFSIZE     64
    
    HeapBuf_Params_init(&heapBufParams);
    heapBufParams.blockSize = HEAPBUFSIZE / 2;
    heapBufParams.numBlocks = 2;
    heapBufParams.align = 8;
    heapBufParams.buf = heapBufBuffer;
    heapBufParams.bufSize = HEAPBUFSIZE;
    HeapBuf_construct(&heapBufStruct, &heapBufParams, NULL);

    So there so each block is 32 bytes and there are 2 of them. Note: heapBufBuffer is 64 bytes. We do the align trickery to make sure this works on all of the TI devices. 

    Neil Lu said:
    Q1: he HeapBuf_construct fun creates 2 block heapBuf.  the Block size is 32, but the "numberAllocatedBlocks" is 0, instead of 2 as we know it just allocated 2 heap buffer blocks.

    When no blocks are allocated, ROV shows numFreeBlocks = 2 and numberAllocatedBlocks=0. If you were to allocate one block, you'd see the numbers go to  numFreeBlocks=1 and numberAllocatedBlocks=1. When you did the allocate, it would give you one 32-byte block.

    Neil Lu said:
    Q2.Why is "maxAllocatedBlocks" 0, instead of 2 or some other number the system can handle?  What is the meaning here?  

    You need to enable this tracking feature. Set HeapBuf.trackMaxAllocs to true in the .cfg file. We default it to false to improve performance and minimize memory.

    Todd

  • Thank you, Todd, I could not find HeapBuf.trackMaxAllocs in the memory.cfg file

    The following is the only code relative to HeapMem

    /* ================ Application Specific Instances ================ */
    var HeapMem = xdc.useModule('ti.sysbios.heaps.HeapMem');
    var HeapBuf = xdc.useModule('ti.sysbios.heaps.HeapBuf');

    Neil

  • You can either add it in the .cfg file (if you are editing it as a text file)

    HeapBuf.trackMaxAllocs = true;

    Or if you are using XGConf, click the box I high-lighted in yellow. This will add the line into the .cfg.

  • Thank you, Todd, you are absolutely correct and a great resource.  I did add HeapBuf.trackMaxAllocs = true; and got the result!  

    It seems that ROV does not capture any error.  I tried to change TASK0NUMBUFS  to 5 which is beyond the heapbuf number block 4 and I still got 4 blocks allocated as shown in the picture.

    #define TASK0BUFSIZE 32 /* size of allocations */
    #define TASK0NUMBUFS 5 /* number of buffers */

  • TASK0NUMBUFS is the number of allocs task0 will do in the following loops. It cannot be more than the number of blocks in the heap.

        for (i = 0; i < TASK0NUMBUFS; i++) {
            bufs[i] = Memory_alloc(heap, TASK0BUFSIZE, 0, NULL);
        }
    
        /* Free memory blocks */
        for (i = 0; i < TASK0NUMBUFS; i++) {
            Memory_free(heap, bufs[i], TASK0BUFSIZE);
        }
    

    If you try to do 5, you'll get a memory allocation error. Since the alloc was not successful, the maxAllocatedBlocks does not increase.

  • Thank you, Todd, the following is what I got from the program itself instead of CCS or ROV, when 5 was used:

    Memory example started.

    Initial task0 heap status

    largestFreeSize = 32

    totalFreeSize = 128

    totalSize = 128

    xdc.runtime.Memory: line 52: out of memory: heap=0x20001900, size=32

    xdc.runtime.Error.raise: terminating execution

  • Neil,

    That makes sense. You attempt to allocate 5 blocks from a heap that only had 4 blocks. Sense NULL was passed into the Memory_alloc, the application terminated on the failure. If you had passed in an initialized Error_block into the Memory_alloc, the API would have returned with a NULL. Note: in either case the maxAllocated stays at 4 since a failed allocation does not impact the maxAllocated blocks. Note: maxAllocated is a high-water mark, not the total number of times you allocated a block.

    Todd

  • Thanks, Todd, from the example memory.c, Is this feeling right?  1) system heap is created by TI-RTOS for its use only? 2) when using TI-RTOS to program applications, applications can only construct heapBuf and heapMem heaps for application use?  Thank you, 

  • Hi, Todd, in this initial TI-RTOS memory heap study, I get 4 types of heaps: System Heap, HeapBuf, HeapMem, and HeapTrack (smartHeap).  Is my guess right?  System Heap is constructed by OS and it is used by OS only?  HeapBuf and HeapMem are constructed by applications and they are used for applications?  HeapTract is used by ROV tool and it is used to collect the heap usage information from system heap, HeapBuf and HeapMem?

  • Neil,

    By default, the RTOS creates one system heap (also called the default heap). This is used, by default, by the kernel. It can be used by the application also via malloc or Memory_alloc(NULL, blah, blah, blah). 

    Additional heaps can be created by the application. They can be of type HeapMem, HeapBuf, etc. HeapTrack sits on top of another heap. For example, in the video I showed how to have a HeapTrack instance sit on top of the system heap. If you want a HeapTrack instance to sit on top of another heap instance, you have to set it up yourself (e.g. create a HeapBuf instance and then supply that handle to the parameters for the HeapTrack instance creation).

    Todd

  • Thank you, Todd, excellent explanation.  

  • Can system Heap be monitored in ROV?

  • Yes. Look in ROV->HeapMem (assuming you used the default configuration). If you see more than one (that means you created more), you'll need to figure out which one is which.

    Todd