Does any one know which of the files generated on M2M Studio contains the memory map?
In a previous topic you guys talked about a “m” file:
http://www.wavecom.com/modules/movie/scenes/forums/viewtopic.php?f=19&t=514&hilit=map
IT’S NOT GENERATED ON M2M STUDIO!!! 
I want to know where each global variable is stored to access them directly.
Some idea better than “try-fail” metod?
Please make sure you are running 1.0.2 version.
Once your application is built, you get (among others) 2 files in the output directory:
- .symbols - alphabetical list of symbols with corresponding addresses
- .map - more detailed map file of your application, generated by the linker
Please note that these files are obviously “valid” for the current build only… The addresses may change on any code modification.
Hi daav,
Thanks for your response. I have some problems with your answer:
[*]The file .map doesn’t have all variables information. It also doesn´t have information of the variables size variables. It’s essential for my own tools.
[]The file .symbols doesn´t have information of the variables size.
[]Files are inconsistent. For example:
In *.symbols:
adl_InitApplicationVersion 00246480In *.map:
0x00246484 adl_InitApplicationVersionThanks in advance for your replies.
It may well be that these are down to the underlying tools themselves (GCC, et al) - and nothing specifically to do with M2MStudio as such… 
Right: *.map and *.s_raw (see below) files are generated by GCC tools.
You’re right. It seems there is an issue in the *.symbols file generation. Please consider that the *.map file owns the correct value. You also have a non-processed *.s_raw file which contains a non-sorted list of the symbols, in which values are also correct.
I log the bug for correction in next release.
True, but you can deduce a symbol size just by looking for the address just after your symbol’s one in the .map/.s_raw file (since the .symbols one is corrupted)
e.g. I get in a .s_raw file:
00270fa0 T adl_InitApplicationVersion
00270fa8 T adl_InitCompanyNameThe size of the adl_InitApplicationVersion symbol is 8, since the next address is 00270fa8.
Please can you elaborate on what information is missing for you?
Is that true?
Is the compiler (linker?) actually prohibited from leaving gaps in the memory map? (I guess they would generally try to avoid it - but is it actually prohibited?)
Even so, this would be the size after any extra padding for alignment, wouldn’t it?
Well, it’s not always true. You’re right that due to padding, the size deduced from this method can sometimes be greater than the real one.
To have real size information, you can use the nm utility. (you can get it from the /plugins/com.wavecom.openat.ide.ebs.build.core.win32_xxxx/os/win32 M2M studio sub-directory)
nm.exe -n -S <project>.axfwill print the symbols list, sorted by address, with size information. I will catch this output to the .s_raw file in order to add the size information, can be usefull.
I don’t know if ARM memory structure allows you to access to any address. Usually ucontrollers allows you to access as bits a small part of the memory and as byte a limited part of the memory. The not bit/byte addressable memory is “word” (whatever it means to each ucontroller) addressable. Ussually compilers/linkers, if they don’t have enough memory of one type, reserve next bigger addressable “step” to smallers variables. So I find size deduction dangerous, as awneil has indicated. 
This a post-processor? It must be run after each building? Does exists any way to automate it?
Please if this is done on future releases, please consider to give the position and sizes of each element of an struct.
Self generated variables doesn’t appear with their names on *.map file. Just two or there.
Yes to both questions. You can add a post builder (as explained in topic viewtopic.php?f=78&t=3121&start=15#p13669):
- invoke nm.exe
- Working directory: set ${project_loc:/[Target]_ARM_ELF_GCC_Debug} (or other directory if you use another configuration)
- Arguments: -n -S .axf
- Don’t forget the refresh tab
- Redirect the output to a file (e.g. ${project_loc}/symbols.txt)
Actually, there isn’t any option for nm to include struct details…
Hum… please can you elaborate on what you call a self-generated variable?
I mean any variable I include in my code. In *.map I only can find the constants (const), and adl internal variables(I think they are variables but I’m not sure).
Thanks
The map/symbol file only includes global/static variables. Local variables addresses are not constant, and cannot be listed in such a map…
Of course local variables are not listed. But, why static are not listed? They use a fixed space in memory, and are listed in *.symbols and *.s_raw file.
You’re right, the linker doesn’t provide informations on static variables in the map file. However, you have the information in the symbol files, so it’s OK, isn’t it 
I’ll try, but I don’t know when. This is a development tool, not a customer tool… You know. 
I know ! 
By the way, please note that it’s planned to include more information on the build output in future M2M Studio releases, in an easier way than greping the symbol/map files
I think the generated files are in the standard AXF format - so any standard tools can be used to examine them?
eg, objcopy and objdump…
Indeed you can. AXF (ARM “specific”) is actually similar to ELF format.
In M2M 1.1.0, *.map file and *.s_raw file contains coherent information!!! 
Well done guys!!!
Thank you, we’ve paid attention to fix this particular point.
Please note the *.symbols (filtered and sorted version of *.s_raw for TMT usage) file content is also fixed, and the *.s_raw file now contains symbol size information.
Not for all. Most of the symbols have the size, but some are missed:
180c09f2 00000001 B cpLastReset
180c0aa4 b cpBus_queueIn my projects *.symbols file is empty.
Anyway, thanks a lot to the priority you gave to this issue.