• State Answer Suggested
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 1627 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 can I understand how CCSv6 and the TI C compiler estimate RAM usage?

Leo Oxvox
Intellectual 460 points
Other Parts Discussed in Thread: MSP430I2020

I'm having a lot of trouble understanding how CCSv6 and the TI C Compiler are estimating RAM use.  I'm using the MSP430i2020 and my project is fairly straightforward when it comes to RAM usage, by which I mean that I'm not using malloc() or creating new objects at any time. (The MSP430i2020 has 1024 bytes of RAM in the address range 0x200 to 0x599.)

Here's the Console message I get after a build:

MSP430: Loading complete. There were 3005 (code) and 58 (data) bytes written to FLASH/FRAM. The expected RAM usage is 1023 (uninitialized data + stack) bytes.

That looks pretty tight on RAM!  But here's the top of the MEMORY CONFIGURATION table in the .map file. It seems to say I have 200h = 518 unused bytes in RAM:

Below is a spreadsheet I made from the section of the .map file showing global variables which is where all my transient application data is kept. It shows that with an 80 byte stack, I have 518 bytes unused byes of RAM.  So what's up?  What does that message say from the build?!

Thanks!

Leo


  • 0
    Guru 92251 points

    Leo Oxvox said:
    I'm having a lot of trouble understanding how CCSv6 and the TI C Compiler are estimating RAM use.

    As of CCS 6.1 the "MSP430: Loading complete. There were <x> (code) and <y>(data) bytes written to FLASH. The expected RAM usage is <z> (uninitialized data + stack) bytes." message reported by CCS when starting a debug session gives an overestimate of the RAM usage. I haven't determined why the CCS message gives an overestimate of the RAM usage, but there is an open defect on CCS. See https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/458469/1652630#1652630.

    Until CCS is fixed, the memory size calculated from the .map file will give a reliable indication of the actual memory usage.

  • 0
    Guru 92251 points

    Leo Oxvox said:
    Below is a spreadsheet I made from the section of the .map file showing global variables which is where all my transient application data is kept. It shows that with an 80 byte stack, I have 518 bytes unused byes of RAM.

    Rather than creating a spreadsheet from the sections in the .map file, one option is to use the CCS Memory Allocation view (from the menu View -> Memory Allocation).

    The Memory Allocation view sums the total memory usage from the output of the TI linker, and also allows the size of each item in the sections to be viewed.

  • 0 in reply to Chester Gillon
    Intellectual 460 points

    Thanks Chester. It was disconcerting not to know which numbers to believe. My search didn't show me that case. I'll keep my eyes on it.

    Leo

  • 0 in reply to Chester Gillon
    Intellectual 460 points
    I like that! I hadn't seen it before.

    One thing - I looked at the other thread you pointed out but wasn't sure how to follow it. I didn't see a "follow this" icon or anything. Does Likeing something put me on the email list for additions?

    Thanks again,
    Tom
  • 0 in reply to Leo Oxvox
    Guru 58965 points

    I think it is very difficult to estimate how much RAM is needed for the stack or the heap. CCS does not even try to estimate that. You can set the "stack size" and "heap size" or use their "default value" of 80 and 80 bytes. They mean "If I use this much, do I have enough RAM?"

  • 0 in reply to Leo Oxvox
    Guru 16361 points

    Leo Oxvox said:
    One thing - I looked at the other thread you pointed out but wasn't sure how to follow it. I didn't see a "follow this" icon or anything. Does Likeing something put me on the email list for additions?

    No, but you can follow a thread by clicking on the options button in the right sidebar. You can toggle reply notifications there (I think those are sent to the email address linked to your account). Also you can bookmark the thread, which makes it appear in the bookmarks drop-down menu in the top-right toolbar.

  • 0 in reply to Robert Cowsill
    Guru 58965 points

    What is your estimate of stack size for this code here?

    #include "msp430.h"

long long fact(long long n);

long long main(void)
{
  long long ans;
  ans = fact(12);
  return ans;
}

long long fact(long long n)
{
  long long ans;
  if (n) ans = (n*fact(n-1));
  else ans = 1;
  return ans;
}

    What does CCS say?

  • 0 in reply to old_cow_yellow
    Intellectual 460 points
    Where is the heap size controlled? I wasn't really thinking of that. It's not used at this stage of the project, but it possibly will be used later. I don't see it anywhere in the .map file.
  • 0 in reply to Leo Oxvox
    Guru 92251 points

    Leo Oxvox said:
    Where is the heap size controlled?

    When using the TI compiler, the amount of memory allocated for the heap is set in the CCS project properties -> Build -> MSP430 Linker -> Basic Options -> Set C system stack size (--stack_size, -stack).

    Leo Oxvox said:
    I don't see it anywhere in the .map file.

    The memory allocated for the heap is shown in the .map file as the .sysmem section. If the program doesn't use the heap, the .sysmem section won't be shown in the .map file.

  • 0 in reply to old_cow_yellow
    Guru 92251 points

    old_cow_yellow said:
    I think it is very difficult to estimate how much RAM is needed for the stack or the heap. CCS does not even try to estimate that.

    Agreed that CCS doesn't attempt to estimate how much RAM is needed for the stack or the heap.

    However, there is a standalone tool call_graph as part of cg_xml which can help to statically determine the worst case stack usage - see Finding out static stack usage.

    If the program contains recursion, then call_graph gives you a warning message about how the script cannot compute worst case stack depth in this case.

  • 0 in reply to Chester Gillon
    Guru 58965 points
    Chester,

    Thank you for pointing that out.

    I can see that it is a daunting task to do such analysis. Theoretically, some of the apparent "worst case" can never occur in any situation. But they can even be mistaken as recursion. Things like that are almost impossible to detect. The specific compiler's ability to "optimize" or inefficient usage of stack can also make the estimate go wrong. And function pointers? ...

    I am just a hobbyist. I really shouldn’t address subjects like this one.

    Happy New Year,

    -- OCY

**Attention** This is a public forum