Thanks JMGross for that information, it was very useful!
But my code does not even reach the 10k limit. It is around 4k, so there
shouldn't be any problems with that. Whatever it was, it was gone after I
called static on the global variables...
On Fri, Jul 1, 2011 at 11:23 AM, JMGross <msp...@grossibaer.de> wrote:
>
> 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
>
--
--------------------------------------
Sergio Campamá
sergiocamp...@gmail.com
------------------------------------------------------------------------------
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
