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.

How to generate trampoline calls without using -c linker option?



TMS320C6000 Assembly Language Tools v 7.0 (7.0.2)

DM648

 

Paragraph 7.4.30 (Generate Far Call Trampolines) in SPRU186S states that trampoline calls are generated automatically for when near calls will not work. This seems to work only when the -c linker option is used. How can I get trampoline calls when using the -r option? I have tried to explicitly enable trampolines and this does not work.

I am trying to load execution sensitive code in L2 memory and have it called by code running is external DDR memory. This is proving to be quite a problem.

 

Following error is returned: warning: relocation from function "..." to symbol "..." overflowed; the 31-bit relocated address ... is too large to encode in the 21-bit signed PC-relative field

 

This is true. L2 memory is at 0xa00000 and DDR is at 0xe0000000. Why aren't trampolines generated?

  • Trampolines are not generated for a partial (-r) link.  Why do you think you need a partial link?

    Thanks and regards,

    -George

  • I am by no means a linker expert. In trying to set my code up for my boot process, using partial link was the only way I could figure out how not to pull the RTS lib main into my load. I have my own boot loader and do not want to use the TI provided main. With the -c option I would end up with both my main and the RTS main.

    In my boot process I have a boot loader that resides in flash at 0xA0000000. It gains control at power on copies itself to L2 and then completes the boot process by using a boot table that contains the application start address, stack info, bss start, cinit data, pinit table, and a configurable number of application code/const data regions that get transferred from flash to memory. For example, Region 1 is the application .text code that gets copied to DDR, Region 2 is .fast data that gets copied to L2. The boot loader ten transfers execution to the application start address.

    I ended up using -r option because it allowed me to define my own cinit, pinit, and main. If there is a way to do this with the -c option, please help me.

    Regards,

    Eric

     

  • It is common to change out the TI supplied boot routine with a custom one.  There several ways to do it.  One easy way is to supply it as just another source file in the application level build.

    The compiler release distribution, in the \lib directory, contains a file rtssrc.zip.  Within that zip is a file named boot.c.  Extract it, modify it as you require, and build it like any other source file in the system.  Linking with -c will work just fine.  Be sure your resulting boot routine meets the description given in the Compiler User's Guide http://www.ti.com/lit/pdf/spru187 ,  in the section titled Run-Time Initialization.

    Do not use the linker -r option.  There is no reason to use -r in your situation.

    Thanks and regards,

    -George

  • Thanks. I changed over the application as you suggested and am using the RTS boot code, for now.

    In my earlier attempts in creating my own boot code, I was successful in extracting the boot.c modifying it for my own use and linking it in. But I found that using the -c option caused the linker to also add the RTS boot.c code in the link map even though it was never called. The only way to use my own boot and not have the RTS boot appear in the link map was to use the -r option. maybe I didn't do something right or maybe the linker has bugs...

     

    Eric

  • Are you using the '-e' option to declare that your own power-on reset function is the entry point?

  • Seems it no longer pulls in the RTS boot code. During my attempts to get this to work a couple of months ago I had a lot of trouble. The examples in the document are not very good (at least for my needs) and seem to be based on much older tools so when I finally got it to work using -r I left it that way. Going back now and inserting the -c option into my working setup works (after fixing other issues that are caused by the -c option). Things like having to define my stack with the -stack option and having to use _c_int00 as my start point to avoid warning nags from the linker.

    Anyway things make a little more sense. Thanks for your response.

    Eric