• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 54 subscribers
  • Views 2924 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

A little help booting needed. Adding boot.asm to an executable project isn't enough

steve spaeth
Prodigy 225 points

In the old days we used to create the startup code (boot.asm) it looks like this has been done automatically when the library is linked with the project.

I have a situation where I actually don't need to bring in the library (--disable_auto_rts) and instead include boot.asm into the main project.

I thought this would be easy, so I unzipped the std library source code (rtssrc.zip), and pulled in boot.asm rebuilt the project only to find I needed to include another file auto_init.asm... ...rebuilt again... ...added more files... ...this continued and now I have over 35 files and still need to add more files.  Some of the undefined symbols are found in standard library files such as memcpy, fflush, fputs, signal; the list is expanding.

I must be overlooking something:

  • Is there some preprocessor directives which need to be added to the project?
  • I would like to add at most a few files to the project necessary for initialization using the files from rtssrc; if this is even possible without a custom boot..asm.

Any help would be appreciated

LM3S5791

 

  • 0
    TI__Expert 5780 points

    Hi Steve,

    I'm not familar with the --disable_auto_rts compiler/linker switch, or boot.asm.  Which Cortex-M tool-chain are you using?  My understanding is that rtssrc.zip actually contains files for TI's C6000 DSPprocessor family.

     

  • 0 in reply to Jonathan Guy
    Prodigy 225 points

    I'm using the following:

    Code Composer Studio Version: 5.2.1.00018

    Stellaris LM3S5791

    Cortex M3 CPU

    compiler tms470

    Under directory c:\ti\ccsv5\tools\compiler\tms470\lib there is the rtssrc.zip file which contains the source with boot.asm

    Any help would be appreciated 

  • 0
    Prodigy 225 points

    I don't seem to be getting much help on this issue.  Is there a way flag the topic to support.  Is there additional information that might help the community provide some assistance.  There must have been a few projects/engineers in the world that have used the --disable_auto_rts directive and added the necessary boot.asm, auto_init.asm, and other files to a project.

    Any help would be appreciated.

  • 0 in reply to steve spaeth
    TI__Expert 5780 points

    Hi Steve,

    The RTS library is already well optimized and our experience is that the linker will only include the necessary functions.  Can you explain what you are trying to achieve with changing the RTS and startup code?

  • 0 in reply to Jonathan Guy
    Prodigy 225 points

    Sure, not a problem.  Our customer is in the aerospace industry and requires all code included in the project to be DO-178B Lvl A certified.  I have extracted the necessary STD library functions (i.e. from the rtssrc.zip) and created a CCS STD library.  I have utilized a third party tool for Unit Testing, test harness creation, and generating test results proving full MC/DC coverage.  I understand the linker removes all dead functions (i.e. --generate_dead_funcs_list) which is great, but the customer has included in our statement of work (SoW) a STD library deliverable project containing the source along with the Unit Test cases and test Result files illustrating full MC/DC coverage.

    My issue came about when linking the system together.  The STD library was automatically being linked into the build (duplicate functions/symbols).  I later discovered the bootstrap code is also part of the std:library.  It has been years; but I am familiar with creating a boot.asm to setup stack, interrupt vectors table, and etc.  Its great that many projects can be developed with this low-level start-up code kind of "hidden" away from the developer, but in this particular situation the customer has required our deliverable to include all source code used to build the system from the bootstrap, Stellaris driver library, STD library, and application code.

    We don't need to change any of the bootstrap or STD library functions; but the STD library, source, Unit Test & Results are a part of the deliverable.  BTW - I could create a completely new library for all the bootstrap source (e.g.  BOOT.lib).

    Some additional information:  No C++ code is used and No dynamically allocated memory functions are utilized.

    Comment:  In this particular project, only a small number of std:library functions are being used; and all have been optimized nicely.  One exception is the floorf function.  There are two noticable code coverage paths which are unreachable in the function; due to a local variable loIsZero which is assigned to 1 at the start of the function and later used in two different multiple conditional logic statements.  Although I am completely on the side-of-reason, which states something along the lines of "the deliverable shall provide source code with blank functionality, including full DO-178B Lvl A coverage, but excluding all third party provided library code"; I am stuck with already agreed upon decisions by upper management during the projects inception.

  • 0 in reply to steve spaeth
    TI__Expert 5780 points

    Steve,

    Thanks for the thorough description (we see a lot of folks reinventing the wheel when it comes to start-up code and standard libraries - clearly you understand what's needed).

    I've moved your post to the CCS forum, so that the TI CCS experts can answer your question about compiling a minimal RTS/boot solution.

  • 0
    TI__Guru**** 173310 points

    Steve,

    Let me try to offer some clarifications and suggestions.

    All C/C++ programs must be linked with a runtime support library that contains standard C/C++ functions and functions to manage the C/C++ environment. What gets linked in from the runtime library is highly dependent on your application code. As you have observed, the boot routine is always linked in (if you do not provide your own custom boot routine), and in addition there may be several other standard C runtime functions that may be required depending on what the application code uses. The linker will only pull in the required routines based on your application, and the link map file is the best place to look to get a summary of which runtime routines were actually linked in for a specific build.

    Typically, users who wish to use a customized boot routine simply extract boot.asm from the RTS sources, add it to their project and modify it to suit their needs. Then when they link the project, as long as their custom boot routine appears on the command line before the rts library, the custom version will be linked in instead of the default version in the rts library. In such cases the RTS library is still linked in to take care of other standard C/C++ functions. Since we provide the sources to the RTS library, are you not able to simply use it as-is?

    If you are saying that what you really need is a sub-set of the RTS library, I believe you could take that list of required source files (from rtssrc.zip) and create your own runtime library out of it. I haven't tried this myself so cannot guarantee its validity, but what I would suggest is to take a look at the link map file (generated by linking in the default RTS lib) to see which rts functions are being linked in, then extract those source files from the rtssrc and either add them to your project or create your own custom runtime library out of it. Note that if your app changes such that is either requires additional/different runtime functions or does not require some, the library may need to be adjusted/rebuilt.

  • 0 in reply to AartiG
    Prodigy 225 points

    Thanks for your quick response.  It looks as if I have been headed down the right path.

    AartiG said:

    Typically, users who wish to use a customized boot routine simply extract boot.asm from the RTS sources, add it to their project and modify it to suit their needs. Then when they link the project, as long as their custom boot routine appears on the command line before the rts library, the custom version will be linked in instead of the default version in the rts library. In such cases the RTS library is still linked in to take care of other standard C/C++ functions. Since we provide the sources to the RTS library, are you not able to simply use it as-is?

    We shouldn't need to change any of the low-level start-up code.  Also, at this point, I believe we likely will be able to use the RTS library as is (there may be one exception with the floorf function) but I will need to speak with upper management and the customer before answering firmly.

    AartiG said:

    If you are saying that what you really need is a sub-set of the RTS library, I believe you could take that list of required source files (from rtssrc.zip) and create your own runtime library out of it.

    This is exactly the approach I have been taking so I am glad I am on the right track.  I created a library project with the required "sub-set" of STD library files/functions.  In the main project I am linking in the library and using the --priority flag.  Everything builds fine and can be debugged, but I have two (2) questions.

    1)  I'm getting the following warning:  "warning #10252-D: Symbol "func" (pulled from /path/SubSet_STD.lib<func.obj>) defined in 2 places."

    I am a little worried this may have the customer/QA asking questions.  Have I done everything correctly and this warning is expected unless it is suppressed.  The main project does have --scan_libraries checked... ...it looks as if that is the culprit.

    2) As you suggested, the .map file is a great resource.  I will likely have to sit down with Quality Assurance, open up the map file, and show evidence the function in our "SubSet_STD.lib" is being linked to the system and the duplicate function is being ignored.  Any suggestions on an approach?

    One additional non-related question:

    I have some questions on compiler/linker flags - where is the best resource

    For instance:  

    • The flag --rom compared to the flag --rom_model?

  • 0 in reply to steve spaeth
    TI__Guru* 84285 points

    The --rom option is not related to --rom_model.  You almost certainly do not want to use --rom.

    The best documentation compiler and linker options is the user's guide.  You can find links to the user's guides at http://processors.wiki.ti.com/index.php/TI_Compiler_Information#Compiler_Manuals

  • 0 in reply to steve spaeth
    TI__Guru**** 173310 points

    steve spaeth said:
     I'm getting the following warning:  "warning #10252-D: Symbol "func" (pulled from /path/SubSet_STD.lib<func.obj>) defined in 2 places."



    I don't believe func.obj is from one of the source files from the standard runtime library. Is it or is it one of your custom files? Somehow it seems that there are two definitions for symbol "func". I would think the warning message would give the full path of where the two definitions are coming from, so you can double-check them.

  • 0 in reply to AartiG
    Prodigy 225 points

    My apology, I have double-quotes around "func" but was just attempting to illustrate the Warning, the #number, and the words "...defined in 2 places" without providing the function used verbatim.