Bill Westfield suggested elsewhere that this problem might be circumvented by changing the link script. the linker is called ld. In trying to begin to understand that I was reading some things last night and found a related, but slightly different issue. I looked at http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1265576847
as an example of what the makefilelooks like. Here are a couple of excerpts:
LDFLAGS = -O$(OPT) -lm -Wl,--gc-sections
I don't understand --gc-sections. Presumably it is the important line since sections is the code that adds offsets to the address being used by the linker.
But this, while not actualy telling the linker what to do, as far as I can tell, is the related problem:
# Convert ELF to COFF for use in debugging / simulating in AVR Studio or VMLAB.
COFFCONVERT=$(OBJCOPY) --debugging \
--change-section-address .data-0x800000 \
--change-section-address .bss-0x800000 \
--change-section-address .noinit-0x800000 \
The avr Harvard architecture is handled by the linker by putting 800000 as an offset for all of flash memory. But notice that the offset used here, just in a simulator, I think, for eeprom is 810000. Translating to decimal that is 65636 above where the flash memory starts. Thus the debugger/simulator separately assumes flash can't be larger than 65K.
It seems like the Atmel folks, would have a big stake in getting this resolved. How can they hope to sell 2560 chips unless it is???