Get a complete memory map of a project (AS 6.1)

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

I have a quite large project, consisting of a dozen .c-files and 3 linked libraries.
The solution contains ...
- the main project
- 3 additional projects, each containing the routines for access to different peripheral chips.

The project compiles without problems and can be run.
Now I am fighting a strange error, where a variable does not contain the expected value and is changed from someone without intention.

The bad news: It is one of the static variables in a sub-project. :?

I expected to find the actual location of this variable (and others) in the .map-file of the solution
but it is not there.
The only information I have is the location from the .lss-file.
Q1: Is there a way to get a complete memory map for my project where all vaibales are listed with their location and their neighbours ?

Q2: One of my firrst ideas was to change the scope of this vairable temporarily to global until I find the reason why this varaiable gets changed without intention. But I fear, that this can change the complete memory map, so I can loose the suspiciscous code

I program like a man:
COPY CON: > firmware.hex

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

"static" limits name scope so it's not global and while it occupies space in either .bss or .data it will not be listed in the .map which is only for globals in .bss/.data.

As a temporary technique switch it from being a static within the function to a global so it will be visible in the .map

I haven't checked but I assume avr-nm is just as shy about naming statics as the linker's generation of .map is but is something that might be worth exploring.


Q2: One of my firrst ideas was to change the scope of this vairable temporarily to global

Ah, I should have read this far - yup I guess this is a concern and is probably why Schroedinger had so many dead cats in the back garden!

If you can identify the location of the static from the .lss then a data breakpoint might catch the rogue pointer/buffer overflow that is damaging it.

EDIT: to try the avr-nm thing I just wrote a test code:

int bbb(void){
	static int foo = 5;
	return foo++;

when I look at the .map it is (indirectly) mentioned:

                0x00800060        0x2 app.o

the reason it's there is because I happen to be building with -fdata-sections so it's been put into a* section on its own and named in the .map file so I think I just inadvertently discovered a solution to your problem ;-)

EDIT2: oh and for completeness if I remove -fdata-sections and build then it's true the .map does not name it but..

C:\Documents and Settings\asl\My Documents\Atmel Studio\ledblink\ledblink\Debug>avr-nm ledblink.elf
0000003e a __SP_H__
0000003e a __SP_H__
0000003d a __SP_L__
0000003d a __SP_L__
0000003f a __SREG__
0000003f a __SREG__
0000007e T __bad_interrupt
00000054 T __ctors_end
00000054 T __ctors_start
00800062 D __data_end
000000a2 A __data_load_end
000000a0 A __data_load_start
00800060 D __data_start
00000060 T __do_copy_data
00000054 T __dtors_end
00000054 T __dtors_start
00810000 D __eeprom_end
00000000 W __heap_end
00000054 W __init
0000045f W __stack
0000009e t __stop_program
00000000 a __tmp_reg__
00000000 a __tmp_reg__
00000054 T __trampolines_end
00000054 T __trampolines_start
00000001 a __zero_reg__
00000001 a __zero_reg__
00800062 D _edata
00800062 D _end
000000a0 T _etext
0000009c T _exit
00000082 T bbb
0000009c W exit
00800060 d foo.1519   <<<<<<<<