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_msp430_4.9.14r1_364: linker error region `ROM' overflowed by 544 bytes



Hi,

I thought I kinda sorted this issue out with my last project by setting my linker options to

-mlarge
-mcode-region=either
-mdata-region=either
-mhwmult=f5series

I started using the vsnprintf function yesterday to send output to my UART. Since then the whole project doesn't built anymore, claiming

c:/ti/ccsv6/tools/compiler/gcc_msp430_4.9.14r1_364/bin/../lib/gcc/msp430-elf/4.9.1/../../../../msp430-elf/bin/ld.exe: VKS_MS_NG_45_VideoProcessorFW.out section `.text' will not fit in region `ROM'
c:/ti/ccsv6/tools/compiler/gcc_msp430_4.9.14r1_364/bin/../lib/gcc/msp430-elf/4.9.1/../../../../msp430-elf/bin/ld.exe: section __interrupt_vector_42 loaded at [0000ffd2,0000ffd3] overlaps section .text loaded at [00006484,0001019f]
c:/ti/ccsv6/tools/compiler/gcc_msp430_4.9.14r1_364/bin/../lib/gcc/msp430-elf/4.9.1/../../../../msp430-elf/bin/ld.exe: region `ROM' overflowed by 544 bytes
collect2.exe: error: ld returned 1 exit status
gmake: *** [VKS_MS_NG_45_VideoProcessorFW.out] Error 1
gmake: Target `all' not remade because of errors.

I tried all possible combinations of -mcode-region and -mdata-region to no avail. Another project using the same settings, same CPU as stated above which uses really large constant arrays builds just fine.

Obviously the GCC linker is still too stupid to make use of my 128kb flash properly.


I thought MSP-GCC is actively maintained by TI employees. Is this the way of forcing people to buy the commercial Ti compiler for a ridiculous amount of money and very annoying licensing scheme?

I read a lot of posts of people having the same issues, so for me it looks like a fundamental flaw. I was hoping TI performs better compared to Atmel with their stupid 64KB limit because of their 16bit pointers.

But TI has 20 bit pointers in the large memory model and I still have to worry about my code size. From a first look I am far from using much more than half of the available flash.

Is there anything I can do to make this link without loosing functionality (I know I could write my own printf)? Any updated linkerscripts? Any beta version GCC with improved behaviour?


P.S. Maybe you should make a seperate Forum under "Development Tools" for the GCC Compiler. I only see the Ti Compiler there.

