For each device, the linker has a command script that contains informations
about where there is RAM or Flash.
Then there are a number of default 'segments' defined, which locations where to
place objects.
The usual setup is that those sections that are defined for placing code are
mapped to a flash area, while
sections for variables are mapped to ram area, and for sections for initialized
variables, there is a mixture of both.
When teh compiler generates an object (glbal variable, function etc.) it
automatically picks one of these
predefined sections. You can override this (invisible) default by manually
defining a section attribute for this
object.
E.g. when you place a funciton manually in teh section for initialized
variables, the linker will put the generated
code into flash, form where it will be copied to ram on startup. All references
to this function will point to
its final ram destination.
However, whether you put a funciton in ram or flash makes no difference, as the
MSP uses von Neumann
architecture, which does not separate data addressing from code addressing. All
happens in the same address
space. The only difference is that if you place a function into ram, it will
definitely end up in lower 64k and
have a 16 bit address, while a function in flash may beput into >64k flash and
get a 20 bit address.
Anyway, as Peters 'wild guess' (hey, that's my TM! :) ) already suggested, your
problem with these errors
may be related to 20 bit addressing mode, even if you do not explicitely enable
it.
Is your code (inlcudign initialized data and constands) larger than the flash
size below 64k?.
On normal (16 bit) MSP code, function pointers are 16 bit.
The generated code leaves space for putting a 16 bit address into it when
resolving all relations during
link stage.
If, however, a reference is marked as 20 bit value while the code has only a 16
bit instruction to put the
address in, the linker (especially if not supporting 20 bit relocations) is
hosed.
Normally, the compiler shouldn't compile what the linker cannot link.
However, it may happen that precompiled libraries use 20 bit model and your
code uses 16 bit only.
Also, you link code parts that have been compiled with 20 bit support and then
link it together with code
parts that have been newly compiled with only 16 bit support.
In case of funciton pointers (which are variables), it even might mix up.
Function pointers to dunciton above
64k require 20 bit (or rather 32 bit) support for data handling (20 bit
registers, 20 bit push/pop etc.),
while normal 20 bit code support only handles 20 bit support for normal code
flow (CALLA/RETA).
So it might be that the function pointer variable is 16 bit only while the
address is 20 bit and requires
a 32 bit pointer.
Then the linker cannot relocate it (set the init value of the funciton pointer
to the function location).
And maybe the linker does not support this kind of relocation at all, not
knowing what to do then.
(not even knowing an error that fits better)
Maybe you can resolve the problem by forcing all function in question to reside
in lower 64k flash
segment, so the linker won't put it into the flash above 64k and therefore does
not assign it a 20 bit address.
JMGross.
----- Ursprüngliche Nachricht -----
Von: Sergio Campamá
An: Oleg Verych
Gesendet am: 30 Jun 2011 14:35:34
Betreff: Re: [Mspgcc-users] Internal Error: Unsupported relocation error
In that case, how can I specify that I want the function pointer to be in RAM
and not in the flash?
Thanks,
---------------------------------------
Sergio Campamá
sergiocamp...@gmail.com
On Jun 30, 2011, at 1:30 PM, Oleg Verych wrote:
> 2011/6/30 Sergio Campamá <sergiocamp...@gmail.com>:
>> Hello,
>
> Hi,
>
>> As an example, this code
>>
>> void (*button_callback_1)() = NULL; //button callback is 0 by default
>>
>> void button_process_interrupt(uint8_t button)
>> {
>> switch(button)
>> {
>> case BUTTON_1:
>> if (button_callback_1 != NULL) button_callback_1();
>> break;
>> }
>> }
>>
>> void button_interrupt(uint8_t button)
>> {
>> task_add(&button_process_interrupt, TASK_PRIORITY_LOW, button);
>> }
>>
>> void button_register_callback_1(void (*callback)())
>> {
>> button_callback_1 = callback;
>> }
>>
>> generates the following errors:
>>
>> obj_z1/button.obj: In function `button_process_interrupt':
>> button.c:(.text+0x8): warning: internal error: unsupported relocation error
>> obj_z1/button.obj: In function `button_register_callback_1':
>> button.c:(.text+0x48): warning: internal error: unsupported relocation error
>>
>> What could be happening? I didn't want to file a bug report until being sure
>> this is a bug.
>
> isn't that logic error in C code?
>
> The CPU has FLASH running a program code, also it may run a code from
> the RAM. The FLASH is readonly, RAM is not. Where C program and linker
> know that specific of the platform?
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
