Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Elektroda.pl
Computer ControlsComputer Controls
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

[AT91SAM7S256][C++/yagarto] error: no memory region specifi.

19 Mar 2009 20:52 2463 9
  • Level 12  
    Witam,
    Po wielkich meczarniach, przesiadlem sie z Keil na Yagarto i Code::Blocks. Mam natomiast problem (prawdopodobnie) ze skryptem linkera. Otoz gdy probuje uzyc jakiejs funkcji z biblioteki lib_AT91SAM7S256.h, dostaje blad:

    Quote:

    e:/program files/yagarto/bin/../lib/gcc/arm-elf/4.3.3/../../../../arm-elf/bin/ld.exe: error: no memory region specified for loadable section `.text.NAZWA_FUNKCJI_Z_LIB'


    Oto skrypt linkera (z przykladow Yagarto):
    Code:

    /****************************************************************************
    *  Copyright (c) 2006 by Michael Fischer. All rights reserved.
    *
    *  Redistribution and use in source and binary forms, with or without
    *  modification, are permitted provided that the following conditions
    *  are met:
    *
    *  1. Redistributions of source code must retain the above copyright
    *     notice, this list of conditions and the following disclaimer.
    *  2. Redistributions in binary form must reproduce the above copyright
    *     notice, this list of conditions and the following disclaimer in the
    *     documentation and/or other materials provided with the distribution.
    *  3. Neither the name of the author nor the names of its contributors may
    *     be used to endorse or promote products derived from this software
    *     without specific prior written permission.
    *
    *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
    *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
    *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
    *  FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
    *  THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
    *  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
    *  BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
    *  OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
    *  AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
    *  OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
    *  THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
    *  SUCH DAMAGE.
    *
    ****************************************************************************
    *
    *  History:
    *
    *  30.03.06  mifi   First Version
    ****************************************************************************/


    ENTRY(ResetHandler)
    SEARCH_DIR(.)

    /*
     * Define stack size here
     */
    FIQ_STACK_SIZE = 0x0100;
    IRQ_STACK_SIZE = 0x0100;
    ABT_STACK_SIZE = 0x0100;
    UND_STACK_SIZE = 0x0100;
    SVC_STACK_SIZE = 0x0400;


    MEMORY
    {
      ram : org = 0x00200000, len = 64k
    }

    /*
     * Do not change the next code
     */
    SECTIONS
    {
      .text :
      {
        *(.vectors);
        . = ALIGN(4);
        *(.init);
        . = ALIGN(4);
        *(.text);
        . = ALIGN(4);
        *(.rodata);
        . = ALIGN(4);
        *(.rodata*);
        . = ALIGN(4);
        *(.glue_7t);
        . = ALIGN(4);
        *(.glue_7);
        . = ALIGN(4);
        etext = .;
      } > ram

      .data :
      {
        PROVIDE (__data_start = .);
        *(.data)
        . = ALIGN(4);
        edata = .;
        _edata = .;
        PROVIDE (__data_end = .);
      } > ram

      .bss :
      {
        PROVIDE (__bss_start = .);
        *(.bss)
        *(COMMON)
        . = ALIGN(4);
        PROVIDE (__bss_end = .);

        . = ALIGN(256);

        PROVIDE (__stack_start = .);

        PROVIDE (__stack_fiq_start = .);
        . += FIQ_STACK_SIZE;
        . = ALIGN(4);
        PROVIDE (__stack_fiq_end = .);

        PROVIDE (__stack_irq_start = .);
        . += IRQ_STACK_SIZE;
        . = ALIGN(4);
        PROVIDE (__stack_irq_end = .);

        PROVIDE (__stack_abt_start = .);
        . += ABT_STACK_SIZE;
        . = ALIGN(4);
        PROVIDE (__stack_abt_end = .);

        PROVIDE (__stack_und_start = .);
        . += UND_STACK_SIZE;
        . = ALIGN(4);
        PROVIDE (__stack_und_end = .);

        PROVIDE (__stack_svc_start = .);
        . += SVC_STACK_SIZE;
        . = ALIGN(4);
        PROVIDE (__stack_svc_end = .);
        PROVIDE (__stack_end = .);
        PROVIDE (__heap_start = .);
      } > ram

    }
    /*** EOF ***/


    Jak w sekcji .text. dodam do niego

    Code:

        *(.text.NAZWA_FUNKCJI_Z_LIB);
        . = ALIGN(4);


    to program sie kompiluje, ale po odpaleniu programu na mikrokontroler nic sie nie dzieje.

    Napisalem prosty programik, zeby przetestowac czy w ogole cos bedzie dzialac, ale niestety nie dziala...

    Code:

    int main() {
        AT91F_PIOA_CfgPMC();
        AT91F_PIO_CfgOutput(AT91C_BASE_PIOA, AT91C_PIO_PA11);

        while(1)
        {
            AT91F_PIO_ClearOutput(AT91C_BASE_PIOA, AT91C_PIO_PA11);

            for(int i = 0; i < 5000; i++)
            {
            }

            AT91F_PIO_SetOutput(AT91C_BASE_PIOA, AT91C_PIO_PA11);
        }

        return 0;
    }


    Plik startup jest z przykladow Yagarto.

    Log z kompilacji

    Quote:

    Build started on: 19-03-2009 at 20:50.56
    Build ended on: 19-03-2009 at 20:50.56

    -------------- Build: Debug_RAM in MySAM7 ---------------
    arm-elf-g++.exe -mthumb-interwork -mlittle-endian -Wfatal-errors -Wall -g -mcpu=arm7tdmi -gdwarf-2 -fomit-frame-pointer -fverbose-asm -I"E:\Program Files\yagarto\arm-elf\include" -c startup.s -o obj\Debug_RAM\startup.o
    arm-elf-g++.exe -mthumb-interwork -mlittle-endian -Wfatal-errors -Wall -g -mcpu=arm7tdmi -gdwarf-2 -fomit-frame-pointer -fverbose-asm -I"E:\Program Files\yagarto\arm-elf\include" -c src\main.cpp -o obj\Debug_RAM\src\main.o
    arm-elf-g++.exe -L"E:\Program Files\yagarto\arm-elf\lib" -o bin\Debug_RAM\MySAM7.elf obj\Debug_RAM\startup.o obj\Debug_RAM\src\main.o -mcpu=arm7tdmi -nostartfiles --cref,--no-warn-mismatch -T sam7s256_ram.ld
    e:/program files/yagarto/bin/../lib/gcc/arm-elf/4.3.3/../../../../arm-elf/bin/ld.exe: error: no memory region specified for loadable section `.text.AT91F_PIO_CfgOutput'
    collect2: ld returned 1 exit status
    Process terminated with status 1 (0 minutes, 0 seconds)
    0 errors, 0 warnings


    Mecze sie z tym kompilatorem juz 4 dni i nic nie moge wskorac...
  • Computer ControlsComputer Controls
  • Helpful post
    MCUs specialist
    A na jakiej podstawie stwierdzasz, że nie działa?

    Co do linkera, to dodaj tam linijki:

    . = ALIGN(4);
    *(.text.*);

    zaraz za sekcją .text i będzie ok.

    4\/3!!
  • Computer ControlsComputer Controls
  • Level 12  
    Freddie Chopin wrote:
    A na jakiej podstawie stwierdzasz, że nie działa?

    To programik do prostego migania dioda. Kiedy podlaczam do PA11 diode, to nie miga niestety. W keilu, przy tym samym kodzie migala.

    Freddie Chopin wrote:

    Co do linkera, to dodaj tam linijki:

    . = ALIGN(4);
    *(.text.*);

    zaraz za sekcją .text i będzie ok.

    4\/3!!


    Serdecznie dzieki :)!!!

    Edit:
    No i po probie uzycia vsprintf dostaje:

    Quote:

    Build started on: 20-03-2009 at 00:22.44
    Build ended on: 20-03-2009 at 00:22.44

    -------------- Build: Debug_RAM in MySAM7 ---------------
    arm-elf-g++.exe -mlittle-endian -Wfatal-errors -Wall -g -mcpu=arm7tdmi -gdwarf-2 -fomit-frame-pointer -fverbose-asm -I"E:\Program Files\yagarto\arm-elf\include" -c startup.s -o obj\Debug_RAM\startup.o
    arm-elf-g++.exe -mlittle-endian -Wfatal-errors -Wall -g -mcpu=arm7tdmi -gdwarf-2 -fomit-frame-pointer -fverbose-asm -I"E:\Program Files\yagarto\arm-elf\include" -c src\main.cpp -o obj\Debug_RAM\src\main.o
    arm-elf-g++.exe -L"E:\Program Files\yagarto\arm-elf\lib" -o bin\Debug_RAM\MySAM7.elf obj\Debug_RAM\startup.o obj\Debug_RAM\src\main.o -mcpu=arm7tdmi -nostartfiles --cref,--no-warn-mismatch -T sam7s256_ram.ld

    E:\Program Files\yagarto\arm-elf\lib\libc.a(lib_a-syscalls.o): In function `_sbrk':
    C:\msys\1.0\home\yagarto\newlib-build\arm-elf\newlib\libc\sys\arm/../../../../../../newlib-1.17.0/newlib/libc/sys/arm/syscalls.c:498: undefined reference to `end'
    collect2: ld returned 1 exit status
    Process terminated with status 1 (0 minutes, 0 seconds)
    1 errors, 0 warnings



    Edit 2:

    http://forum.sparkfun.com/viewtopic.php?t=539...t=15&sid=3e94b257d0aa271231cebcd4fe6a5756

    Zamienilem w swoim skrypcie linkera

    Code:
        PROVIDE (__stack_start = .); 
    
    ...
         PROVIDE (__stack_end = .);

    na
    Code:

         PROVIDE (start = .);
    ...
         PROVIDE (end = .);
    . Blad nie wystepuje, ale zmiana zrobiona kompletnie na czuja :P. Czy dobrze?

    Dodano po 4 [godziny] 44 [minuty]:

    Kolejna noc nieprzespana, ale...

    Udalo mi sie uruchomic program w trybie ROM, czyli uruchamianego z flasha. Niestety po kompilacji powtarza sie problem z duzym plikiem bin.

    Rozwiazalem go w taki sposob. Jest to prowizorka, dlatego prosilbym zaawansowanych o jakies bardziej eleganckie rozwiazanie.

    W skrypcie linkera dla trybu ROM mam

    Code:

    MEMORY
    {
      rom : org = 0x00100000, len = 256k
      ram : org = 0x00200000, len = 64k
    }

    /*
     * Do not change the next code
     */
    SECTIONS
    {
      .text :
      {
        // tu struktura pamieci
      } > rom

      .data :
      {
        // tu struktura pamieci
      } > rom // <------- tutaj oryginalnie jest "ram" i plik ma + 1mb wiecej. Po zmianie na rom plik bin uzyskuje normalny rozmiar.


    Jak to elegancko rozwiazac? Wydaje mi sie, ze linker niepotrzebnie mapuje caly obszar 1MB.

    Kolejna sprawa, to program kompilowany w trybie RAM nie uruchamia sie. Mniemam, ze problemem jest tutaj mapowanie pamieci. Mapowanie u mnie wyglada tak:

    Code:

        FLASH_BASE      = 0x00100000
        RAM_BASE        = 0x00200000

        MC_BASE         = 0xFFFFFF00
        MC_RCR          = 0x00

    _vectors:
       ldr pc, ResetAddr       /* Reset */
       ldr pc, UndefAddr       /* Undefined instruction */
       ldr pc, SWIAddr          /* Software interrupt */
       ldr pc, PAbortAddr       /* Prefetch abort */
       ldr pc, DAbortAddr       /* Data abort */
            nop
            ldr pc, [pc,#-0xF20]
            ldr pc, [pc,#-0xF20]


    ResetAddr:      .word ResetHandler
    UndefAddr:      .word UndefHandler
    SWIAddr:        .word SWIHandler
    PAbortAddr:     .word PAbortHandler
    DAbortAddr:     .word DAbortHandler
    ReservedAddr:   .word 0
    IRQAddr:        .word IRQHandler
    FIQAddr:        .word FIQHandler

        /* Insert vectors to RAM */
        .ifdef RAMRUN
            adr     r8, _vectors
            ldr     r9, =RAM_BASE
            ldmia   r8!, {r0-r7}
            stmia   R9!, {r0-r7}
            ldmia   r8!, {r0-r7}
            stmia   r9!, {r0-r7}

            ldr     r0, =MC_BASE
            mov     r1, #1
            str     r1, [r0, #MC_RCR]
        .endif


    Kod przerobilem z pliku SAM7S.s keila, wiec wydaje sie, ze powinno byc ok.

    Bardzo prosze o pomoc :).
  • Helpful post
    User removed account  
  • Level 18  
    Użyj takiej komendy w skrypcie linkera:

    .data :
    {
    . = ALIGN(4);
    _data = .;
    *(.data)
    *(.data*)
    . = ALIGN(4);
    _edata = .;
    } >ram AT >rom

    _load_data = LOADADDR(.data);

    W ten sposób informujesz linkera, że sekcja .data ma być umieszczona w pamięci RAM, a dane do inicjalizacji zmiennych tej sekcji są w pamięci ROM. Do tego musisz mieć w startupie komendy, które skopiują dane z ROMu do RAMu, przed wywołaniem funkcji main. Ja użyłem tu symbolu _load_data, w innych implementacjach zamiast _load_data jest symbol .etext czyli koniec sekcji .text, tylko wtedy sekcja .data musi być bezpośrednio za sekcją .text. Oto przykład komend do kopiowania zmiennych do sekcji .data

    ldr R1, =_load_data
    ldr R2, =_data
    ldr R3, =_edata
    l2: cmp R2, R3
    ldrlo R0, [R1], #4
    strlo R0, [R2], #4
    blo l2
    ...............

    Gdy użyjesz twojego skryptu:
    .data :
    {
    // tu struktura pamieci
    } > rom

    to twoje zmienne będą tylko do odczytu.

    Poczytaj trochę o poleceniach w skrypcie linkera to zrozumiesz o co tu chodzi.
  • Level 12  
    albertb wrote:
    Czytam sobie Twoje posty w tym wątku i poprzednim.
    I widzę, że się totalnie miotasz próbując kleić różne rozwiązania, co przy braku wiedzy nie przynosi pożądanego skutku.
    Trudno też Ci pomóc, bo załatanie jednej czy dwóch dziur ,które ktoś zauważy nie naprawia całości.
    Weź sobie trochę na wstrzymanie z pisaniem programu, a spróbuj zrozumieć zależności pomiędzy architekturą ARM, kompilatorem, linkerem oraz skryptami startowymi.
    Wydaje mi się, że dobrą lekturą będzie dla Ciebie
    http://www.embedded.com/design/opensource/201802580
    Na końcu masz linki do wcześniejszych artykułów w serii.

    Powodzenia
    Albert


    Masz racje, ale czas mnie goni. Nie mam w sumie czasu na zglebianie sie we wszystkie rzeczy - a to wlasnie drazni mnie w produktach open source. Jednak widze, ze bez dokladnego zrozumienia tego, co robie, nic nie zdzialam. Dzieki za linka - zabieram sie za lekture i caly weekend poswiece na pisanie wszystkiego od podstaw...
  • Level 20  
    Witam
    Kolego lamator, właśnie o to w tym wszystkim chodzi żeby zrozumieć to od podstaw. Nie musisz pisać wszystkiego od nowa, ściąg sobie jakiś gotowy projekt pod sam7 z przykładowym programem, a tam będziesz miał wszystko skonfigurowane. Wpisz w google:
    Using Open Source Tools for AT91SAM7S Cross Development revision C.pdf.
    To na początek powinno Ci starczyć 200 storn podstawowej wiedzy.
    Jak zainstalować, debugować we Flashu, ramie, opis skryptu linkera itp
    Pozdrawiam i powodzenia.
  • MCUs specialist
    ja bym tego nawet nie ściągał, bo informacje tam przedstawione są już tak stare, że...

    4\/3!!
  • Level 20  
    Witam
    no tak masz racje stare... z 15.05.07.
    na stronie http://www.embedded.com/design/opensource/201802580 z 27.08.07. Ciekawe co się zmieniło w podstawach... inaczej się kompiluje.
    Z C Source Files po kompilacji masz Object Files a z tego Output File (out lub .elf) a potem Binary File. Jest nowszy kompilator, czy źródła piszę się inaczej? Napisz proszę jeden dwa, trzy przykłady co się zmieniło. Człowiek uczy się przez całe życie, i głupi umiera. Jeśli są jakieś nowsze darmowe rozwiązania... będę wdzięczny...
    Pozdrawiam
  • MCUs specialist
    W kwestii kompilatora nic, ale w kwestii debuggowania i wgrywania kodu to praktycznie wszystko. No chyba że ja mowię o jakimś innym dokumencie, co jest bardzo możliwe bo ten który pamiętam był naprawdę staaaaaaary. [;

    Przy okazji czytania tego dokumentu (zakładając, że to ten o którym myślę) po prostu warto pamiętać, że niektóre rzeczy da się zrobić łatwiej, szybciej, prościej i wygodniej. Jeśli jest tam jakiś opis openocd, to warto pamiętać, że w openocd pod koniec roku 2008 zmieniło się praktycznie wszystko.

    4\/3!!