• Locked Locked
  • Replies 10 replies
  • Subscribers 56 subscribers
  • Views 1091 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.

Excluding Start Code

Alex K.
Expert 7820 points

I am trying to make a CCS project that only compiles and sends to the .txt file only the source code functions, nothing else.


For example any CCS compiled project has certain compiler init code.  Like set the stack pointer, clear certain memory, before the actual functions are run.  Usually there are also interrupt vectors that are also set.  I am trying to prevent that from being programmed to the device.

Example code that needs to not be compiled:

.text

0 0000f840 00000096
0000f840 0000005e rts430_eabi.lib : autoinit.obj (.text:_auto_init)
0000f89e 0000001a : boot.obj (.text:_c_int00_noexit)
0000f8b8 00000010 : epilog.obj (.text)
0000f8c8 00000006 : isr_trap.obj (.text:__TI_ISR_TRAP)
0000f8ce 00000004 : pre_init.obj (.text:_system_pre_init)
0000f8d2 00000004 : exit.obj (.text:abort)

Also the interrupt vectors should not be in the .txt file as well.  Only the functions that are present in the source code to be compiled should be present in the .txt file.

Is this possible with the CCS compiler?

  • TI__Genius 9225 points

    Alexander,

    Re: the interrupt vectors, of course, you could simply exclude their source from the project.  But I don't know if there's a way to suppress the init code from being generated at all.  I'm guessing you're not interested in re-writing your app in assembly...

    This is probably a question for the CCS forum -- I'll move it there now. 

    Can I ask the reason behind it?  Maybe there's another solution. 

    Regards,
    Keith

  • in reply to Keith Quiring
    TI__Expert 7820 points

    This solution is needed for a MCU that already has the information (init, vectors) in its ROM.  It needs the extra code programmed into it (to re-writeable memory) to add functionality.

  • in reply to Alex K.
    TI__Guru 61235 points

    The RAM autoinitialization model (linker -cr option) for the cgtools will NOT include the C startup code.

    Regards,

    David

  • TI__Guru* 84285 points

    Does the new function refer to any symbols (such as functions) that are already in ROM?

  • in reply to David M. Alter
    TI__Expert 7820 points

    Selecting the RAM autoinitialization model still generated the startup code (there seemed to be no difference in size of it).  However when the blank option was selected in the drop down menu (neither RAM nor ROM auto init) then the startup code was removed.

  • in reply to Archaeologist
    TI__Expert 7820 points

    Yes the new functions do modify some of the RAM of the ROM code.  The new code was written in a way to make sure that the new variables were created pointing to the correct locations.

    No functions of the ROM were used.  However the ROM code calls these news functions on its own as it was designed to do.

  • in reply to Alex K.
    TI__Guru* 84285 points

    As long as there aren't any references in the new code to old symbols, you should just be able to set the entry point to the function you are compiling. Anything else might start to get a little complicated.

    Setting the entry point to something other than _c_int00 will prevent any startup code from being linked in (there are other ways, but this is probably the most expedient).  If you have more than one function, use the '-u' option on each of them to force the linker to keep them all.

  • in reply to Archaeologist
    Prodigy 40 points

    In C and C++ function main() (or _main()), or its caller, sets up all sorts of things, expecially in C++. Leave function main() out of your compile, and write your own in Assembler, and link in the main-less C code, and pretend it's one big chunk of assembly code - this should work fine, as long as you duplicate all the functionality of main() required by the C code. Of course, the linker may get its fingers in there too with interrupt vectors and the like, or more likely the run-time system. You might have to re-write some library functions too in assembler to avoid whatever it is you are trying to avoid. Sounds like a lot of work, and generally there's a lot of subtle complexity in that code (setting up the heap, threads, memory protection, initializing IO devices and files, setting up the root exception handler - all kinds of stuff).

    Probably easier to live with it; maybe you can clobber the interrupt vectors (at early)  runtime somehow. Just branching to your code is very risky without fully understanding what all that prefix code does for you.

    You might try patching the start address in the link file and see what happens - wear protective clothing if you try this.

  • TI__Guru**** 253380 points

    Alexander Kozitsky said:
    I am trying to make a CCS project that only compiles and sends to the .txt file only the source code functions, nothing else.

    That is an unusual use case.  What overall problem are you solving?  There might be a better way to do it.

    I have a suggestion to consider.  Though I have not tried it, I'm confident it will work.  The general idea is to partial link together only the code you require.  You don't say which target CPU you use, so here are all the compiler tools manuals.  Use the Assembly Language Tools User's Guide for your target.  Find the section titled Partial (Incremental) Linking.  There are several details to consider.  If you think it will work for you, then use the --relocatable option when linking.

    Thanks and regards,

    -George

  • in reply to George Mock
    TI__Expert 7820 points

    So I did get it working to my needs, yesterday.

    The use case, is that I need to "patch" in some functions to an MSP430 that already has the main program in ROM. With the standard CCS build you get the init or start code and interrupt vector with any compile.

    If this was for my use case, I could have deleted the start binary in the .txt file and programmed only the functions that i need.  However we need a use case that a customer who is using the chip can easily do it on their own.

    I was able, with some help here, to find a way to with project setting described above, to completely prevent the start code from being generated.  Also with some modification to the .cmd file the interrupt vector definitions are also not present in the .txt file.  

    So now, the user can modify the C functions, then compile and program into the target MSP430 and not corrupt the interrupt vectors(which exist in FRAM) and not reset the SP of the ROM with unnecessary start code.