Issue Using Large Memory Model with new GCC for MSP430(X) in CCSv6

In your other post you mentioned adding the -mlarge option. Could you try adding this option to both the compiler and linker settings, so the application is also compiled with this option? Under Project Properties, there is a Miscellaneous for both Compiler and Linker options, where you can add this.

Oops.  Thank you for pointing that out...  I added -mlarge and now my errors are:

DownhillSlide.out section `.text' will not fit in region `ROM'
gmake: *** [DownhillSlide.out] Error 1
gmake: Target `all' not remade because of errors.
region `ROM' overflowed by 11348 bytes
section __interrupt_vector_42 loaded at [0000ffd2,0000ffd3] overlaps section .text loaded at [00005c98,00012bbf]

If I turn on size optimization, it compiles, loads and debugs fine.  There are many function definitions in my source files that are not yet used that, as they get brought in, I'm afraid will eventually cause issues.  Plus, for the sake of debugging while in development, I'd prefer to use no optimization.

As a comparison, I removed the -mlarge option from both the compiler and linker and recompiled.  Here is that output:

additional relocation overflows omitted from the output DownhillSlide
DownhillSlide.out section `.text' will not fit in region `ROM'
gmake: *** [DownhillSlide.out] Error 1
gmake: Target `all' not remade because of errors.
region `ROM' overflowed by 1552 bytes
relocation truncated to fit: R_MSP430X_ABS16 against symbol `__mspabi_slli_2' defined in .text section in c:/ti/ccsv6/tools/compiler/i686-pc-mingw32/bin/../lib/gcc/msp430-elf/4.8.0/430x\libgcc.a(slli.o)
relocation truncated to fit: R_MSP430X_ABS16 against symbol `__mspabi_slli_3' defined in .text section in c:/ti/ccsv6/tools/compiler/i686-pc-mingw32/bin/../lib/gcc/msp430-elf/4.8.0/430x\libgcc.a(slli.o)
relocation truncated to fit: R_MSP430X_ABS16 against symbol `__mspabi_slli_9' defined in .text section in c:/ti/ccsv6/tools/compiler/i686-pc-mingw32/bin/../lib/gcc/msp430-elf/4.8.0/430x\libgcc.a(slli.o)
relocation truncated to fit: R_MSP430X_ABS16 against symbol `__mspabi_srli_8' defined in .text section in c:/ti/ccsv6/tools/compiler/i686-pc-mingw32/bin/../lib/gcc/msp430-elf/4.8.0/430x\libgcc.a(srli.o)
relocation truncated to fit: R_MSP430X_ABS16 against symbol `__mspabi_slli_13' defined in .text section in c:/ti/ccsv6/tools/compiler/i686-pc-mingw32/bin/../lib/gcc/msp430-elf/4.8.0/430x\libgcc.a(slli.o)
relocation truncated to fit: R_MSP430X_ABS16 against symbol `__mspabi_slli_12' defined in .text section in c:/ti/ccsv6/tools/compiler/i686-pc-mingw32/bin/../lib/gcc/msp430-elf/4.8.0/430x\libgcc.a(slli.o)
relocation truncated to fit: R_MSP430X_ABS16 against symbol `__mspabi_slli_8' defined in .text section in c:/ti/ccsv6/tools/compiler/i686-pc-mingw32/bin/../lib/gcc/msp430-elf/4.8.0/430x\libgcc.a(slli.o)
section __interrupt_vector_42 loaded at [0000ffd2,0000ffd3] overlaps section .text loaded at [00005c58,00010583]

CLINT STEVENSON1 said:

DownhillSlide.out section `.text' will not fit in region `ROM'
gmake: *** [DownhillSlide.out] Error 1

As the message says, when you don't have optimization turned on, the code size of your program is large enough that it does not fit in the available 'ROM' memory to which it is allocated. You could try placing the .text section to the "far_rom" memory region by modifying the linker script. There might be other ways to split the .text section and/or customize it yourself but I don't have sufficient expertise in the linker and linker script for MSPGCC to tell you exactly how that should be done.

As far as simply changing the allocation of .text from ROM to far_rom I think you should just be able to change it in peripherals.ld file in your project.

You may also be able to get additional ideas and help from the MSPGCC users mailing list. The archives of this list are here.

Thanks AartiG.  I wish I knew more about the inner workings of the build "magic" and how to tweak the compiler and linker settings.  It is puzzling to me why the ROM overflow is a greater number when I add the -mlarge option.  I'm suspecting it is because it forces all the object pointers to 32-bit instead of 16-bit?  Can you confirm?  

I modified the peripheral.ld file in the respective device include folder inside the "include_gcc" folder, reallocating the ".text" sections to "far_rom" instead of "ROM" as you suggested, but it didn't make a difference.  I get the same errors and same ROM overflow.

I'm assuming there should be some trigger in the compile & link process to use alternate ld files when the -mlarge option is selected, but which ones and why it's not using those, I don't know.

I may be on the right track...  I finally figured out the syntax for the section attribute and started adding this to all of my application layer function definitions:

__attribute__ ((section(".far_rom")))

