avr32avr32-gcc

How to interpret avr32-size output?

I have C program running on a AVR32 microcontroller (UC3C0512C). Issuing the avr32-size -A PROGRAM.elf command generates the following output:

PROGRAM.elf  :
section               size         addr
.reset                8200   2147483648
.rela.got                0   2147491848
.text                99512   2147491848
.exception             512   2147591680
.rodata               5072   2147592192
.dalign                  4            4
.data                 7036            8
.balign                  4         7044
.bss                  5856         7048
.heap                48536        12904
.comment                48            0
.debug_aranges        8672            0
.debug_pubnames      14476            0
.debug_info         311236            0
.debug_abbrev        49205            0
.debug_line         208324            0
.debug_frame         23380            0
.debug_str           43961            0
.debug_loc           63619            0
.debug_macinfo    94469328            0
.stack                4096        61440
.data_hram0            512   2684354560
.debug_ranges         8368            0
Total             95379957

Can someone explain how to interpret these values? How can I calculate the flash and ram usage based on this list?

Update 1:

Without the -A flag, I am getting the following:

   text    data     bss     dec     hex filename
 113296    7548   58496  179340   2bc8c PROGRAM.elf

Update 2:

I'm not using dynamic memory allocation, so according the avr-libc user-manual, the free RAM space should be simply: stackpointer minus __heap_start.

In this case: 61440 - 12904 = 48536 byte free RAM space.

Can someone confirm that?

Solution

  • (There is a mismatch in the two outputs in your question. The bss number is wildly different.)

    If you don't use malloc, and don't count the stack, then yes, the RAM usage is the data plus the bss (plus some alignment spacing). The data are the variables that are set in a declaration, and the bss are the variables that are not. The C runtime will probably initialize them to 0, but it doesn't have to.

    The flash usage will be the text and the data. That is, the flash will include the program instructions and C runtime, but also the values that need to get copied into RAM on startup to initialize those variables. This data is generally tacked onto the end of the program instructions.

    Re: update 2

    RAM holds global variables, the heap, and then the stack in that order.

    The global variables can be initialized in the program, or not. The .data section is stored in flash, and the C runtime copies these values into the beginning of RAM where the corresponding variables live before your code runs. The .bss section of global variables needs space in RAM to hold the values, but they aren't necessarily initialized. The C runtime that comes with avr-gcc does actually initialize these to 0. The point it that your don't need to store an array of 0s to copy over, as you do with the .data section.

    You are not using heap, but dynamically allocated memory is obtained from the addresses between heap_start and heap_end.

    But the stack is not limited. Yes, the stack-pointer is initialized at startup, but it changes as your program runs, and can move well into the heap or even into the global variables (stack overflow). The stack pointer moves whenever a function is called, or local variables within a function are used. For example, a large array declared inside a function will go on the stack.

    So in answer to your question, there is no RAM that is guaranteed to remain free.