• Join
  • Sign In with my.TI Login
Texas Instruments
  • Products
  • Applications
  • Tools & Software
  • Support & Community
  • Sample & Buy
  • About TI
Sample & Purchase Cart Sample & Purchase Cart
  • Search
  • Advanced
TI E2E™ Community
  • Support Forums
  • Blogs
  • Groups
  • Videos
  • 简体中文
  • More ...
TI Home » TI E2E Community » Support Forums » Microcontrollers » MSP430™ Microcontrollers » MSP430 Ultra-Low Power 16-bit Microcontroller Forum » MSP430F5438A Linker file (can not fit code into memory)
Share
MSP430™ Microcontrollers
  • Forum
  • Announcements
  • E2E Wiki
Options
  • Subscribe via RSS
MSP430 Resources
  • MSP430 Product Folder
  • MSP-EXP430G2 - MSP430 LaunchPad Value Line Development kit
  • MSP430 Getting Started Guide
  • MSP430 Microcontroller Projects
  • More Resources >
  • MSP430F5438A Linker file (can not fit code into memory)

    MSP430F5438A Linker file (can not fit code into memory)

    This question is not answered
    Russell Lemburg
    Posted by Russell Lemburg
    on Jul 30 2012 14:01 PM
    Prodigy230 points
    LEDGoggles_MSP430_Sw_Rev_B_F5438A.zip

    Hello,

    I'm having trouble with getting a program to fit into flash on an MSP430F5438A. The code size is ~50K, and the total flash memory on the MSP430F5438A is 256K. This uC has 4 flash sections (SLAS612C, p. 14).  If I force things around, the program will sometimes load "successfully" but Code Composer will never reset the CPU (the program will just load, but will not execute). 

    My entire code size is a little larger than the first flash section defined in the datasheet (SLAS612C, p. 14)

    Here's the error (entire project attached as well):


    Program will not fit into available memory.  placement with alignment fails for section ".cinit" size 0x34 .  Available memory ranges: FLASH        size: 0xa380       unused: 0x28         max hole: 0x28    lnk_msp430f5438a.cmd   line 124    C/C++ Problem

    I understand what the error message means, but if I change any of the FLASH or FLASH2 sections, I create all sorts of strange overlaps, and end up blowing the security fuse. Basically my question is: how do I get a large .code base to allocate all the 256K of memory? I have all optimizations turned on for size in linker options, but I cannot figure out how to specify .code to span all 4 flash sections.

    msp430f5438a.cmd

    MEMORY

    {

    .....

        //Here is where the flash range is defined
        FLASH                   : origin = 0x5C00, length = 0xA380
        FLASH2                  : origin = 0x10000,length = 0x35C00

        INT00                   : origin = 0xFF80, length = 0x0002

    .....

        INT62                   : origin = 0xFFFC, length = 0x0002
        RESET                   : origin = 0xFFFE, length = 0x0002
    }

    SECTIONS
    {
        .bss        : {} > RAM                /* GLOBAL & STATIC VARS              */
        .data       : {} > RAM                /* GLOBAL & STATIC VARS              */
        .sysmem     : {} > RAM                /* DYNAMIC MEMORY ALLOCATION AREA    */
        .stack      : {} > RAM (HIGH)         /* SOFTWARE SYSTEM STACK             */

        .text       : {} >> FLASH |  FLASH2   /* CODE                              */ Error usually here
        .text:_isr  : {} > FLASH2             /* ISR CODE SPACE                    */
        .cinit      : {} > FLASH              /* INITIALIZATION TABLES             */
        .const      : {} > FLASH | FLASH2     /* CONSTANT DATA                     */ Error usually here
        .cio        : {} > RAM                /* C I/O BUFFER                      */
        .pinit      : {} > FLASH              /* C++ CONSTRUCTOR TABLES            */
        .init_array : {} > FLASH              /* C++ CONSTRUCTOR TABLES            */
        .mspabi.exidx : {} > FLASH            /* C++ CONSTRUCTOR TABLES            */
        .mspabi.extab : {} > FLASH            /* C++ CONSTRUCTOR TABLES            */

        .infoA     : {} > INFOA              /* MSP430 INFO FLASH MEMORY SEGMENTS  */
        .infoB     : {} > INFOB
        .infoC     : {} > INFOC
        .infoD     : {} > INFOD

    .......

    }


    Best regards,


    Russell

    memory linker msp430f5438a command
    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    All Replies
    • Jeff Tenney
      Posted by Jeff Tenney
      on Jul 30 2012 17:46 PM
      Guru10795 points

      Hi Russell,

      I don't use CCS.  But it seems to me that the ".cinit : " line should be above the ".text : " line so that that linker places it first.

      To your specific question, it looks like the entire 256KB is configured correctly in the linker script and that the code will span appropriately.  It's just that ".cinit" apparently must reside in the lower 64K.  Again, I don't use CCS, so I don't know if the linker honors the order of sections listed, but I would move all sections that require "FLASH" __above__ all of the sections that can be "FLASH" or "FLASH2".

      Jeff

      PS.  Why does this command file apparently put ISRs in FLASH2 (@ 0x10000 and above)?  That doesn't seem right.

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Chester Gillon
      Posted by Chester Gillon
      on Jul 30 2012 18:49 PM
      Mastermind6315 points

      Try replacing the following part of the linker script:

       

      .bss : {} > RAM | RAM2 //Global and static variables
      .sysmem : {} > RAM | RAM2 //Dynamic memory alloc
      .stack : {} > RAM2 (HIGH) //Stack
      .text : {}>> FLASH //Code
       .text:_isr : {} > FLASH2 //Interrupt Service Routines
      With:

      .bss : {} > RAM | RAM2 //Global and static variables
      .sysmem : {} > RAM | RAM2 //Dynamic memory alloc
      .data : {} > RAM | RAM2
      .stack : {} > RAM2 (HIGH) //Stack
      .text : {}>> FLASH2 | FLASH //Code
       .text:_isr : {} > FLASH //Interrupt Service Routines

      The reasons for this are:

      1) With CCS 5.2 and MSP430 Compiler v4.1.1 the linker was reporting the warning:

      warning #10247-D: creating output section ".data" without a SECTIONS specification

      As a result the linker was placing the .data section in peripheral space rather than RAM which then leads to a crash. I don't know if you were getting the same warning, but it is a sign that the linker command file was originally generated for an older version of the MSP430 Compiler. Adding the .data section ensures the variables get placed in RAM.

      2) Setting the .text to be placed in FLASH2 in preference to FLASH allows the code to fit without getting the "can not fit code into memory". I don't understand why, but had a similar problem with a MSP430F5438 project.

      3) As Jeff already pointed out the .text:_isr needs to be placed in the first 64Kbytes of memory (as per the default linker script when a new MSP430F5438A project is created).
       

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Russell Lemburg
      Posted by Russell Lemburg
      on Jul 31 2012 13:19 PM
      Prodigy230 points

      Chester,

      This is a logical idea, and certainly fixes the issue of data being stored in the FLASH section, instead of RAM. However, when I make this correction, it blows the security fuse.

      Russell

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Russell Lemburg
      Posted by Russell Lemburg
      on Jul 31 2012 13:46 PM
      Prodigy230 points

      Jeff,

      Those definitions come from TI's CCS linker file via the "User Experience" application for this chip. I'm not sure why that's the case, but with very small code models, it seems to work.

      Seems like everyone using micros at TI use IAR Workbench. If so, why does TI even create this tool at all?

      Russell

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Leo Hendrawan
      Posted by Leo Hendrawan
      on Jul 31 2012 17:08 PM
      Mastermind27240 points

      Hi Russel,

      Russell Lemburg

      Seems like everyone using micros at TI use IAR Workbench. If so, why does TI even create this tool at all?

      As far as i know, IAR is much more expensive than CCS.

      Regards,

      Leo Hendrawan

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Chester Gillon
      Posted by Chester Gillon
      on Jul 31 2012 17:15 PM
      Mastermind6315 points

      Russell Lemburg
      This is a logical idea, and certainly fixes the issue of data being stored in the FLASH section, instead of RAM. However, when I make this correction, it blows the security fuse.

      So that I am looking at the correct information, can you please post:

      a) The current lnk_msp430f5438a.cmd linker command file.

      b) The CCS console build output for a rebuild of the project, to see if there are any #10247-D: creating output section "<section>" without a SECTIONS warnings. See Should linker warning #10247-D really be an error for why these warnings are a sign that the linked program may not run.

      (it the linker ends up placing sections intended for ram in the peripheral address space the start-up code can get stuck continuously generating watchdog resets which means CCS may report that the security fuse is blown)

      c) The LEDGoggles_MSP430_Sw_Rev_B_F5438A.map file produced by the linker, to be able to check where sections have been placed in memory.

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Russell Lemburg
      Posted by Russell Lemburg
      on Aug 03 2012 12:24 PM
      Prodigy230 points
      LEDGoggles_map_and_cmd.zip

      Chester,

      Thanks for the reply.

      Yes, I've read over the Should linker warning #10247-D really be an error article. This was sort of what we thought was happening, but CCS no longer gives that warning.

      In zip file:

        lnk_msp430f5438a.cmd

        LEDGoggles_MSP430_Sw_Rev_B_F5438A.map

      CCS Build output:

      Description    Resource    Path    Location    Type
      #303-D typedef name has already been declared (with same type)    main.c    /LEDGoggles    line 32    C/C++ Problem
      #70-D integer conversion resulted in truncation    Factory.h    /LEDGoggles    line 204    C/C++ Problem
      #70-D integer conversion resulted in truncation    Factory.h    /LEDGoggles    line 214    C/C++ Problem
      #70-D integer conversion resulted in truncation    Factory.h    /LEDGoggles    line 224    C/C++ Problem

      Thank you

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Chester Gillon
      Posted by Chester Gillon
      on Aug 03 2012 16:03 PM
      Mastermind6315 points

      Looking at the linker command file and map file I can't see any problem with the sections. i.e. appears that the flash and RAM sections are correct.

      The project uses flash above 64Kbyte, has the CCS project selected the "large" memory model?

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Chester Gillon
      Posted by Chester Gillon
      on Aug 05 2012 09:43 AM
      Mastermind6315 points

      Chester Gillon
      The project uses flash above 64Kbyte, has the CCS project selected the "large" memory model?

      On further investigation, when a CCS project is created the CCS Project Properties -> CCS Build -> MSP430 Compiler -> Processor Options -> Specify the code memory model (--code_model) is blank.

      Having the option as "blank" causes the compiler to select the code memory model based upon the type of CPU - small for a CPU module (16-bit register / address bus) and large for a CPUX module (20-bit registers / address bus).

      To confirm the actual settings in use the CCS Project Properties -> CCS Build -> MSP430 Compiler -> Advanced Options -> Assembler Options -> Generate listing file (--asm_listing, -al) can be selected. The resulting .lst file reports the memory model used by the compiler.

      Given that the attached LEDGoggles_MSP430_Sw_Rev_B_F5438A.zip doesn't change the default memory models, it should be using a large code memory model and a small data model which is correct (the map file shows all constants and data are in the lower 32Kbytes).

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Chester Gillon
      Posted by Chester Gillon
      on Aug 05 2012 09:59 AM
      Mastermind6315 points

      The attached CCS project in the attached LEDGoggles_MSP430_Sw_Rev_B_F5438A.zip contains a system_pre_init.c to "Disable Watchdog timer to prevent reset during long variable initialization sequences".

      Using CCS 5.2.1.00018 and MSP430 compiler v4.1.0 to compile the project in the attached LEDGoggles_MSP430_Sw_Rev_B_F5438A.zip with the lnk2_msp430f5438a.cmd from the attached LEDGoggles_map_and_cmd.zip, the resulting linker map shows that the _system_pre_init function from the project system_pre_init.c gets linked into the executable:

      0001a2b4 0000000a system_pre_init.obj (.text:_system_pre_init)

      Whereas your LEDGoggles.map in the attached LEDGoggles_map_and_cmd.zip shows that the default _system_pre_init function from the run-time-library is used:

      00027af6 00000004 rts430x_lc_sd_eabi.lib : pre_init.obj (.text:_system_pre_init)

      The default default _system_pre_init function from the run-time-library doesn't disable the watchdog, so the executable may suffering from watchdog resets at start-up.

      Has anything in the project, apart from lnk2_msp430f5438a.cmd changed since LEDGoggles_MSP430_Sw_Rev_B_F5438A.zip was attached?

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Russell Lemburg
      Posted by Russell Lemburg
      on Aug 06 2012 12:18 PM
      Prodigy230 points

      Chester,

      This is a good suggestion. I've made sure that we are using the large memory model and small data model (this is correct based on the .map file). I thought I had these compiler arguments enabled.

      CCS has seemed to stop working with Spy-by-Wire as a result of this (I get a "device not recognized" if the FET430UIF is connected in a Spy-by-Wire configuration). However, I managed to get the code to store into memory using JTAG. If I break execution a second or so after running, I get the following runtime message:

      No source available for "_TI_zero_init(unsigned long, unsigned long) at 0x27810"

      Seems like the processor is resetting itself.

      I removed system_pre_init.c and disable the watchdog at the beginning of main().

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Russell Lemburg
      Posted by Russell Lemburg
      on Aug 06 2012 12:57 PM
      Prodigy230 points

      Including rts430x_lc_sd_eabi.lib in the runtime support library and adding system_pre_init.c seemed to work. I'm now able to compile and run the code (~90K), but ONLY WITH JTAG.


      CCS is giving me an "unknown device" if I connect with Spy-by-Wire.

      I could not find any documentation on compiler options for forcing either JTAG or Spy-by-Wire modes in CCS. I know in IAR you can specify either one explicitly.


      Russ

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Dung Dang
      Posted by Dung Dang
      on Aug 06 2012 13:12 PM
      Genius10820 points

      Russell,

      from your last post I wasn't sure whether you were able to completely resolve the issue. Could you confirm either scenario?

      As far as the .text: {} >> FLASH2 | FLASH is concerned, the splitting instruction essentially prioritizes splitting and placing .text objects into FLASH2 first and only switches to FLASH when it runs out of FLASH2 space. This is indicated in your map file with most of the code is located in FLASH2 and minimal space is consumed in FLASH.

      I gave your project a quick try, with the latest linker command file that you attached, as well as with some other combinations of placing .text to >/>> FLASH2 | FLASH, and the project seems to build. However, the interrupt vectors, especially the reset vector always shows up as 0xFFFF. This might be due to my hacked-up test setup, but I want to make sure whether you can see the same thing or it was something related to something specific in the code.

      Regarding the system_pre_init.c and its function int _system_pre_init(void), do you plan on adding any code in there other than the watchdog holding line? If not, you can safely remove the file and let CCS use the system default file. You'll need to add the watchdog line to the top of your main() function however.

      Regards,

      Dung

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Russell Lemburg
      Posted by Russell Lemburg
      on Aug 06 2012 13:25 PM
      Prodigy230 points

      Dung,

      The linker file is working now. most of the code should reside in FLASH2. That's now working.

      system_pre_init.c needs to be there. If I disable the watchdog in main, the processor stays in reset.

      The problem I am now having seems to be a result of fixing these other problems. That is, I can no longer debug with Spy-by-Wire. JTAG seems to be the only thing that works.

      Russell

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Chester Gillon
      Posted by Chester Gillon
      on Aug 06 2012 16:56 PM
      Mastermind6315 points

      Dung Dang
      I gave your project a quick try, with the latest linker command file that you attached, as well as with some other combinations of placing .text to >/>> FLASH2 | FLASH, and the project seems to build. However, the interrupt vectors, especially the reset vector always shows up as 0xFFFF. This might be due to my hacked-up test setup, but I want to make sure whether you can see the same thing or it was something related to something specific in the code.

      I just looked the project I built from the attachments. When 'hex430.exe --ti_txt' was run on the generated .out file, the reset vector, TIMER1_A0_VECTOR and TIMER1_A1_VECTOR are showing up as 0x0000!

      There are two warnings 'ignoring .CLINK directive' warnings which are probably related to the vectors being zero:

      **** Build of configuration Debug for project LEDGoggles_MSP430_Sw_Rev_B_F5438A ****

      C:\ti\ccsv5\utils\bin\gmake -k all
      'Building file: ../FFT_430.asm'
      'Invoking: MSP430 Compiler'
      "C:/ti_ccs5_2/ccsv5/tools/compiler/msp430_4.1.0/bin/cl430" -vmspx --abi=eabi -O4 --opt_for_speed=0 -g --include_path="C:/ti/ccsv5/ccs_base/msp430/include" --include_path="C:/ti_ccs5_2/ccsv5/tools/compiler/msp430_4.1.0/include" --define=__MSP430F5438A__ --diag_warning=225 --display_error_number --silicon_errata=CPU21 --silicon_errata=CPU22 --silicon_errata=CPU23 --silicon_errata=CPU40 --printf_support=minimal --preproc_with_compile --preproc_dependency="FFT_430.pp" "../FFT_430.asm"
      'Finished building: ../FFT_430.asm'
      ' '
      'Building file: ../main.c'
      'Invoking: MSP430 Compiler'
      "C:/ti_ccs5_2/ccsv5/tools/compiler/msp430_4.1.0/bin/cl430" -vmspx --abi=eabi -O4 --opt_for_speed=0 -g --include_path="C:/ti/ccsv5/ccs_base/msp430/include" --include_path="C:/ti_ccs5_2/ccsv5/tools/compiler/msp430_4.1.0/include" --define=__MSP430F5438A__ --diag_warning=225 --display_error_number --silicon_errata=CPU21 --silicon_errata=CPU22 --silicon_errata=CPU23 --silicon_errata=CPU40 --printf_support=minimal --preproc_with_compile --preproc_dependency="main.pp" "../main.c"
      "..\Factory.h", line 204: warning #70-D: integer conversion resulted in truncation
      "..\Factory.h", line 214: warning #70-D: integer conversion resulted in truncation
      "..\Factory.h", line 224: warning #70-D: integer conversion resulted in truncation
      "../main.c", line 23: warning #303-D: typedef name has already been declared (with same type)
      "C:\DOCUME~1\MR_HAL~1\LOCALS~1\Temp\0328013", WARNING! at line 34570:
      [W0000]
      Section .text:_isr:TIMER1_A0_ISR already has .RETAIN specified -
      ignoring .CLINK directive

      .clink

      No Assembly Errors, 1 Assembly Warning
      'Finished building: ../main.c'
      ' '
      'Building file: ../system_pre_init.c'
      'Invoking: MSP430 Compiler'
      "C:/ti_ccs5_2/ccsv5/tools/compiler/msp430_4.1.0/bin/cl430" -vmspx --abi=eabi -O4 --opt_for_speed=0 -g --include_path="C:/ti/ccsv5/ccs_base/msp430/include" --include_path="C:/ti_ccs5_2/ccsv5/tools/compiler/msp430_4.1.0/include" --define=__MSP430F5438A__ --diag_warning=225 --display_error_number --silicon_errata=CPU21 --silicon_errata=CPU22 --silicon_errata=CPU23 --silicon_errata=CPU40 --printf_support=minimal --preproc_with_compile --preproc_dependency="system_pre_init.pp" "../system_pre_init.c"
      'Finished building: ../system_pre_init.c'
      ' '
      'Building target: LEDGoggles_MSP430_Sw_Rev_B_F5438A.out'
      'Invoking: MSP430 Linker'
      "C:/ti_ccs5_2/ccsv5/tools/compiler/msp430_4.1.0/bin/cl430" -vmspx --abi=eabi -O4 --opt_for_speed=0 -g --define=__MSP430F5438A__ --diag_warning=225 --display_error_number --silicon_errata=CPU21 --silicon_errata=CPU22 --silicon_errata=CPU23 --silicon_errata=CPU40 --printf_support=minimal -z --stack_size=256 -m"LEDGoggles_MSP430_Sw_Rev_B_F5438A.map" --heap_size=256 --use_hw_mpy=F5 -i"C:/ti/ccsv5/ccs_base/msp430/include" -i"C:/ti_ccs5_2/ccsv5/tools/compiler/msp430_4.1.0/lib" -i"C:/ti_ccs5_2/ccsv5/tools/compiler/msp430_4.1.0/include" --reread_libs --warn_sections --display_error_number --rom --rom_model -o "LEDGoggles_MSP430_Sw_Rev_B_F5438A.out" "./system_pre_init.obj" "./main.obj" "./FFT_430.obj" -l"libc.a" "../lnk2_msp430f5438a.cmd"
      <Linking>
      "C:\DOCUME~1\MR_HAL~1\LOCALS~1\Temp\0354412", WARNING! at line 52802:
      [W0000]
      Section [1].text:_isr:TIMER1_A0_ISR already has .RETAIN specified -
      ignoring .CLINK directive

      .clink

      No Assembly Errors, 1 Assembly Warning
      'Finished building target: LEDGoggles_MSP430_Sw_Rev_B_F5438A.out'
      ' '

      **** Build Finished ****

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    12
    TI E2E™ Community
    • Support Forums
    • Blogs
    • Videos
    • Groups
    • Site Support & Feedback
    • Settings
    TI E2E™ Community Groups
    • TI University Program
    • Make the Switch
    • Microcontroller Projects
    • Motor Drive & Control
    Other Communities
    • Deyisupport
    • Designsomething.org
    • beagleboard.org
    • TI on Element 14
    • TI on TechXchangeSM
    Other Technical & Support Resources
    • WEBENCH® Design Center
    • Product Information Centers
    • Technical Documents
    • TI Design Network
    • TI Technical Articles
    • TI Training

    All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.

    Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms of Use of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms of Use of this site. TI, its suppliers and providers of content reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.

    Follow Us Texas Instruments on Facebook Texas Instruments on Twitter Texas Instruments on LinkedIn Texas Instruments on Google+
    TI Worldwide | Contact Us | my.TI Login | Site Map | Corporate Citizenship | mobile m.ti.com (Mobile Version)

    TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs and
    embedded processors, along with software, tools and the industry’s largest sales/support staff.

    © Copyright 1995-2013 Texas Instruments Incorporated. All rights reserved.
    Trademarks | Privacy Policy | Terms of Use