Skip to main content
Kuikui
Associate III
September 2, 2010
Question

Codesourcery startup and link file for STM32

  • September 2, 2010
  • 11 replies
  • 2330 views
Posted on September 02, 2010 at 21:48

Codesourcery startup and link file for STM32

    This topic has been closed for replies.

    11 replies

    Tesla DeLorean
    Guru
    May 17, 2011
    Posted on May 17, 2011 at 14:05

    Don't know which linker script files or device you are using, but you need to make very sure that the RAM, FLASH and STACK are correctly described for the device you are using. If you say the RAM is 20K and the stack is at 0x20005000 you're going to get a fault on a 16K RAM STM32.

    Check the .MAP files also to see where the code/data/stack end up

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    xacc
    Associate II
    May 17, 2011
    Posted on May 17, 2011 at 14:05

    That looks like a C++ linker script.

    Just do what I did. Grab one from the STM32 Standard Peripheral library.

    The ones from TrueStudio looks all like C++ ones (those that do the call to __libc_init_array, etc).  The RIDE one seems to be only for a XL density device, but it is all that is needed for a C app. Just modify the memory section to match yours, and it should be good.

    Kuikui
    KuikuiAuthor
    Associate III
    May 17, 2011
    Posted on May 17, 2011 at 14:05

    Thanks for your answer clive1.

    I'm using an STM32F102R8.

    Here is my linker script :

    [quote]

    /**

     * <b>File:</b> stm32_flash.ld

     *

     * <b>Project:</b> FreeRTOS.org STM32 demo using Eclipse

     *

     * <b>Description:</b> Linker script to load the application in the STM32 internal flash.

     * It works with the startup_stm32f10x.c startup file.

     *

     * <b>Cereated:</b> 24/06/2008

     *

     * <dl>

     * <dt><b>Autor</b>:</dt>

     * <dd>Stefano Oliveri</dd>

     * <dt><b>E-mail:</b></dt>

     * <dd>software@stf12.net</dd>

     * </dl>

     */

    MEMORY

    {

        FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 128K

        SRAM (rwx) : ORIGIN = 0x20000000, LENGTH = 20K

    }

    SECTIONS

    {

        .text :

        {

            KEEP(*(.isr_vector))

            *(.text .text.* .gnu.linkonce.t.*)

            *(.rodata .rodata.* .gnu.linkonce.r.*)

            *(.eh_frame_hdr)

            *(.eh_frame)

            *(.ARM.extab* .gnu.linkonce.armextab.*)

            *(.gcc_except_table)

            *(.eh_frame_hdr)

            *(.eh_frame)

            . = ALIGN(4);

            KEEP(*(.init))

            . = ALIGN(4);

            __preinit_array_start = .;

            KEEP (*(.preinit_array))

            __preinit_array_end = .;

            . = ALIGN(4);

            __init_array_start = .;

            KEEP (*(SORT(.init_array.*)))

            KEEP (*(.init_array))

            __init_array_end = .;

            . = ALIGN(0x4);

            KEEP (*crtbegin.o(.ctors))

            KEEP (*(EXCLUDE_FILE (*crtend.o) .ctors))

            KEEP (*(SORT(.ctors.*)))

            KEEP (*crtend.o(.ctors))

            . = ALIGN(4);

            KEEP(*(.fini))

            . = ALIGN(4);

            __fini_array_start = .;

            KEEP (*(.fini_array))

            KEEP (*(SORT(.fini_array.*)))

            __fini_array_end = .;

            KEEP (*crtbegin.o(.dtors))

            KEEP (*(EXCLUDE_FILE (*crtend.o) .dtors))

            KEEP (*(SORT(.dtors.*)))

            KEEP (*crtend.o(.dtors))

            . = ALIGN(8);

            _etext = .;

        } >FLASH

        /* .ARM.exidx is sorted, so has to go in its own output section. */

        __exidx_start = .;

        .ARM.exidx :

        {

            *(.ARM.exidx* .gnu.linkonce.armexidx.*)

        } >FLASH

        __exidx_end = .;

        _flash_data = .;

        .data : AT (_flash_data)

        {

            _data = .;

            *(vtable)

            *(.data*)

            _edata = .;

        } > SRAM

        .bss :

        {

            _bss = .;

            *(.bss*)

            *(COMMON)

            _ebss = .;

            _end = .;

            __end = .;

        } > SRAM

    }

    /* end of allocated ram _end */

    PROVIDE( _heap = _end );

    /* end of the heap -> align 8 byte */

    PROVIDE ( _eheap = ALIGN(ORIGIN(SRAM) + LENGTH(SRAM) - 8 ,8) );

    [/quote]

    But I can't see any definition of the stack address ..

    xacc
    Associate II
    May 17, 2011
    Posted on May 17, 2011 at 14:05

    The startup files are in the CMSIS library under the DeviceSupport directory.

    The linker scripts work with those files.

    Kuikui
    KuikuiAuthor
    Associate III
    May 17, 2011
    Posted on May 17, 2011 at 14:05

    And what about the startup code ?

    lipin
    Associate III
    May 17, 2011
    Posted on May 17, 2011 at 14:05

    I would try startup from gcc_ride7 afterall codesourcery its gcc or great startup files from crossworks (if its legal).

    Kuikui
    KuikuiAuthor
    Associate III
    May 17, 2011
    Posted on May 17, 2011 at 14:05

    Yes, but none of these startup files are dedicated to codesourcery's toolchain.

    Tesla DeLorean
    Guru
    May 17, 2011
    Posted on May 17, 2011 at 14:05

    MEMORY /* STM32F102R8 64K FLASH, 10K RAM */

    {

        FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 64K

        SRAM (rwx) : ORIGIN = 0x20000000, LENGTH = 10K

    }

    Check also _stack, and _estack in .MAP file generated by the linker. And more generally verify that the RAM based allocations are in the 20000000..200027FF range. The linker should choke if the limits in the script are exceeded, but if those are wrong the CPU will fault as your initialization routines touch memory that is not present.

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    domen23
    Associate II
    May 17, 2011
    Posted on May 17, 2011 at 14:05

    How about you do what clive1 said and fix the linker script so RAM and FLASH sizes match?

    xacc
    Associate II
    May 17, 2011
    Posted on May 17, 2011 at 14:05

    I have no problem using them with CodeSourcery.

    It's the only decent GCC toolchain I found in fact and the only one I use.

    Edit: I did have to change 1 thing to make it compile via Eclipse. Change the file extension of the startup assembler file to uppercase (from 's' to 'S'), but that is an Eclipse issue of course :)