Monitoring memory usage

Go To Last Post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm in the process of cleaning up my code's memory usage and want to see how my changes affect how much RAM and Flash is used in my MCU. The avr-size tool called automatically during build tells me some sizes, but doesn't include all the custom sections I have defined for things like locating const variables and certain functions to specific areas of flash. Thus the numbers for my Program and Data usage are inaccurate.

Is there a way to have this tool generate a neatly formatted summary for all my custom sections? For example, Data would be .data + .bss + .noinit + .customsection1

The --help summary didn't show anything that I could do, but I figured I'd ask.

I see that tools like avr-readelf will allow me to display a summary of ALL sections and sizes, but it would be nice to have something quick and dirty that I can check at a glance at the end of my build process.

If anyone knows how to customize avr-size or otherwise how to display a quick summary of RAM and Flash usage, it would be appreciated.

Otherwise I'll just run avr-readelf and add up the numbers for now.

Thanks in advance!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Try using -A on the avr-size invocation (rather than -C). This just gives you something like:

test.o  :
section           size   addr
.text              282      0
.data               61      0
.bss                 0      0
.debug_abbrev      438      0
.debug_info        633      0
.debug_line        374      0
.fred                8      0
.debug_frame        96      0
.debug_loc          94      0
.debug_pubnames    108      0
.debug_aranges      32      0
.debug_str         270      0
Total             2396

.fred in that is some data I just added:

char fred[] __attribute__((section(".fred")))= { "testing" };

The -C patch just conglomerates specific sections (.text+.data+.bootloader) but if you pull the source of avr-size and the patch you should be able to rebuild it for your own sections (maybe add a -D or something?)

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

look for data_load_end in your elf file, and you can see how much flash is used, there one for ram, I think it's _end.

Because you can't predict how much stack is used before running if you use lots of co-recursion like me, you can see it at runtime.

To see how much stack is free at runtime I use this:


#define MAGIC 0x5A
/* calculate free space */
int ramusage_free(void *start)
{
   /* traverse from fartest stack can grow until it is no
      longer set to MAGIC */
   char *p;
   for(p = (char*)start; p <= (char*)&p; p++)
      if(*p != MAGIC)
         break;

   return p - (char*)start;
}

void ramusage_init(void *start)
{
   /* initialize from our current location on stack to the
      farthest the stack can grow */
   char *p;
   for(p = (char*)start; p < (char*)&p; p++)
      *p = MAGIC;
}

Then sometime at startup call:

ramusage_init(&_end);

then whenever you want to see how much stack you didn't use yet:

ramusage_free(&_end);
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For the size of code flash maybe check the .map for "_exit" ?

"_end" or "_heap start" also work for the stuff in RAM (minus __data_start)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson: That sounds good. I'll have to check into just recompiling the avr-size source.

geckosenator: Coincidentally, the whole motivation for re-examining memory usage was because a new feature ended up not working because memory got trashed by the stack growing too large. I'll have to give your suggestion a try.

Thanks!