avr-nm output for EEPROM storage

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

Hi all,

 

As part of the output from my build process I am using avr-nm to generate a memory usage profile:

 

avr-nm --size-sort -r --demangle application.elf

 

My application uses 195 bytes of EEPROM, declared as follows:

 

static uint8_t EEMEM eeprom_device_address = 0;
static uint16_t EEMEM eeprom_max_level = MAX_LEVEL; 'Default MAX_LEVEL #defined in header file
static uint16_t EEMEM eeprom_data_table[192];

these variables appear in the avr-nm output as:

 

000000c0 d eeprom_data_table
00000002 d eeprom_device_address
000000c1 d eeprom_max_level

Some normal RAM variables in this output also have a 'd' symbol type.

 

Is there a way of making EEPROM variables appear as a separate symbol type to RAM in the profiler output?

 

Context: I am using a python tool to parse the profile output to visualise my memory usage. In order to not count EEPROM variables as RAM usage I am filtering for variables starting with the string 'eeprom_', but a more robust, less error-prone method would be an advantage.

Target microcontroller: ATMEGA328PB

avr-nm version: GNU nm (AVR_8_bit_GNU_Toolchain_3.5.4_1709) 2.26.20160125

avr-g++ version: avr-g++ (AVR_8_bit_GNU_Toolchain_3.5.4_1709) 4.9.2

 

Thanks!

 

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

I don't get it, how do those variables have 0 based addresses?

 

When I build this:

#include <avr/io.h>
#include <avr/eeprom.h>

uint16_t read_adc;
uint32_t foo EEMEM;

int main(void) {
    while(1) {
    }
    return 0;
}

I get this:

$ avr-nm avr.elf
00000068 t .do_clear_bss_loop
0000006a t .do_clear_bss_start
00000034 a __CCP__
0000003e a __SP_H__
0000003d a __SP_L__
0000003f a __SREG__
00000078 T __bad_interrupt
00800062 B __bss_end
00800060 B __bss_start
00000054 T __ctors_end
00000054 T __ctors_start
00000082 A __data_load_end
00000082 A __data_load_start
00000060 T __do_clear_bss
00000054 T __dtors_end
00000054 T __dtors_start
00810004 D __eeprom_end
00000000 W __heap_end
00000054 W __init
0000045f W __stack
00000080 t __stop_program
00000000 a __tmp_reg__
00000054 T __trampolines_end
00000054 T __trampolines_start
00000078 W __vector_1
00000078 W __vector_10
00000078 W __vector_11
00000078 W __vector_12
00000078 W __vector_13
00000078 W __vector_14
00000078 W __vector_15
00000078 W __vector_16
00000078 W __vector_17
00000078 W __vector_18
00000078 W __vector_19
00000078 W __vector_2
00000078 W __vector_20
00000078 W __vector_3
00000078 W __vector_4
00000078 W __vector_5
00000078 W __vector_6
00000078 W __vector_7
00000078 W __vector_8
00000078 W __vector_9
00000000 W __vector_default
00000000 T __vectors
00000001 a __zero_reg__
00800060 T _edata
00800062 B _end
00000082 T _etext
0000007e T _exit
0000007e W exit
00810000 D foo
0000007c T main
00800060 B read_adc

As you can see, EEPROM variables are based at 0x0081???? so searching for that should be enough to pick them out.

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

If the --size-sort option is used then nm displays size rather than address. But if I use the -S flag as well:

 

avr-nm --size-sort -S -r --demangle application.elf

It looks like I can get both size and address information and then use the address as you've suggested:

 

00000074 00000010 T __do_clear_bss
00000090 0000000a T main
00810000 00000004 D foo
00800100 00000002 B read_adc

 

Last Edited: Thu. Nov 10, 2016 - 08:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
As you can see, EEPROM variables are based at 0x0081???? so searching for that should be enough to pick them out.

And you have big D and OP has little d.  Because of the "static"?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Yeah, lowercase symbols are local, uppercase are global.