TLDR: If you want to issue -Wl,--print-memory-usage the content of .data (or another block) in several sections, such as FLASH And RAMYou have to use the pattern .data : { ... } > RAM AT > FLASH For precise reporting. The pattern of .data: AT(some_location) { ... } > RAM creates false results. Many thanks to Scott Shawcroft (Tannewt) for that!
In the original version of Three GCC flags for analyzing memory consumptionI described an inaccuracy that was observed in the edition of -Wl,--print-memory-usage. Special, .data Content was not properly taken into account FLASH. Here is what the article said:
One disadvantage of this flag is that the reported data can be misleading if a section is placed in several storage regions. For example the .data The section is actually saved in FLASHand charged in RAM During the program start.
In the following example edition the reported size for FLASH is actually wrong because it is only the inclusion of the .text Segment. You can see from the sizeEdition that we have 392 bytes in the .data Segment. Our actual binary size in the flash will be 13512 + 392 bytes.
(3/3) Linking target src/applications/blinky/blinky_dongle
Memory region Used Size Region Size %age Used
FLASH: 13512 B 1020 KB 1.29%
RAM: 892 B 262136 B 0.34%
$ arm-none-eabi-size src/applications/blinky/blinky_dongle
text data bss dec hex filename
13512 392 500 14404 3844 src/applications/blinky/blinky_dongle
I am currently not a way to deal with this restriction with the flag. Unfortunately, this discrepancy remains, even if we correctly specified both last memory addresses and virtual memory addresses in our left file.
Even with this restriction, the flag still offers me an advantage: I can monitor the use of non-nonFLASH Sections and an early warning received if I go shortly before the memory.
Note: If you have some Left -script Magic that will get that
.dataSection calculated compared to bothFLASHAnd data, let us know!
This stood for two years and I could never find a suitable solution to get it .data Content in both FLASH And RAM Sizes. After all, Scott Shawcroft (whom you might also know as a firewat) solved the riddle and found a solution.
In my left scripts I tend to use the following pattern: Set the .data Section AT (__end_of_text_section_in_flash)And indicate that it should be laid in RAM.
.data : AT (__data_start_in_flash)
{
. = ALIGN(4);
__data_start__ = .;
*(vtable)
*(.data)
*(.data*)
. = ALIGN(4);
/* All data end */
__data_end__ = .;
} > RAM
From the perspective of the generated application, this is a completely suitable pattern. However, you do not receive the correct output with -Wl,--print-memory-usageas described above. I will update the sizes with the current compiler version that I have installed (ARM GCC 10.3.1), since the output of the original has changed slightly.
make
(...)
(3/3) Linking target src/blinky_dongle
Memory region Used Size Region Size %age Used
FLASH: 14748 B 1020 KB 1.41%
RAM: 800 B 262136 B 0.31%
arm-none-eabi-size buildresults/src/blinky_dongle
text data bss dec hex filename
14748 48 752 15548 3cbc buildresults/src/blinky_dongleAs you can see, FLASH Size only takes into account .textAnd not that .data Contents that are also saved in FLASH (and moved later to RAM).
Instead, you can use a different pattern in which you specify the content of the .data Section and then use > RAM AT > FLASH At the end.
.data :
{
. = ALIGN(4);
__data_start__ = .;
*(vtable)
*(.data)
*(.data*)
. = ALIGN(4);
/* All data end */
__data_end__ = .;
} > RAM AT > FLASH
In this format we get the same edition from the perspective of the binary, but now the FLASH The region is calculated properly. We can check this by seeing this FLASH Is now the sum of .text And .data.
make
(...)
(1/1) Linking target src/blinky_dongle
Memory region Used Size Region Size %age Used
FLASH: 14796 B 1020 KB 1.42%
RAM: 800 B 262136 B 0.31%
arm-none-eabi-size buildresults/src/blinky_dongle
text data bss dec hex filename
14748 48 752 15548 3cbc buildresults/src/blinky_dongle