I'm writing code for the 2560, lots of code, and have run into the usual error from the linker about an internal overflow error.
Archive searches give mostly Stu-san's post about fixing the FreeRTOS, which I don't use. However, I do have the same kind of issues.
Given that I have a different structure for a called function, I've changed the definition of the called function to be:
#define FUNCTION_HANDLER __attribute__ ((section (".fptr_target"))) typedef int (function) (void*, int ival, int jval, void*); // define *FUNCTION as pointer to int function(hardware block*, int task#, int argument, *more parameters)
Which is an attempt to maintain the same calling routine structure for a MEGA as an XMEGA. Code somewhat abstracted from the Atmel notes.
I have a function called as:
int FUNCTION_HANDLER twi_reply_smart_data (struct TWI_Master_type* twi, int count, int block_count, void* data)
Note that all called functions (used in a table, etc of pointers to a function follow this mode. Declaring the function prototype to be of type FUNCTION_HANDLER does not work. No big deal there.
Where I had a problem was in looking for the means to define the start of the lower block of function pointers (which must reside in the lower 64K of memory). The linker additions as addressed from the configuration settings make the data exist at an address, but that address must be a particular memory address, numeric only, please. Obviously, I want it roughly before the main program code, and after the .init 9 section. I can't use any of the .init sections because they are executed code. This remains statically allocated data.
For a long time, I looked for the location of linker_script.x, with no luck. Apparently, it's a created file.
I did find the location of the linker scripts for a particular processor. Looks like looks like av6.x is the one for the MEGA 256x series. Making a modification to it, the way that Stu-san did, I added a section to the linker script for this processor model (and I could do so for the other models eventually, but I only use a few processor types, MEGA 16, 32, XX4, and XX8, plus xmega, where I won't need them. Or, I'll change the function definitions with a #ifdef statement and drop out the section relocation.) Hopefully, the xmega doesn't have the problem (although it might).
That modification is of the form
*(.init9) /* Call main(). */ KEEP (*(.init9)) /* Any code that is the target of a function pointer must also reside in lower memory */ *(.fptr_target) KEEP(*(.fptr_target)) *(.text) . = ALIGN(2);
Where the section added starts with the comment, and ends with the KEEP instruction.
This produces the following map file (I've tried it on only one routine to see if it relocates, it wasn't one of the "problem" routines so the errors persist)
*(.init8) *(.init9) .init9 0x00002816 0x8 c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avr6/crtm2560.o *(.init9) *(.fptr_target) .fptr_target 0x0000281e 0x6a TWI_X_driver.o 0x0000281e twi_reply_smart_data *(.fptr_target) *(.text) .text 0x00002888 0x4 c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avr6/crtm2560.o 0x00002888 __vector_38 0x00002888 __vector_22 0x00002888 __vector_28
Which, if I read this properly, should solve the problem.
Main difficulty I have is that this is a workaround, I'd like to see something of this type of problem addressed a bit more gracefully. Any chance of that?
Did I manage to do this right? I will know in advance which functions are called by the task scheduler, the GUI_icon driver, and the TWI_slave execute routine, all of which are the routines potentially giving me the problem. I have yet to see if the code works, but so far, it at least looks as if it should.