I think I can say we all love the little Memory Usage gauges introduced in MPLAB a couple of years ago.. or was it more?
When working in assembly with an 8-bit microcontroller and a couple of Kbytes of FLASH memory they definitely do their job, but when using the PIC24 or PIC32 type of devices, the memory space grows into the hundreds of Kbytes and things get … well, more complicated!
You start including a stack here (USB?) and a library there (Advanced Graphics), the compiler throws in a couple library modules of its own (math libs, stdio…) and both FLASH and RAM spaces become a little more crowded. It does not take long before we start wondering who is using up more memory, and why… the little memory gauges just don’t cut it anymore.
The experts will tell you right away that the sensible thing to do is to turn on the “map” option of the linker, (Project Build Options, Linker Tab, Select Diagnostics pane, then Check Create Map file) and inspect the resulting .map file in the editor window. But the text file generated is a pretty complex (and long) document and browsing through it in search of clues about what happened to our program and data memory can be quite hard work.
Fortunately with the latest version 1.05 of MPLAB C32 compiler there is a new option for the linker to produce a detailed summary of your project memory usage: –report-mem.
In the Project Options dialog box, select once more the MPLAB PIC32 Linker tab, then check the Alternate Settings checkbox and add: –report-mem to the beginning of the alternate settings string. Notice the double minus before the word “report” and make sure there are no spaces in between the two words but only another (single) minus sign before “mem”.
For example:
--report-mem --defsym=_min_stack_size=512 -o"$(BINDIR_)$(TARGETBASE).$(TARGETSUFFIX)"
Here is an example of the output you will obtain in the MPLAB Build Output window:
Microchip PIC32 Memory-Usage Report
kseg0 Program-Memory Usage
section address length [bytes] (dec) Description
------- ---------- ------------------------- -----------
.text 0x9d000000 0x838 2104 Application's executable code
Total kseg0_program_mem used : 0x838 2104 0.4% of 0x80000
kseg0 Boot-Memory Usage
section address length [bytes] (dec) Description
------- ---------- ------------------------- -----------
.startup 0x9fc00490 0x1e0 480 C startup code
Total kseg0_boot_mem used : 0x1e0 480 19.9% of 0x970
Exception-Memory Usage
section address length [bytes] (dec) Description
------- ---------- ------------------------- -----------
.app_excpt 0x9fc01180 0x10 16 General-Exception handler
Total exception_mem used : 0x10 16 0.4% of 0x1000
kseg1 Boot-Memory Usage
section address length [bytes] (dec) Description
------- ---------- ------------------------- -----------
.reset 0xbfc00000 0x10 16 Reset handler
.bev_excpt 0xbfc00380 0x10 16 BEV-Exception handler
Total kseg1_boot_mem used : 0x20 32 2.7% of 0x490
--------------------------------------------------------------------------
Total Program Memory used : 0xa48 2632 0.5% of 0x81e00
--------------------------------------------------------------------------
kseg1 Data-Memory Usage
section address length [bytes] (dec) Description
------- ---------- ------------------------- -----------
.stack 0xa0000000 0x200 512 Minimum space reserved for stack
Total kseg1_data_mem used : 0x200 512 1.6% of 0x8000
--------------------------------------------------------------------------
Total Data Memory used : 0x200 512 1.6% of 0x8000
--------------------------------------------------------------------------
Still pretty long and detailed, but way more readable and informative than the row data from the map file. Now you get to know, how much of the memory is really used up by your code, how much space is taken up by the interrupt vectors and exceptions management and so on…