What was a ROM overflow of over 11k bytes is down to just over 7k bytes.  

Why doesn't the linker automatically fill the near ROM first and then begin filling the far ROM?

CLINT STEVENSON1 said:

Why doesn't the linker automatically fill the near ROM first and then begin filling the far ROM?

I don't believe the GCC linker does an automatic splitting of sections into multiple memory regions ( at least I haven't been able to find information that it is capable of doing so).

As an update, I added the code placement macros throughout a particular file as mentioned in my previous post and that fixed the problem, or so I thought....  Then I started adding the same macros throughout another file, but when I compiled now it is saying RAM overflowed by xyz bytes...?  

So I went back to mspgcc-20120406-p20120911 and added the same code placement macros, and everything seems to be compiling, linking, loading and debugging fine.  I think I will continue down this path until the new RedHat MSPGCC matures and better (any) documentation is released.

So now I'm seeing the same overflow error using mspgcc-20120406-p20120911, but caused when I added the code placement macro to the FatFs ff.c source file.  The error is saying the *.elf section '.far_rom' will not fit in region 'ram'.  

As a side note, I have tried various ways to get a map file with no luck.  I would think I could just add the option -Map "listing.map" to the linker miscellaneous flags, but I get nothing out even after manually refreshing the workspace.

When I was working through this exercise in the RedHat MSPGCC, it was successfully creating a map file.  I noticed however, even though I instructed the linker to put certain functions in '.far_rom', the map file still showed those functions at addresses < 0x10000.  Shouldn't anything in '.far_rom' be located beyond 0x10000?

Minor update regarding map file generation.  Here is what it took to get the map file from MSPGCC for others who may be having issues with this.  After examining the map file, my suspicions were confirmed that the linker is *not* placing the functions tagged with:

__attribute__ ((section(".far_rom")))

into the "far memory", or flash address greater than 0x0001 0000.  

Sorry for the burst of posts, but also of possible interest to readers of this thread my post about this issue in the MSP430 GCC Users Forum here:

http://msp430-gcc-users.1086195.n5.nabble.com/Issue-Using-Large-Memory-Model-MSP430X-td7012.html

And I also saw this here:

http://msp430-gcc-users.1086195.n5.nabble.com/Miscompiled-crtbegin-in-large-model-td6991.html

So, I guess I'm just not being patient enough on the 430X architecture support...

CLINT STEVENSON1 said:

I modified the peripheral.ld file in the respective device include folder inside the "include_gcc" folder, reallocating the ".text" sections to "far_rom" instead of "ROM" as you suggested, but it didn't make a difference.  I get the same errors and same ROM overflow.

I just noticed this comment from one of your earlier posts, and I wanted to add some comments on this.

If you are using CCSv6 beta and started off by creating a new CCS project, and selecting GNU compiler 4.8.0 in the Advanced Settings, then based on the device selected the appropriate linker scripts should be automatically added to your project. In the Project Explorer view in CCS, you should see a folder with the device name, within which will be the memory.ld and peripherals.ld linker scripts. If you wish to alter any of the section allocations, you can modify the files here as these are the files used for the link.

Sorry to make you back track on what you have done since this post, but maybe could you try modifying the peripherals.ld file within your project to allocate .text to far_rom? You may also need to remove the code additions you had made earlier (__attribute__ ((section(".far_rom"))) , but I'm not certain about this.

I tried a simple hello world example project and was able to modify the peripheral.ld script to allocate .text in far_rom (0x10000) instead of ROM(0x5C00) on a MSP430F5438A device. I can't guarantee that this will solve all your issues as you also mentioned some overflow errors but I just wanted to point out that maybe the reason you did not see the linker map file reflect the correct memory allocation was because you adjusted the linker script in the wrong location.

Yes, I was using CCSv6 beta and did exactly what you described above regarding GNU compiler 4.8.0 in 'Advanced Settings'.  As I recall, I had expected to find the linker scripts in a folder named after the device (msp430f5438 in my case) within the following path and it's not there:

C:\ti\ccsv6\tools\compiler\i686-pc-mingw32\msp430-elf\lib\ldscripts

As you mentioned though this folder and linker files are in the Project Explorer.  Removing the (__attribute__((section(".far_rom"))) code was as easy as removing __LARGE_DATA_MODEL__ from the 'Symbols' in the project properties compiler setup.

#if defined (__LARGE_DATA_MODEL__)
__attribute__ ((section(".far_rom")))
#endif

So here is the result:

1. With __LARGE_DATA_MODEL__ set as a defined symbol (i,e. all (__attribute__((section(".far_rom"))) tags in place) and peripheral.ld unmodified to locate .text to near rom first, I get linker errors saying it overflows section RAM by 5940 bytes.
2. With __LARGE_DATA_MODEL__ removed (i,e. all (__attribute__((section(".far_rom"))) tags removed) and peripheral.ld modified to locate .text only to far rom it compiles.

From reading one of the hyperlinks to the MSP430 GCC Users Forum I included in my previous post, I concluded that support for MSP430X devices is at best premature - at least in terms of utilizing the 20-bit wide address space.