• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Subscribers 100 subscribers
  • Views 1677 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.

Profiling RAM (static and dynamic)

Leonardo Gabrielli1
Expert 1275 points
Other Parts Discussed in Thread: CC3200, SYSBIOS

Hello,

I am progressing in developing features on cc3200 and i'd like to keep track of the current RAM usage to see how much spare memory I have for further features. How can I determine that? Furthermore is it possible to keep track of dynamic memory allocation during a debug session?

  • 0
    Expert 1275 points
    Uhm, I think I've been able to answer the question myself. In Debug mode, View --> Memory Allocation
    It seems quite sufficient to the task at the moment.
  • 0 in reply to Leonardo Gabrielli1
    Expert 1275 points
    Dear all, the Memory Allocation view is just saying what has been statically assigned in RAM at compile time according to the debug symbols. No idea of dynamic allocation. I ask again the question: IS there a tool for DYNAMIC memory view during debug?

    FURTHERMORE:

    I've been playing with malloc and HeapMem.
    My understanding is that with the Heap modules I can create a heap in the *.cfg file and later fill it up to its maximum size with dynamically allocated data.

    - I'm not sure, however, where malloc will put its data (I understand it uses one of the heap modules, it's made transparent to us).
    - I'm not sure, either, how to tell the heapMem_create which heap it should use
    - I see how to tell heapTrack_create which heap it should use (i.e. by saying prms.heap = <name of the heap>; ) but I get a problem in compiling as the name of the heap (defined in my .cfg file) is not known to the compiler (I followed the sysbios user guide example, spruex3o sec. 7.8.5)
  • 0 in reply to Leonardo Gabrielli1
    TI__Mastermind 27095 points

    Hi Leonardo,

    With respect to the Static memory allocation, the above steps on CCS would give you the correct information.

    For RTOS related heap allocation at runtime, I would move this query to TI-RTOS forum.

    Regards,
    Raghavendra

  • 0 in reply to Raghavendra Shenoy
    Expert 1275 points

    Thank you for moving to the TI RTOS forum. Let's see if answers arrive...

  • 0 in reply to Leonardo Gabrielli1
    Expert 1275 points
    I'm trying to ask the question again.
    Is there any way to measure dynamic memory allocation at runtime in a debug session in TI RTOS? Some way to log it, some dedicated tool or API? Nothing?
  • 0 in reply to Leonardo Gabrielli1
    TI__Mastermind 30830 points
    Have you tried using ROV to monitor the Heap?
    By default, a HeapMem instance is used as the Heap manager for the Memory module.
    You can view information about the HeapMem instance using ROV (total size, total free, etc).

    Alan
  • 0 in reply to Alan DeMars
    Expert 1275 points

    Ok, thank you, ROV seems to be quite complete to track down HeapMem instances.

    I briefly tried to see whether malloc is contemplated but it creates no HeapMem instance. I supposed so. Of course I could overload malloc with a my_malloc to mask all the HeapMem code (which is quite hard to read and untidy).  However my understanding about malloc is that it already masks some RTOS object to allocate memory. It would be cool if malloc would map to some RTOS object to view, so we can allocate memory hassle-free and still watch it in a debug session.

  • 0 in reply to Leonardo Gabrielli1
    TI__Mastermind 30830 points

    A version of malloc() is provided by TI-RTOS that internally calls Memory_alloc(), which, in turn, calls HeapMem_alloc().

    This version of malloc() is linked with prior to the RTS library version of malloc() so it gets used rather than the RTS library version.

    Consequently, malloc() calls do affect the HeapMem ROV view content as you wish.

    Alan

  • 0 in reply to Alan DeMars
    Expert 1275 points

    This is what I was hoping for. In my test I can't verify this, though.

    Maybe I'm not linking the way you suggest? We are building a project containing all the libraries and the includes, maybe in the linking we are taking the RTS malloc and not the TI-RTOS one...

    The project ARM Linker / File search path looks like:

    - libc.a

    - "${ORIGINAL_PROJECT_ROOT}/libs/driverlib.a"

    - "${ORIGINAL_PROJECT_ROOT}/libs/simplelink.a"

    - "${ORIGINAL_PROJECT_ROOT}/libs/osilib_ti_rtos.a"

    So maybe it takes the default libc implementation of malloc first?

  • 0 in reply to Leonardo Gabrielli1
    Expert 1275 points
    Ok, I verified that the field head/next$fetchDesc/next in the heapmem instance tells the next address that is free and from this I can evaluate how much space is left in the default heap.
  • 0 in reply to Leonardo Gabrielli1
    TI__Mastermind 30830 points
    Did you determine which malloc() is being used? If not, you can use the disassembler window to confirm if malloc() is calling Memory_alloc().
    If you have already moved past this point and feel that the issue raised in this thread has been adequately addressed, please mark this thread as 'answered'.
    Alan
  • 0 in reply to Alan DeMars
    Expert 1275 points
    This is what is being called: xdc_runtime_Memory_alloc(...), which in turn calls a file Memory.c (part of CCS) where the malloc actually implemented.
    It doesn't seem to be part of HeapMem, but at the end I see the heap getting filled...
  • 0 in reply to Leonardo Gabrielli1
    TI__Mastermind 30830 points

    Its a little convoluted but the Memory_alloc() thread eventually calls HeapMem_alloc(), which is why you see the HeapMem ROV view change whenever malloc() is called.


    If you feel that your question has been answered, please mark this thread 'answered'.

    Alan