Closed armandas closed 8 months ago
Did also run into this problem. The -B flag does not work for me. What flags exactly you use?
Furthermore the SysProgs compiler (only for Windows) works out of the box with correct region size. So somehow it must be possible to get the correct behavior also on Linux.
@mobacon Did you pass the right argument to -B
? I point it to the extracted DFP like this:
-B _deps/atmegadfp/gcc/dev/atmega640
Reason is that Binutils works on emulation level, i.e. is knows -mavrxmega2
or -mavr51
, and the layout of MEMORY regions comes from the emulation default. For example, the top of the default linker scripts read something like (here from avr51.x
):
__TEXT_REGION_ORIGIN__ = DEFINED(__TEXT_REGION_ORIGIN__) ? __TEXT_REGION_ORIGIN__ : 0;
__TEXT_REGION_LENGTH__ = DEFINED(__TEXT_REGION_LENGTH__) ? __TEXT_REGION_LENGTH__ : 128K;
__DATA_REGION_ORIGIN__ = DEFINED(__DATA_REGION_ORIGIN__) ? __DATA_REGION_ORIGIN__ : 0x800100;
__DATA_REGION_LENGTH__ = DEFINED(__DATA_REGION_LENGTH__) ? __DATA_REGION_LENGTH__ : 0xff00;
...
MEMORY
{
text (rx) : ORIGIN = __TEXT_REGION_ORIGIN__, LENGTH = __TEXT_REGION_LENGTH__
data (rw!x) : ORIGIN = __DATA_REGION_ORIGIN__, LENGTH = __DATA_REGION_LENGTH__
...
}
Hence, when symbols like __TEXT_REGION_LENGTH__
are not defined, the core specific defaults are used which are large enough so that all MCUs in that core family will fit.
A canonical place to define these symbols is in the startup code. Stock AVR-LibC currently does not define respective symbols, but there is https://github.com/avrdudes/avr-libc/issues/936 to (weakly) define respective symbols.
crt*.o
from atpacks has these symbols defined, so it makes a difference which crt you are using. See avr-nm crt*.o | grep REGION
.
For the time being, you can define the symbols on the command line, e.g. -Wl,--defsym,__TEXT_REGION_LENGTH=64k
or in the device-specs file, for example:
*link_text_start:
--defsym __TEXT_REGION_LENGTH=64k
I am building a project for ATmega640 using GCC 12.1. I'm passing a
-Wl,--print-memory-usage
flag to the linker to get the memory usage, but GCC thinks that the device has 128KB of flash, instead of 64KB. The RAM and EEPROM sizes are also wrong.Linker flags:
-mmcu=atmega640 -fno-exceptions -fno-rtti -Wl,--gc-sections -Wl,--print-memory-usage
Output:
When the command from #3, the correct percentage is displayed:
Unfortunately, this issue means that compiler does not detect when the code exceeds the available memory.
The issue is not present on GCC 5.4, that is bundled with the Microchip Studio.