• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 78 subscribers
  • Views 4808 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

GCC 4.9.1 using __attribute__ (section(""))

Dr. C. L. Fullmer
Intellectual 435 points
Other Parts Discussed in Thread: MSP430FR5969

(Sorry if this is not the correct forum .. but there is no specific GCC forum as yet)

Trying to use the GCC __attribute__ (section(("label")));  but it gives me errors... (in CCSv6)

error: no memory region specified for loadable section `APP_DATA_TSTAMP'

Any ideas here? Did I miss a compile switch or such?

I seem to have followed the documentation properly, and a few examples I've seen agree..

------------------------

GCC documentation

section ("section-name")
Normally, the compiler places the code it generates in the text section. Sometimes,
however, you need additional sections, or you need certain particular
functions to appear in special sections. The section attribute specifies that a
function lives in a particular section. For example, the declaration:
       extern void foobar (void) __attribute__ ((section ("bar")));
puts the function foobar in the bar section.
Some file formats do not support arbitrary sections so the section attribute
is not available on all platforms. If you need to map the entire contents of a
module to a particular section, consider using the facilities of the linker instead.

..... example code ...

// FRAM Array reserved to store FRAM Log Mode starting Time Stamp
#if defined(__IAR_SYSTEMS_ICC__)
#pragma location = 0xF002
__no_init uint8_t timeStamp[6];
#elif defined(__TI_COMPILER_VERSION__)
#pragma location = 0xF002
#pragma NOINIT(timeStamp)
uint8_t timeStamp[6];
#elif defined(__GNUC__)
uint8_t timeStamp[6] __attribute__ ((section("APP_DATA_TSTAMP")));
#endif

..... linker output..

'Building target: OutOfBox_FR5969.out'

'Invoking: GNU Linker'
"C:/TexasInstruments/ccsv6/tools/compiler/gcc_msp430_4.9.14r1_10/bin/msp430-elf-gcc.exe" -mmcu=msp430fr5969 -Os -g -gstrict-dwarf -Wall -Wl,-Map,"OutOfBox_FR5969.map" -o"OutOfBox_FR5969.out" "./FRAMLogMode.o" "./LiveTempMode.o" "./main.o" "./driverlib/MSP430FR5xx_6xx/adc12_b.o" "./driverlib/MSP430FR5xx_6xx/aes256.o" "./driverlib/MSP430FR5xx_6xx/comp_e.o" "./driverlib/MSP430FR5xx_6xx/crc.o" "./driverlib/MSP430FR5xx_6xx/cs.o" "./driverlib/MSP430FR5xx_6xx/dma.o" "./driverlib/MSP430FR5xx_6xx/eusci_a_spi.o" "./driverlib/MSP430FR5xx_6xx/eusci_a_uart.o" "./driverlib/MSP430FR5xx_6xx/eusci_b_i2c.o" "./driverlib/MSP430FR5xx_6xx/eusci_b_spi.o" "./driverlib/MSP430FR5xx_6xx/fram.o" "./driverlib/MSP430FR5xx_6xx/gpio.o" "./driverlib/MSP430FR5xx_6xx/mpu.o" "./driverlib/MSP430FR5xx_6xx/mpy32.o" "./driverlib/MSP430FR5xx_6xx/pmm.o" "./driverlib/MSP430FR5xx_6xx/ref_a.o" "./driverlib/MSP430FR5xx_6xx/rtc_b.o" "./driverlib/MSP430FR5xx_6xx/sfr.o" "./driverlib/MSP430FR5xx_6xx/sys.o" "./driverlib/MSP430FR5xx_6xx/timer_a.o" "./driverlib/MSP430FR5xx_6xx/timer_b.o" "./driverlib/MSP430FR5xx_6xx/tlv.o" "./driverlib/MSP430FR5xx_6xx/wdt_a.o" "./driverlib/MSP430FR5xx_6xx/deprecated/cs.o" "./driverlib/MSP430FR5xx_6xx/deprecated/dma.o" "./driverlib/MSP430FR5xx_6xx/deprecated/fram.o" "./driverlib/MSP430FR5xx_6xx/deprecated/mpy32.o" "./driverlib/MSP430FR5xx_6xx/deprecated/pmm.o" "./driverlib/MSP430FR5xx_6xx/deprecated/sfr.o" "./driverlib/MSP430FR5xx_6xx/deprecated/sys.o" -T"../msp430fr5969.ld"  -Wl,--start-group -l"c" -l"gcc" -Wl,--end-group
c:/texasinstruments/ccsv6/tools/compiler/gcc_msp430_4.9.14r1_10/bin/../lib/gcc/msp430-elf/4.9.1/../../../../msp430-elf/bin/ld.exe: error: no memory region specified for loadable section `APP_DATA_TSTAMP'
collect2.exe: error: ld returned 1 exit status
gmake: *** [OutOfBox_FR5969.out] Error 1
gmake: Target `all' not remade because of errors.

**** Build Finished ****

  • 0
    Guru 227245 points

    The attribute tells the compiler to tell the linker to place this element in a specific section. Which is properly done.

    However, the linker is telling you that it has never heard of such a section, because a section of this name is not defined in its linker script.

  • 0 in reply to Jens-Michael Gross
    Intellectual 435 points

    Yes.. it would appear so.. I've spent a couple days going over the gnu docs on ld and gas..

    However, that said, it is still not clear to me how to make a section of FRAM available for loading a data variable into, as in the examples (ie, OutOfBox_FR5969) ..  the 'tips and tricks' FRAM doc has examples for the other compilers, but not for GCC as yet..  perhaps there is another more current document I've not come across so far..

    I've got the example link script (msp430fr5969.ld), but it does not appear to address access to FRAM, putting it all into a section called ROM..

    An example script or a code snippet or three would be greatly appreciated :)

  • 0 in reply to Dr. C. L. Fullmer
    Guru 227245 points

    It’s indeed difficult for a linker to handle non-volatile random access memory. Either it is RAM (and needs to be initialized at startup) or it is ROM and can hold persistent read-only data.

    But if you only want to place your (non-persistent) variables in a certain FRAM area…

    Well, in the linker script you’ll find the definitions for the predefined segments.
    You need to clip the definition for the main code segment (shrinking its size and its start or end address)
    Then create an additional segment definition that spans the now free area of FRAM, but contains the same flags as the data segments.
    Finally, add a move instruction to the script, that tells to copy elements of your section into this newly created memory segment.
    Then you can move variables into it, using the section attribute.

  • 0 in reply to Jens-Michael Gross
    Intellectual 435 points

    Thanks for your suggestion Jens-Michael...

    However, I took a slightly different approach with some success..

    I modified the link script by adding this to it:

    .appData : {
          . = ALIGN(2);
          PROVIDE (__appdata_start = .);
          *(.appData)
          . = ALIGN(2);
          PROVIDE (__appdata_end = .);
          end = . ;
          } > ROM

    I then declared it as this:

    #elif defined(__GNUC__)
     __attribute__ ((section(".appData"))) uint16_t dataArray[12289];
    #endif

    Which leaves me 24578 byte hole in the memory map to diddle data into and out of.. similar to the original example .. 

  • 0 in reply to Dr. C. L. Fullmer
    Guru 227245 points

    Well, this will work, assuming all ‘ROM’ is R/W. However, you’ll maybe run into trouble when using the memory protection mechanisms, as you’ll end up with code and data mixed in rather random order.

**Attention** This is a public forum