How big is my program?

23 Nov 2009

Is it possible to get the compiler to produce a report of how much code space and RAM is used by each module in a program together with the totals?

How much RAM is available for programs?

How much RAM is allocated to the stacks?

Is it possible to detect stack overflow, or at least report the high water mark?

Is dynamic memory allocation, such as malloc() supported? If so, how big is the pool?

Paul

23 Nov 2009 . Edited: 23 Nov 2009

Hi Paul,

Paul Griffith wrote:
How much RAM is available for programs? How much RAM is allocated to the stacks? Is it possible to detect stack overflow, or at least report the high water mark? Is dynamic memory allocation, such as malloc() supported? If so, how big is the pool?

I might ask you to hold that thought. The compiler does not report this information, but it sounds like something it should. We'll see if we can add this as a new feature.

At the same time i'll try and writeup a tutorial on memory/stacks/heaps, as it is an interesting area that is worthy of some proper explanation. It would also give context for the questions you are asking.

Some quickfire answers - if they don't make sense, then i'd wait until I get a chance to write up something properly.

Main RAM is 32k, with the RW/ZI regions at the bottom, and shared heap/stack filling the rest. Dynamic memory allocation is certainly usable (so malloc/free and new/delete both work fine). The memory will be allocated in the heap (and hence reduce the memory available for the stack).

More on this once we've had a chance to consider the possibility of the feature upgrade...

Simon

13 Jan 2011

I'm another one who would like to know how the available memory is allocated.  I have a program which has apparently random behaviour but which, from past experience, seems to me to possibly be due to RAM/heap/stack overlap.  I don't use any dynamically allocated memory (other than that implicit in the FILE handling procedures) but have a lot of variables and many procedures and functions.  This is the first C compiler I've ever used which does not report how much memory is used in the variables and the stack.  This is, IMHO, essential info needed when debugging a stubborn program!

13 Jan 2011

Hi Jim,

This is quite an old thread. Have you seen the Build Details tab we added a while back? Static memory usage only, but hopefully a help.

Simon

14 Jan 2011

Hi Simon,

Yes, I've seen that. Can I take it, then, that the stack builds down from the top (as is usual) so that, if there are no dynamic memory allocations, it extends all the way down to the top of the space allocated for variables. Are there any run-time checks to see if there is overlap?

Jim

14 Jan 2011

Hi Jim,

Yep, spot on. The stack grows down from the top of RAM. See:

The stack does not have any runtime checks, no. The stack pointer will just get updated as part of function epilogue/prologues, which often just comes down to a single push/pop instruction.

Simon

14 Jan 2011

Hi Simon,

Thanks for confirming this. Here's the problem. I have a fairly simple program, a few hundred lines, which behaves differently if I include a few diagnostic statements. I'm using two LCD's and the .printf function to update them. If I comment out a section with half a dozen .printf statements, the program behaves differently than when I leave them in. In the course of the running program, the LCD printf's are used very frequently. The program, generally, behaves similarly to other faults I've had in the past with other compilers when the stack overflowed into the RAM area. I read in the handbook that .printf uses malloc(). I know this is common in large computers but most microprocessor compilers rewrite the printf function so that it does not use the heap because of relatively limited memory. Since I can't debug 'normally' by setting breakpoints and have to use printf statements to do diagnostics and doing so changes the behaviour of the program, I'm stuck!

Jim

15 Jan 2011

What do you mean by 'behaves differently'? Does it crash (stop running) or does it something strange?

15 Jan 2011

The prgram has external interrupts so it doesn't behave exactly the same way every time.  But, the behaviour differs when I add or change the number of lcd .printf statementts which I use for diagnostics.  Sometimes, it crashes and (apparently) freezes and doesn't respond correctly to the interrupts; sometimes it just seems to have minor bugs.  The ONLY changes I make are by leaving in or commenting out the printf statements.  I intend to write my own version of the lcd.printf statements which does not use dynamic allocation of memory space to see if that is the problem.

16 Jan 2011

You need to remember that printf() takes time - it goes out to the PC via USB, which consumes a significant time (10 printf's can take several 10s or 100s of milliseconds). So it might just be that your printf statements alter the timing.

Regarding the occasional hangs: I know that there is a malloc problem (see here), which can cause crashes. I also have found that usage of some classes from the mbed libraries and some tools can cause freezes. E.g. NTPClient can eats nearly all memory, and recently I had the problem that LocalFileSystem interfered with some other code (leading to empty strings or frequent hangs). Each of these things seems to depend on the actual memory layout, so adding or removing e.g. printf statements changes the behavior sometimes (but not always).

Workarounds involve mostly creating the offending classes dynamically on demand and removing them as soon as possible, For NTPClient, I just reserver some memory beforehand and release it afterwards.

17 Jan 2011

I have now replaced all the lcd.printf statements with a function which writes floats and strings to my two LCD's.  I still have bugs in my program but it now looks like the behaviour is, at least, reproducable.  This makes me wonder if there is a memory leakage problem in the library .printf functions.  In my (previous) program, the .printf was called very frequenctly as I used it to display the position of a milling machine x, y and z axes.  The lcd update can be as infrequent as once every ten or twenty seconds to as much as several hundereds of times per second.  This meant that, previously, the lcd.printf calls were often very frequent so any memory leakage would manifest itself fairly soon.

17 Jan 2011

Hi Jim,

It would be good to get to the bottom of this. Were you using interrupts in your program at all? If so, were you ever calling printf from within them? Just wondering if this is actually just a re-entrancy/race condition of multiple things calling printf, rather than a problem with the function itself, as some of the reports in the thread don't quite add up.

If you have something that reproduces the problem you can share, that would be very useful so I could investigate this.

Thanks, Simon

17 Jan 2011

Simon might be right. Printing to a LCD also can be slow (depending on the type of display), and doing this might end in re-entrance problems (and I'm pretty convinced that the TextLCD library is not re-entrant). Also, the lcd printf() functions do dynamic memory allocation (to build the formatted string).

17 Jan 2011

Hi Simon,

 

17 Jan 2011

Hi Simon,

 

17 Jan 2011

Hi Simon,

No, the interrupts themselves do not generate the .prinf statements.  The interrupts are generated by rotary encoders which just change the value of some global variables; very simple interrupt routines.  However, the state machine of the main program does respond to these variable changes and every one eventually results in a printf statement.  For the most part every machine motion step (4000 steps per inch) generates a .printf statement and I believe it was the sheer number of these which made the problem apparent.

Sorry about the empty responses I've generated - finger trouble.

Jim