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.

CCS/MSP430F67691: Undefined References

Part Number: MSP430F67691

Tool/software: Code Composer Studio

Hi Team,

I have a customer who is using an MSP430F67691 and running into a build problem.  They are currently using CCS 7.4.0.00015. Please see the description below and thanks for the help in advance:

"There are multiple CCS projects involved, but the essence of the problem shows up in one project.  It builds a relocatable output module.  There is no main() in this project.  When I look at the .map file generated by the linker, there are undefined references.  Most of these get resolved when the .lib file is linked in the “final” project, but some (MPUCTL0, MPUSAM, MPUSEG, etc.) don’t.  The unresolved references are to registers in the MSP430FR parts.  Of course the part I’m using doesn’t have these registers.  I can’t figure out why the build process is making reference to these non-existent registers."

Thanks again for the help and efforts.

Best,

Jerry

  • Hi Jerry,
    Some more details would be helpful, like the full build output in the build console. Also, a reproducible test case would be very helpfule

    Thanks
    ki
  • Hi Ki,

    Thanks for the response.  Following up from the customer:

    I include rts430x_lc_rd_eabi.lib in both project builds.  I want the run-time math functions to be in the lib created by both.  In the project that “fails”, the .map file has

    0000c000    0000001a     rts430x_lc_rd_eabi.lib : boot.c.obj (.text:_isr:_c_int00)

    In contrast, the .map file for the “good” project has

    0000001c     rts430x_lc_rd_eabi.lib : boot.c.obj (..text:_isr:_c_int00_noargs)

    I’m not sure of the mechanism, but the “noargs” part is critical as the code generated from boot.c does not include references to the mpu.  Without the “noargs”, the code from boot.c includes __mpu_init(), which creates the reference to non-existent registers. 

    How does the build process know to use the _c_int00_noargs entry?  The “good” project has a function main(), whereas the “bad” project has no main(). 

    Hope this helps and please let me know if any additional information is necessary.

    Thanks and best,

    Jerry

  • Thanks.
    I will bring this thread to the attention of the compiler experts for more analysis.

    ki
  • Jerry%20Leung said:
    the essence of the problem shows up in one project.  It builds a relocatable output module.  There is no main() in this project.

    What problem does this project solve?  Instead of a relocatable module, why not build a static library?

    Thanks and regards,

    -George

  • Hi George,

    Thanks for the feedback. I relayed the info to our customer. In the meantime, our customer also provided the tail end of the map file with compiler Ti 16.9.6.LTS

     

    00003176  _system_post_cinit                        

    UNDEFED   MPY32                                     

    UNDEFED   MPYS32                                     

    UNDEFED   OP2_32X                                   

    UNDEFED   RES16                                     

    UNDEFED   RES64                                     

    UNDEFED   SD24BMEM0_8                               

    UNDEFED   _SAFETY_DATA_END                          

    UNDEFED   _SAFETY_DATA_START                        

    UNDEFED   __STACK_END                               

    UNDEFED   __STACK_START                             

    UNDEFED   __TI_BINIT_Base                            

    UNDEFED   __TI_BINIT_Limit                          

    UNDEFED   __TI_CINIT_Base                           

    UNDEFED   __TI_CINIT_Limit                          

    UNDEFED   __TI_Handler_Table_Base                   

    UNDEFED   __TI_Handler_Table_Limit                  

    UNDEFED   __TI_INITARRAY_Base                       

    UNDEFED   __TI_INITARRAY_Limit                      

    UNDEFED   __TI_pprof_out_hndl                       

    UNDEFED   __c_args__                                

    UNDEFED   infoD_data                                

    UNDEFED   main                                      

    UNDEFED   mdu_crc_table                             

    UNDEFED   scaled_cable_resistance_u16               

     

    With TI 18.1.0.LTS  The offending symbols are highlighted.

     

    00003188  _system_post_cinit                         

    UNDEFED   MPUCTL0                                   

    UNDEFED   MPUCTL0_H                                 

    UNDEFED   MPUSAM                                    

    UNDEFED   MPUSEG                                    

    UNDEFED   MPY32                                      

    UNDEFED   MPYS32                                    

    UNDEFED   OP2_32X                                   

    UNDEFED   RES16                                     

    UNDEFED   RES64                                     

    UNDEFED   SD24BMEM0_8                               

    UNDEFED   _SAFETY_DATA_END                          

    UNDEFED   _SAFETY_DATA_START                        

    UNDEFED   __STACK_END                               

    UNDEFED   __STACK_START                              

    UNDEFED   __TI_BINIT_Base                           

    UNDEFED   __TI_BINIT_Limit                          

    UNDEFED   __TI_CINIT_Base                           

    UNDEFED   __TI_CINIT_Limit                          

    UNDEFED   __TI_Handler_Table_Base                   

    UNDEFED   __TI_Handler_Table_Limit                  

    UNDEFED   __TI_INITARRAY_Base                       

    UNDEFED   __TI_INITARRAY_Limit                      

    UNDEFED   __TI_pprof_out_hndl                       

    UNDEFED   __c_args__                                

    UNDEFED   __mpusam         

    Thanks for the help and effort,

    Jerry

  • Hi George,

    Here is a further update from the customer:

    There’s some unusual requirements that led me to building a relocatable module. Part of the application is safety-critical and subject to UL1998 requirements. The rest is not. The safety-critical part has a separate CRC which UL uses to audit that the code. If the CRC changes we have to resubmit to UL. We separate the safety code from the non-safety code so that we can make changes to the non-safety code without causing the CRC of the safety code to change.

    If I create a static library of the safety code it will not contain things like the run-time math routines used in the safety code. These would eventually get linked in the final link step, but I have no control over where they will be placed (actually I could, but it would involve explicitly enumerating them in the linker script, which is not practical). A subsequent change to non-safety code may result in a math routine being linked at a different location. This then results in a change in the binary of the safety code; its reference to the math routine changes.

    To get around this I create a relocatable module that includes the run-time libraries, or at least that part of them actually used by the safety code. The final link step places the safety code as a unit at a fixed place.

    If you perhaps know a better approach, please let us know.

    Thanks and best,
    Jerry
  • Jerry%20Leung said:
    We separate the safety code from the non-safety code so that we can make changes to the non-safety code without causing the CRC of the safety code to change.

    This is the first time I have heard of someone using a relocatable module for this purpose.  For me, that raises the question: How does everyone else handle getting UL1998 certification for part of a system? Whatever that is, maybe it is worth considering.

    Jerry%20Leung said:
    To get around this I create a relocatable module that includes the run-time libraries, or at least that part of them actually used by the safety code.

    Please show the exact commands you use to create this relocatable module.  Based on what I know so far, I don't understand why that module would have any startup code (_c_int00, the stack, etc)  in it.  Yet it does.

    Thanks and regards,

    -George

  • The compiler expects those symbols to be defined by a linker command file, or a command file included by the linker command file. If you are not using the default linker command file provided by CCS when you open a project, you'll need to make sure those symbols are defined in your own linker command file.
  • Hi Team,

    Please see below for the commands used:

    Commands for 16.9.6

    -vmspx --data_model=restricted --use_hw_mpy=F5 --include_path="C:/ti/ccsv7/ccs_base/msp430/include" --include_path="C:/ti/ccsv7/ccs_base/msp430/include" --include_path="C:/ti/ccsv7/tools/compiler/ti-cgt-msp430_16.9.6.LTS/include" --include_path="C:/Users/carl/Documents/Designs/AC48/firmware/common/inc" --include_path="C:/Users/carl/Documents/Designs/AC48/firmware/emeter-toolkit" --include_path="C:/Users/carl/Documents/Designs/AC48/firmware/mdu/inc" --include_path="C:/Users/carl/Documents/Designs/AC48/firmware/IEC60730/include" --advice:power="1,2,3,4,5.3,6,7,8,9,10,11,12,14" --define=__MSP430F67691__ --define=NO_WDT --define=ISR_TIMING_SIGNALS -g --printf_support=minimal --diag_warning=225 --diag_wrap=off --display_error_number --abi=eabi --silicon_errata=CPU21 --silicon_errata=CPU22 --silicon_errata=CPU40 --check_misra="required"

    -vmspx --data_model=restricted --use_hw_mpy=F5 --advice:power="1,2,3,4,5.3,6,7,8,9,10,11,12,14" --define=__MSP430F67691__ --define=NO_WDT --define=ISR_TIMING_SIGNALS -g --printf_support=minimal --diag_warning=225 --diag_wrap=off --display_error_number --abi=eabi --silicon_errata=CPU21 --silicon_errata=CPU22 --silicon_errata=CPU40 --check_misra="required" -z -m"ssm_exe.map" --heap_size=160 --stack_size=160 --cinit_hold_wdt=on -i"C:/ti/ccsv7/ccs_base/msp430/include" -i"C:/ti/ccsv7/ccs_base/msp430/include" -i"C:/ti/ccsv7/tools/compiler/ti-cgt-msp430_16.9.6.LTS/lib" -i"C:/ti/ccsv7/tools/compiler/ti-cgt-msp430_16.9.6.LTS/include" -i"C:/Users/carl/Documents/Designs/AC48/firmware/emeter-toolkit/Debug" -i"C:/ti/ccsv7/ccs_base/msp430/lib/5xx_6xx_FRxx" --reread_libs --diag_wrap=off --display_error_number --warn_sections --relocatable --xml_link_info="ssm_exe_linkInfo.xml" --use_hw_mpy=F5 --rom_model --unused_section_elimination=on


    Commands for 18.1.0

    -vmspx --data_model=restricted --use_hw_mpy=F5 --include_path="C:/ti/ccsv7/ccs_base/msp430/include" --include_path="C:/ti/ccsv7/ccs_base/msp430/include" --include_path="C:/ti/ccsv7/tools/compiler/ti-cgt-msp430_18.1.0.LTS/include" --include_path="C:/Users/carl/Documents/Designs/AC48/firmware/common/inc" --include_path="C:/Users/carl/Documents/Designs/AC48/firmware/emeter-toolkit" --include_path="C:/Users/carl/Documents/Designs/AC48/firmware/mdu/inc" --include_path="C:/Users/carl/Documents/Designs/AC48/firmware/IEC60730/include" --advice:power="1,2,3,4,5.3,6,7,8,9,10,11,12,14" --define=__MSP430F67691__ --define=NO_WDT --define=ISR_TIMING_SIGNALS -g --printf_support=minimal --diag_warning=225 --diag_wrap=off --display_error_number --abi=eabi --silicon_errata=CPU21 --silicon_errata=CPU22 --silicon_errata=CPU40 --check_misra="required"

    -vmspx --data_model=restricted --use_hw_mpy=F5 --advice:power="1,2,3,4,5.3,6,7,8,9,10,11,12,14" --define=__MSP430F67691__ --define=NO_WDT --define=ISR_TIMING_SIGNALS -g --printf_support=minimal --diag_warning=225 --diag_wrap=off --display_error_number --abi=eabi --silicon_errata=CPU21 --silicon_errata=CPU22 --silicon_errata=CPU40 --check_misra="required" -z -m"ssm_exe.map" --heap_size=160 --stack_size=160 --cinit_hold_wdt=on -i"C:/ti/ccsv7/ccs_base/msp430/include" -i"C:/ti/ccsv7/ccs_base/msp430/include" -i"C:/ti/ccsv7/tools/compiler/ti-cgt-msp430_18.1.0.LTS/lib" -i"C:/ti/ccsv7/tools/compiler/ti-cgt-msp430_18.1.0.LTS/include" -i"C:/Users/carl/Documents/Designs/AC48/firmware/emeter-toolkit/Debug" -i"C:/ti/ccsv7/ccs_base/msp430/lib/5xx_6xx_FRxx" --reread_libs --diag_wrap=off --display_error_number --warn_sections --relocatable --xml_link_info="ssm_exe_linkInfo.xml" --use_hw_mpy=F5 --rom_model --unused_section_elimination=on


    16.9.6 works, 18.1.0 doesn’t. See the .map snippets below.

    Many symbols are undefined when I build the relocatable module. With 16.9.6 they are all resolved in the final link step. With 18.1.0 there are symbols associated with the FR memory controller that don’t get resolved because they don’t exist.

    Thanks again for the help and efforts.
    Best,
    Jerry
  • Jerry%20Leung said:
    See the .map snippets below.

    Something went wrong.  I don't see them.  

    I would prefer to see the entire map file from build of the relocatable module.  Please attach it to the next post.  So the forum will accept it, add the file extension .txt to it.  

    I want to see the map file because, when I perform test builds with the options shown above, nothing in the relocatable build gets allocated to an actual memory address.  Everything is located at address 0.   On the final link, it gets relocated to the actual address.  This is counter to what is said earlier about safety certification of the module.  Such certification rests, in part, on things being located at the same address in the relocatable module and in the final build.

    Switching topics ... I notice you use compiler version 18.1.0.LTS.  There is a later version 18.1.1.LTS available.  For what we are doing here, I don't think there is any difference between these two versions.  But, just to be safe, it would be ideal if you upgraded to version 18.1.1.LTS.

    Thanks and regards,

    -George

  • Please submit the map file from the build of the relocatable module.

    Thanks and regards,

    -George