Markus

  • Follow-Up: I saw there is a newer GCC Version gcc_msp430_4.9.14r1_467. I updated it and tried to built my project with it.
    It does not show up in the compiler list, there is just one entry in the list "GNU v4.9.1 (RedHat).

    If I manually select the compiler with the "Select new compiler from file-system" and point it to
    C:\ti\ccsv6\tools\compiler\gcc_msp430_4.9.14r1_467
    CCS doesn't complain (like if I try to select the "bin" subdirectories in the same dialogue), but when I build again its still using the old 364 release, not the 467. What am I doing wrong there?
  • I updated to CCS V6.1.2 with gcc_msp430_4.9.14r1_467, which introduced other issues with a different project, which I could fix, no improvements with the ROM overflow here, actually the code greq a bit with the new gcc_msp430_4.9.14r1_467

    c:/ti/ccsv6/tools/compiler/gcc_msp430_4.9.14r1_467/bin/../lib/gcc/msp430-elf/4.9.1/../../../../msp430-elf/bin/ld.exe: VKS_MS_NG_45_VideoProcessorFW.out section `.text' will not fit in region `ROM'
    c:/ti/ccsv6/tools/compiler/gcc_msp430_4.9.14r1_467/bin/../lib/gcc/msp430-elf/4.9.1/../../../../msp430-elf/bin/ld.exe: section __interrupt_vector_42 loaded at [0000ffd2,0000ffd3] overlaps section .text loaded at [000064cc,000101e3]
    c:/ti/ccsv6/tools/compiler/gcc_msp430_4.9.14r1_467/bin/../lib/gcc/msp430-elf/4.9.1/../../../../msp430-elf/bin/ld.exe: region `ROM' overflowed by 612 bytes
    collect2.exe: error: ld returned 1 exit status
    gmake: *** [VKS_MS_NG_45_VideoProcessorFW.out] Error 1
    gmake: Target `all' not remade because of errors.
    

    I'm desperate a bit.

    Markus

  • Hi Markus,
    I did the same thing.
    I've tried a number things to no avail.

    ti/ccsv6/tools/compiler/gcc_msp430_4.9.14r1_364/bin/../lib/gcc/msp430-elf/4.9.1/../../../../msp430-elf/bin/ld: region `ROM' overflowed by 12932 bytes

    Mike
  • Markus Rudolf said:
    c:/ti/ccsv6/tools/compiler/gcc_msp430_4.9.14r1_364/bin/../lib/gcc/msp430-elf/4.9.1/../../../../msp430-elf/bin/ld.exe: VKS_MS_NG_45_VideoProcessorFW.out section `.text' will not fit in region `ROM'

    Markus,

    The message is indicating that the .text section is too large to fit into ROM. If you are using the default linker script that CCS adds to MSP-GCC projects, then you will notice that the interrupt vectors are also allocated to ROM. So if you're .text section is larger than what can fit into the remaining ROM, then the above message is generated. And *printf functions do contribute to quite a bit of code size increase.

    A couple of things to try:
    - Allocate the .text section to HIROM (upper flash memory) region. Please check the linker script for your specific device to veriify the name of the upper Flash memory region.
    - Depending on your device/linker script, there might already be a section allocation for .upper.text to go into HIROM. You could place some parts of your code into .upper.text section so it automatically gets allocated to HIROM.

  • AartiG said:

    Markus,

    The message is indicating that the .text section is too large to fit into ROM. If you are using the default linker script that CCS adds to MSP-GCC projects, then you will notice that the interrupt vectors are also allocated to ROM.

    Sure they have to be in the ROM section, by the nature of the CPU (they are at fixed addresses).

    AartiG said:
    So if you're .text section is larger than what can fit into the remaining ROM, then the above message is generated. And *printf functions do contribute to quite a bit of code size increase.


    Yes, but why do I have to worry about this? Why is the linker script or the linker itself not able to see that there is plenty of space left above the vectors and it just maps the excess functions there?

    That's something the tool should do for me. There is plenty of announcements in the GCC change-logs that it will support the different memory regions handling better, but I'm still supposed to do it manually?


    How the TI compiler dealing with such situations? I'm pretty sure there no one has to worry in which section which function should go. Correct me if I'm wrong there.

    Markus

    Markus

  • Markus Rudolf said:
    How the TI compiler dealing with such situations? I'm pretty sure there no one has to worry in which section which function should go. Correct me if I'm wrong there.

    The user of the TI linker does need to specify which memories each section may go in.  This is the job of the linker command file.  However, for MSP, CCS provides a default set of linker command files tailored to the hardware which work pretty well aside from exceptional programs.  I don't know how GCC manages the memories.

  • Markus Rudolf said:
    Yes, but why do I have to worry about this? Why is the linker script or the linker itself not able to see that there is plenty of space left above the vectors and it just maps the excess functions there?

    As pointed out by Archaeologist, the linker script (or linker command file in the case of TI tools) "defines" the range of the memory regions and which memories each section maps to. For MSP devices, CCS includes a default set of TI linker command files and GCC linker scripts which work well in most cases. But there may always be corner cases where user modification of the linker script and/or code may be necessary to get things going (as in this case where code size increases to a point where the default linker script allocation does not work).

    One feature that the TI linker supports, that comes in handy in such situations, is automatic splitting of a section across multiple memory regions. So if the section is larger than what the first memory region can hold, then it will automatically split it and allocate the rest to the second memory region. However, I don't believe the GCC linker supports this feature, so some level of user intervention is required for certain use-cases.

    If you still have questions about the default GCC linker scripts provided by CCS, I would suggest starting a new post in the MSP forums, They should be able to contact and work with the MSP team that provides those files.