If the asm code you're using is the stuff in
MSP-EXP430F5438-CC256x/firmware/hal_compat.c, one question is why
you're using a uint32_t to hold the status register, especially since
you're using 16-bit instructions to read and write it.
Not related to the problem you reported, but it doesn't look right.
If you're using asm code somewhere else, I'd need to see it to debug the issue.
Peter
On Fri, Apr 27, 2012 at 2:50 PM, Matthias Ringwald <matth...@ringwald.ch> wrote:
> Hi
>
> On 27.04.2012, at 21:43, Peter Bigot wrote:
>
>> On Fri, Apr 27, 2012 at 2:19 PM, Matthias Ringwald <matth...@ringwald.ch>
>> wrote:
>>> Hi
>>>
>>> After updating from the 2011 LTS to the new LTS version, my code to place a
>>> 10k array into . fartext section fails.
>>>
>>> The source file looks like this:
>>>
>>> __attribute__((section (".fartext")))
>>> const uint8_t cc256x_init_script[] = { 0x00, ... roughly 10k of data ... };
>>> const uint32_t cc256x_init_script_size = sizeof(cc256x_init_script);
>>>
>>> I get this error:
>>>
>>> msp430-gcc -mmcu=msp430f5438a -g -Os -Wall -I. -I../src -I../firmware
>>> -I../.. -I../../chipset-cc256x -I../../src -I../../include -c -o
>>> ../../chipset-cc256x/bluetooth_init_cc2560A_1.7.o
>>> ../../chipset-cc256x/bluetooth_init_cc2560A_1.7.c
>>>
>>> msp430-gcc ../../chipset-cc256x/bluetooth_init_cc2560A_1.7.o main.o
>>> -mmcu=msp430f5438a -o led_counter.out
>>> ../../chipset-cc256x/bluetooth_init_cc2560A_1.7.o:(.debug_info+0x8e):
>>> relocation truncated to fit: R_MSP430_16_BYTE against symbol
>>> `cc256x_init_script' defined in .fartext section in
>>> ../../chipset-cc256x/bluetooth_init_cc2560A_1.7.o
>>> collect2: ld returned 1 exit status
>>>
>>> Is there something I'm doing wrong, or, is this a regression and I should
>>> file an item in the bug tracker?
>>
>> The only thing "wrong" is that specifying the section is sufficient to
>> correctly place data in far memory, but not to allow you to access
>> that memory. In the updates leading to 20120406, binutils now
>> validates the range for values placed into relocations, and addresses
>> in far memory simply don't fit in a 16-bit relocation, which is what
>> would be used if the array that's in far memory is referenced from any
>> other object file.
>
>> I'm not sure how it could have worked in 20110716; maybe other changes
>> cause a 16-bit relocation to be emitted where you used to use some
>> other mechanism to load the 20-bit address.
>
> The attribute moved it to 0x10000 and I've used inline assembly to read it
> back byte by byte. The code for the Bluetooth stack is about 30 kB, but the
> init script for earlier Bluetooth modules had been 40 kB.
>
> While this isn't a clean & nice solution, at least it worked and there was no
> need for CCS or IAR. Is there a way to just dump data to 0x10000? Could
> binutils be told to relax a bit? :)
>
> Best
> Matthias
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
