Search

Technical Discussion Group Forum

This forum is provided for user discussion. While Beacon EmbeddedWorks support staff and engineers participate, Beacon EmbeddedWorks does not guarantee the accuracy of all information within in the Technical Discussion Group (TDG).

The "Articles" forums provide brief Articles written by Beacon EmbeddedWorks engineers that address the most frequently asked technical questions.

To receive email notifications when updates are posted for a Beacon EmbeddedWorks product download, please subscribe to the TDG Forum of interest.

TDG Forum

PrevPrev Go to previous topic
NextNext Go to next topic
Last Post 14 Aug 2003 10:03 AM by  miket@logicpd.com
putting code in onchip SRAM
 1 Replies
Sort:
You are not authorized to post a reply.
Author Messages

philburk@softsynth.com



New Member


Posts:
New Member


--
30 Jul 2003 04:45 PM
    I would like to direct that several files from my program go to onchip SRAM for faster execution.

    The program compiles and runs fine if I put it all together in off-chip SRAM using the default linker script.

    But when I put this in the linker script:

    . = 0x80000400;
    .text2 : { oscillator.* (.text) }

    I get errors like:
    Dwarf Error - invalid or unhandled FORM value 14.

    This post suggests I need a new binutils:
    http://gcc.gnu.org/ml/gcc/2002-02/msg00965.html

    I also get an error: "relocation truncated to fit: R_ARM_PC24".

    Apparently the jumps between code in external and internal SRAM is breakng the code relocation model.

    If you have any suggestions on how to get code into onchip SRAM, I would be happy to hear them.

    miket@logicpd.com



    New Member


    Posts:
    New Member


    --
    14 Aug 2003 10:03 AM
    I think you probably have two different problems.

    1. If you're using logicloader to load your image, you'll have to break it up
    into SDRAM and SRAM portions because the loader (currently) only loads
    contiguous segments. We will have an elf loader that loads based on section
    headers instead of the program header, but it isn't finished yet. In the meantime
    you should be able to use ld and objcopy to break up the file.

    2. The second problem is more difficult. If you *always* call only from SDRAM to
    SRAM, you could wrap all of the SRAM function calls in a snippet of assembly
    that does something like (this is rough & untested):

    foo.c: x_foo(void) { i++; } /* this file linked to SRAM */
    foostub.S: foo: ldr r4, ax_foo ; b r4 ; ax_foo: .word x_foo ; /* this file linked to SDRAM */

    But if you have to call both ways, it could get a little more difficult.

    There may be a way to get gcc to emit 32-bit ranged function calls too, which is
    really a better solution. Oh, yep. here it is: -mlong-calls, see the gcc docs.

    mt
    You are not authorized to post a reply.