Not applicable
Jan 13, 2016
07:51 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 13, 2016
07:51 AM
Hi All,
Happy new year.
I'm looking for a way to display how much program and data storage memory has been used after compiling in DAVE 3.
Thanks very much
Aaron
Happy new year.
I'm looking for a way to display how much program and data storage memory has been used after compiling in DAVE 3.
Thanks very much
Aaron
- Tags:
- IFX
14 Replies
Jan 13, 2016
07:58 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 13, 2016
07:58 AM
Hi,
I don't know the situation in DAVE 3, but in DAVE 4 you find a .lst file in the Debug folder. There should be something similar in DAVE 3.
Regards
elm0
I don't know the situation in DAVE 3, but in DAVE 4 you find a .lst file in the Debug folder. There should be something similar in DAVE 3.
Regards
elm0
Not applicable
Jan 13, 2016
08:09 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 13, 2016
08:09 AM
Thanks elm0, I did look at the .lst file but it is pretty big. I searched for obvious keywords like PSRAM but failed to find the information. Do you know where to look in the file or keywords to search for ?
Jan 13, 2016
09:03 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 13, 2016
09:03 AM
Right at the beginning, there should be a summary of the sections with information about size, VMA (virtual memory address) and LMA (load memory address) for each. This are the sections specified in the linker script. Usually, the .text section contains the program data, the .data section contains initialized data and the .bss section contains uninitialized data.
The LMA shows where the section is loaded by the debugger (or whatever programming device), the VMA shows where the section is expected to be by the compiled code. For example, the .data section contains the data which shall be available in the DSRAM (VMA) during code execution, but it has to be stored in the non volatile Flash (LMA). Thus, somewhere in the startup code, there is a procedure which copies the data from the loaded flash location to DSRAM.
On the other hand, for the .bss section containing uninitialized data, the LMA doesn't matter, because the memory space is only allocated.
Maybe (as it is in my DAVE 4 XMC4000 projects), there might be some other sections predefined in the linker script, containing special program code or data. At the end, you need to sum by hand. At least that is how I do.
The LMA shows where the section is loaded by the debugger (or whatever programming device), the VMA shows where the section is expected to be by the compiled code. For example, the .data section contains the data which shall be available in the DSRAM (VMA) during code execution, but it has to be stored in the non volatile Flash (LMA). Thus, somewhere in the startup code, there is a procedure which copies the data from the loaded flash location to DSRAM.
On the other hand, for the .bss section containing uninitialized data, the LMA doesn't matter, because the memory space is only allocated.
Maybe (as it is in my DAVE 4 XMC4000 projects), there might be some other sections predefined in the linker script, containing special program code or data. At the end, you need to sum by hand. At least that is how I do.
Not applicable
Jan 14, 2016
12:05 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 14, 2016
12:05 AM
Thanks elm0.
Not applicable
Jan 14, 2016
12:31 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 14, 2016
12:31 AM
Hi elm0,
I found the following in the .map file which seems to give the amount of data memory used...
0x000016d0 __Xmc4500_Data_Size = (__Xmc4500_eData - __Xmc4500_sData)
I haven't found the code size yet though.
Best regards
Aaron
I found the following in the .map file which seems to give the amount of data memory used...
0x000016d0 __Xmc4500_Data_Size = (__Xmc4500_eData - __Xmc4500_sData)
I haven't found the code size yet though.
Best regards
Aaron
Jan 14, 2016
04:49 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 14, 2016
04:49 AM
The variables mentioned in the statement you posted are variables of the linker script and thus their meaning is depending on how the linker script is written.
Let me show you an example of one of my projects. I find the following information in my lst-file:
So I have:
.text: 0x450C bytes of code loaded in uncached flash memory (LMA), executed via cache (VMA)
.rodata: 0x701 bytes of read only data in flash (same way of address handling as for .text section)
Stack: The stacksize is 0x1000 bytes and the stack is located at the beginning of the PSRAM
.data: 0xB4 bytes of initialized data located in DSRAM (but loaded in uncached flash to be non volatile)
.bss: 0x34 bytes of uninitialized data located in DSRAM
.no_init: Another 0x14 bytes of uninitialized data located at the end of the DSRAM.
Regards
Elmo
Let me show you an example of one of my projects. I find the following information in my lst-file:
So I have:
.text: 0x450C bytes of code loaded in uncached flash memory (LMA), executed via cache (VMA)
.rodata: 0x701 bytes of read only data in flash (same way of address handling as for .text section)
Stack: The stacksize is 0x1000 bytes and the stack is located at the beginning of the PSRAM
.data: 0xB4 bytes of initialized data located in DSRAM (but loaded in uncached flash to be non volatile)
.bss: 0x34 bytes of uninitialized data located in DSRAM
.no_init: Another 0x14 bytes of uninitialized data located at the end of the DSRAM.
Regards
Elmo
Not applicable
Jan 14, 2016
05:45 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 14, 2016
05:45 AM
Thanks again Elmo, that makes complete sense now.
I have a feature request for Infineon if the feature does not already exist...
Display this information from the DAVE environment with clear descriptions of each parameter and maybe a total for the ram usage.
Best regards
Aaron
I have a feature request for Infineon if the feature does not already exist...
Display this information from the DAVE environment with clear descriptions of each parameter and maybe a total for the ram usage.
Best regards
Aaron
Jan 14, 2016
08:04 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 14, 2016
08:04 AM
Hi Aaron,
I found something like you are asking for in DAVE 4!
In the toolchain, there is a program called "ARM-GCC Print Size" invoked. When I check the "Show Totals" in the toolsettings, I get the highlighted output in the screenshot. I think that is exactly what you're looking for, hopefully the tool is also used in the DAVE 3 toolchain!
Regards
Elmo
I found something like you are asking for in DAVE 4!
In the toolchain, there is a program called "ARM-GCC Print Size" invoked. When I check the "Show Totals" in the toolsettings, I get the highlighted output in the screenshot. I think that is exactly what you're looking for, hopefully the tool is also used in the DAVE 3 toolchain!
Regards
Elmo
Jan 14, 2016
08:16 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 14, 2016
08:16 AM
I crosschecked for my example: In that output, "text" contains the .text (code) and the .rodata sections, "data" conatins simply the .data section and "bss" contains the .bss, the .no_init and the Stack sections.
Not applicable
Jan 14, 2016
08:44 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 14, 2016
08:44 AM
Hi Elmo,
Fantastic, it works in DAVE 3 too. I also found the following explanation for the Eclipse IDE...
http://mcuoneclipse.com/2013/04/14/text-data-and-bss-code-and-data-size-explained/
Thanks again for your help.
Best regards
Aaron
Fantastic, it works in DAVE 3 too. I also found the following explanation for the Eclipse IDE...
http://mcuoneclipse.com/2013/04/14/text-data-and-bss-code-and-data-size-explained/
Thanks again for your help.
Best regards
Aaron
Not applicable
Jan 15, 2016
01:33 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 15, 2016
01:33 AM
HI,
In DAVE 3 and DAVE 4, when you compile your code, in the console window, you can find out the program and variable size.
Here’s an example from the console window:
"C:\DAVEv4\DAVE-4.1.2\eclipse\ARM-GCC-49/bin/arm-none-eabi-size" --format=berkeley "XMC13S2_SECUREBSL_XMC1302-T038x0200_0.elf"
text data bss dec hex filename
9193 132 1116 10441 28c9 XMC13S2_SECUREBSL_XMC1302-T038x0200_0.elf
‘text’ is what ends up in FLASH memory
‘data’ is used for initialized data.
‘bss’ contains all the uninitalized data.
Regards,
Daryl
In DAVE 3 and DAVE 4, when you compile your code, in the console window, you can find out the program and variable size.
Here’s an example from the console window:
"C:\DAVEv4\DAVE-4.1.2\eclipse\ARM-GCC-49/bin/arm-none-eabi-size" --format=berkeley "XMC13S2_SECUREBSL_XMC1302-T038x0200_0.elf"
text data bss dec hex filename
9193 132 1116 10441 28c9 XMC13S2_SECUREBSL_XMC1302-T038x0200_0.elf
‘text’ is what ends up in FLASH memory
‘data’ is used for initialized data.
‘bss’ contains all the uninitalized data.
Regards,
Daryl
Not applicable
Jan 15, 2016
01:45 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 15, 2016
01:45 AM
Thanks Daryl
Jan 15, 2016
01:48 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 15, 2016
01:48 AM
😄 That's true. The output was always there, also without checking the "Show Totals".
Not applicable
Jan 16, 2016
07:18 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 16, 2016
07:18 AM
You're welcome 🙂
Have a good weekend!
Have a good weekend!