Main.bin ist 0bytes groß

Hallo, ich habe mir jetzt selber ein kleines Board mit einem STM32f103VBT6 gebaut und beschäftige mich jetzt mit der Programmierung. Als IDE verwende ich Eclipse und den Compiler von Codesourcery. Makefile und Linkerskripte sind von Lanchon. Das Problem ist, dass ich mit der aktuellen FWLib keine Main.bin Datei erzeugt bekomme bzw dass diese leer ist.

Der Code (siehe Anhang) ist das RCC Beispiel aus der FWLib. In der stm32f10x.h Header-Datei habe ich #define STM32F10X_MD und #define USE_STDPERIPH_DRIVER aktiviert. Wenn ich den Code "builde" gibt es keine Fehler. Was ich allerdings noch nicht implementiert habe ist die startup_stm32f10x_md.s Datei, da ich hier nicht sicher bin, wie genau ich das mache. Implementiere ich diese durch #include "startup_stm32f10x_md.s" in der main.h bekomme ich über 140 Fehler.

Zudem bin ich nicht sicher, ob ich die Makefile nicht noch abändern muss. So habe ich hier $(LIBSTM32_OBJS): stm32f10x_conf.h auskommentiert, da dies wohl keinen Sinn mehr macht? So ganz verstanden habe ich die Funktion der Makefile aber noch nicht.

Vielleicht sieht ja jemand auf den ersten Blick was falsch sein könnte.

hi
dein Makefile ist sehr komisch, es enthält z.B. keine rule für main.o, die Datei existiert aber...??? (siehe auch stm32f10x_it.o)
Evtl. solltest du mal ein paar Tutorials für über make und makefiles lesen...!

Welches Target steuert Eclipse an, wenn du "Build" sagst? all? (Ich hasse Eclipse, weil das da irgendwie total komisch ist. Ich verwende Code::Blocks, das find ich besser)

Es wäre mal interessant, was make sagt wenn du es manuell ausführst (no rule to make target?), und welches Make du verwendest (Solltest du ein Borland Make verwenden, dann solltest du dich dringend für GNU-Make entscheiden, ich hatte mit Bordland so meine Probleme.)

$(LIBSTM32_OBJS): stm32f10x_conf.h macht Sinn, es auszukommentieren nicht.
Warum siehe $(YOUR_MAKE_TUTORIAL)

Edit: Du linkst den Startupcode auch nicht dazu? Passt dein Startupcode überhaupt zum Linkerscript...?
Schaust du hier
https://www.roboternetz.de/phpBB2/viewtopic.php?t=34752
Ist zwar ein etwas anderer Compiler, aber daran solls nicht liegen.

Das Makefile und die Linkerskripte sind nicht von mir und stammen aus diesem Tutorial (http://www.mikrocontroller.net/articles/Cortex_M3_OCM3U) und funktionieren auch, allerdings nur mit einer alten Version der FWLib von ST. Ich habe jetzt versucht das ganze mit der aktuellen FWLib 3.1.2 zum Laufen zu bringen. Dies scheint dann aber wohl nicht mehr möglich zu sein.
$(LIBSTM32_OBJS): stm32f10x_conf.h habe ich auskommentiert, weil die alte Datei und die aus der neuen Lib nicht mehr viel gemeinsam haben und die stm32f10x_conf.h Datei mitlerweile in der stm32f10x.h Datei verlinkt wurde.

Achso, ich dachte wenn ich Codesourcery als Compiler nenne ist klar, dass ich mit cs-make "builde". Mit make bekomme ich natürlich deine oben genannte Fehlermeldung.
Eclipse habe ich gelesen soll halt recht gut sein. Ich würde aber auch jederzeit eine andere IDE verwenden. Mit Visual Studio von MS geht das wohl auch nicht so einfach, wenn überhaupt? Wäre aber mein Favourit, da ich mit diesem Programm schon lange gearbeitet habe. Aber von Code:blocks habe ich jetzt auch schon öfters gelesen und werde es mal testen.

Das Tutorial kannte ich sogar, der Link ist nur mitlerweile in meiner Datensammlung untergegangen.

Ich werde mich dann mal durch das Tutorial arbeiten. Hast du evtl. noch ein paar Tipps für mich? Ansonsten werde ich mich wieder melden, sobald ich nicht weiterkomme.

EDIT: code:blocks habe ich gerade gesehen, wurde das letzte mal im Februar 2008 aktualisiert. Wird das überhaupt noch weiterentwickelt?

Hi,
dass Linkerscript / Startupcode(!!) nicht von dir stammen ist ok, aber wenn du neuen Code dazuschreibst, musst du das Makefile schon anpassen. In der jetzigen Version gibt es für mehrere Dateien keine targets.
(Manche IDEs machen das automatisch, ist hier aber nicht der Fall.)
Dazu kommt, dass du z.B. deinen Startupcode weder assemblierst noch dazu linkst. Das _KANN_ also garnicht funktionieren.

Welches Make du nimmst hängt primär davon ab, welches make in den Verzeichnissen der PATH-Umgebung zuerst gefunden wird (Da muss man erst mal drauf kommen...) ;)

Welche IDE man verwendet ist Geschmackssache, ich mag Eclipse z.B. nicht. Was Visual Studio anbelangt müsste man damit auch arbeiten können, da gibts sicher im Netz viele Anleitungen zum Thema.
Code::Blocks ist tatsächlich schon relativ alt, allerdings habe ich nichts gefunden, was besagen würde dass codeblocks nicht mehr weiterentwickelt wird. ( ... http://code.google.com/p/codeblocks-mix/ ... ? )

Du solltest dir zunächst mal anschauen wie Make funktioniert und dir dann nochmal vor Augen führen, wie dein Projekt zusammengesetzt wird (compilieren, linken etc).

Das $(LIBSTM32_OBJS): stm32f10x_conf.h besagt, dass die LibSTM32 von einer Datei namens stm32f10x_conf.h abhängt. Sollte sich stm32f10x_conf.h seit dem letzten build verändert haben, muss die Library neu compiliert werden. So ist das gedacht. Daher ist es wichtig, dieses Statement nicht auszukommentieren. Natürlich ist stm32f10x_conf.h in allen Dateien der Lib verlinkt. Aber voneinander abhängen und verlinken ist nicht das gleiche.
Wie gesagt, schau dir einfach make mal genauer an.

~

So habe mal eben mein Projekt an die Makefile aus dem blinky-Beispiel aus dem Tutorial angepasst. Läuft schonmal ganz gut, allerdings gibt es noch zwei Probleme:

1.) Ich habe es noch nicht geschafft das Makefile so zu verändern, dass ich auf die *.c/*.h Dateien unter lib/src bzw. lib/inc zugreifen könnte. Daher habe ich diese Headerdateien erstmal alle direkt ins Projektverzeichnis kopiert.

und

2.) Beim Ausführen bekam ich folgende Fehlermeldung:
target CPU does not support ARM mode.

Daher habe jeweils ein -mthumb eingefügt. Jetzt habe ich aber noch eine letzte Warnung:
cannot find entry symbol _start; defaulting to 00100000

Diese scheint wichtig zu sein, denn das Board funktioniert mit der PCB-STM32.bin Datei nicht.
Laut google hat das irgend etwas mit CRT0.o zu tun. Eine Lösung habe ich aber noch nicht gefunden.

Hi,

na also ;)
Das Makefile sieht soweit i.O. aus, Wobei ich mich jetzt tiefer einlesen müsste...

zu 1... das sollte eigentlich kein Problem sein; einfach etwas mit den Pfaden spielen...

2. ist klar, der Cortex M3 kann nur (noch) den THUMB2-Befehlssatz, weshalb man - wie du schon richtig bemerkt hast - mit -mthumb in den CFLAGS compilieren muss.

Allerdings habe ich ein Problem mit deinem Linkerscript gefunden:

Code:

---

...
ENTRY(_start)

MEMORY {                                      /* memory map of AT91SAM7S64 */
    ROM (rx)  : ORIGIN = 0x00100000, LENGTH = 64k
    RAM (rwx) : ORIGIN = 0x00200000, LENGTH = 16k
}
...

---

Man achte besonders auf das /* memory map of AT91SAM7S64 */
Sprich, das Linkerscript passt nicht auf dein Device.

Dein Startup-code kommt mir auch irgendwie spanisch vor, mit diesen vielen Vektoren, aber das kann durchaus sein, dass das so sein muss; das weiß ich jetzt nicht.

Schau mal hier, vielleicht findest du was zu deinem Device: http://www.siwawi.arubi.uni-kl.de/av.../arm_projects/

(das generelle Problem ist, so wie sich das mir darstellt, dass der Linker nicht weiß, an welcher Adresse er mit dem code beginnen soll...).

Merke: Linker-Errors sind immer sch****.

Frage: Dieser Beispielcode von ST, hatte der ein Linkerscript?

so long.

Edit: http://www.siwawi.arubi.uni-kl.de/av...ml#stm32_blink ??
Wow, die Cortex M3 sind cooler als ich dachte!

Misst, ich hatte gefofft, ich kann das Linkerscript, nach anpassen der RAM Größe usw. trotzdem benutzen. Bei dem Beispiel war auch ein Linker Script dabei. Allerdings gehört dies zu einem anderen Beispiel und ist auch für eine uC-Version mit mehr Speicher. Und fraglich ist auch, ob dieses dann mit dem Makefile zusammenpasst.

Code:

---

/*
Default linker script for STM32F10x_512K_64K
Copyright RAISONANCE S.A.S. 2008
*/

/* include the common STM32F10x sub-script */

/* Common part of the linker scripts for STM32 devices*/


/* default stack sizes.

These are used by the startup in order to allocate stacks for the different modes.
*/

__Stack_Size = 1024 ;

PROVIDE ( _Stack_Size = __Stack_Size ) ;

__Stack_Init = _estack  - __Stack_Size ;

/*"PROVIDE" allows to easily override these values from an object file or the commmand line.*/
PROVIDE ( _Stack_Init = __Stack_Init ) ;

/*
There will be a link error if there is not this amount of RAM free at the end.
*/
_Minimum_Stack_Size = 0x100 ;


/* include the memory spaces definitions sub-script */
/*
Linker subscript for STM32F10x definitions with 512K Flash and 1024K RAM */

/* Memory Spaces Definitions */

MEMORY
{
  RAM (xrw) : ORIGIN = 0x68000000, LENGTH = 1024K
  FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 512K
  FLASHB1 (rx) : ORIGIN = 0x00000000, LENGTH = 0
  EXTMEMB0 (rx) : ORIGIN = 0x00000000, LENGTH = 0
  EXTMEMB1 (rx) : ORIGIN = 0x00000000, LENGTH = 0
  EXTMEMB2 (rx) : ORIGIN = 0x00000000, LENGTH = 0
  EXTMEMB3 (rx) : ORIGIN = 0x00000000, LENGTH = 0
}

/* higher address of the user mode stack */
_estack = 0x68100000;



/* include the sections management sub-script for FLASH mode */

/* Sections Definitions */

SECTIONS
{
    /* for Cortex devices, the beginning of the startup code is stored in the .isr_vector section, which goes to FLASH */
    .isr_vector :
    {
        . = ALIGN(4);
        KEEP(*(.isr_vector))            /* Startup code */
        . = ALIGN(4);
    } >FLASH
 
    /* for some STRx devices, the beginning of the startup code is stored in the .flashtext section, which goes to FLASH */
    .flashtext :
    {
        . = ALIGN(4);
        *(.flashtext)            /* Startup code */
        . = ALIGN(4);
    } >FLASH
 
   
    /* the program code is stored in the .text section, which goes to Flash */
    .text :
    {
            . = ALIGN(4);
           
        *(.text)                  /* remaining code */
        *(.text.*)                  /* remaining code */
        *(.rodata)                /* read-only data (constants) */
        *(.rodata*)
        *(.glue_7)
        *(.glue_7t)

            . = ALIGN(4);
            _etext = .;
            /* This is used by the startup in order to initialize the .data secion */
            _sidata = _etext;
    } >FLASH
   
 

    /* This is the initialized data section
    The program executes knowing that the data is in the RAM
    but the loader puts the initial values in the FLASH (inidata).
    It is one task of the startup to copy the initial values from FLASH to RAM. */
    .data  : AT ( _sidata )
    {
            . = ALIGN(4);
        /* This is used by the startup in order to initialize the .data secion */
        _sdata = . ;
       
        *(.data)
        *(.data.*)

            . = ALIGN(4);
            /* This is used by the startup in order to initialize the .data secion */
            _edata = . ;
    } >RAM
   
   

    /* This is the uninitialized data section */
    .bss :
    {
            . = ALIGN(4);
        /* This is used by the startup in order to initialize the .bss secion */
        _sbss = .;
       
        *(.bss)
        *(COMMON)
       
            . = ALIGN(4);
            /* This is used by the startup in order to initialize the .bss secion */
            _ebss = . ;
    } >RAM
   
    PROVIDE ( end = _ebss );
    PROVIDE ( _end = _ebss );
   
    /* This is the user stack section
    This is just to check that there is enough RAM left for the User mode stack
    It should generate an error if it's full.
    */
    ._usrstack :
    {
            . = ALIGN(4);
        _susrstack = . ;
       
        . = . + _Minimum_Stack_Size ;
       
            . = ALIGN(4);
        _eusrstack = . ;
    } >RAM
   

 
    /* this is the FLASH Bank1 */
    /* the C or assembly source must explicitly place the code or data there
    using the "section" attribute */
    .b1text :
    {
        *(.b1text)                  /* remaining code */
        *(.b1rodata)                /* read-only data (constants) */
        *(.b1rodata*)
    } >FLASHB1
   
    /* this is the EXTMEM */
    /* the C or assembly source must explicitly place the code or data there
    using the "section" attribute */
   
    /* EXTMEM Bank0 */
    .eb0text :
    {
        *(.eb0text)                  /* remaining code */
        *(.eb0rodata)                /* read-only data (constants) */
        *(.eb0rodata*)
    } >EXTMEMB0
   
    /* EXTMEM Bank1 */
    .eb1text :
    {
        *(.eb1text)                  /* remaining code */
        *(.eb1rodata)                /* read-only data (constants) */
        *(.eb1rodata*)
    } >EXTMEMB1
   
    /* EXTMEM Bank2 */
    .eb2text :
    {
        *(.eb2text)                  /* remaining code */
        *(.eb2rodata)                /* read-only data (constants) */
        *(.eb2rodata*)
    } >EXTMEMB2
   
    /* EXTMEM Bank0 */
    .eb3text :
    {
        *(.eb3text)                  /* remaining code */
        *(.eb3rodata)                /* read-only data (constants) */
        *(.eb3rodata*)
    } >EXTMEMB3
   
   
   
    /* after that it's only debugging information. */
   
    /* remove the debugging information from the standard libraries */
    DISCARD :
    {
    libc.a ( * )
    libm.a ( * )
    libgcc.a ( * )
    }

    /* Stabs debugging sections.  */
    .stab          0 : { *(.stab) }
    .stabstr      0 : { *(.stabstr) }
    .stab.excl    0 : { *(.stab.excl) }
    .stab.exclstr  0 : { *(.stab.exclstr) }
    .stab.index    0 : { *(.stab.index) }
    .stab.indexstr 0 : { *(.stab.indexstr) }
    .comment      0 : { *(.comment) }
    /* DWARF debug sections.
      Symbols in the DWARF debugging sections are relative to the beginning
      of the section so we begin them at 0.  */
    /* DWARF 1 */
    .debug          0 : { *(.debug) }
    .line          0 : { *(.line) }
    /* GNU DWARF 1 extensions */
    .debug_srcinfo  0 : { *(.debug_srcinfo) }
    .debug_sfnames  0 : { *(.debug_sfnames) }
    /* DWARF 1.1 and DWARF 2 */
    .debug_aranges  0 : { *(.debug_aranges) }
    .debug_pubnames 0 : { *(.debug_pubnames) }
    /* DWARF 2 */
    .debug_info    0 : { *(.debug_info .gnu.linkonce.wi.*) }
    .debug_abbrev  0 : { *(.debug_abbrev) }
    .debug_line    0 : { *(.debug_line) }
    .debug_frame    0 : { *(.debug_frame) }
    .debug_str      0 : { *(.debug_str) }
    .debug_loc      0 : { *(.debug_loc) }
    .debug_macinfo  0 : { *(.debug_macinfo) }
    /* SGI/MIPS DWARF 2 extensions */
    .debug_weaknames 0 : { *(.debug_weaknames) }
    .debug_funcnames 0 : { *(.debug_funcnames) }
    .debug_typenames 0 : { *(.debug_typenames) }
    .debug_varnames  0 : { *(.debug_varnames) }
}

---

Das siwawi blink Beispiel ist ja das Programm vom User Lachon von dem ich ausgegangen bin. Leider nutzt es noch die alte FWLib. Wenn ich mein Programm mit diesem Linkerscript erzeuge, hat die .bin-Datei eine größe von 384MB.

Den Makefile ist das Linkerscript egal, das Linkerscript muss mit dem (startup)code zusammenpassen...

So wie ich das sehe brauchts für den Cortex M3 garkeinen Startup-Code mehr (?) da die Interrupt-Vektoren direkt im VectorController abgelegt werden (??)
Frag mich dann aber nicht, wie die Variablen initialisiert werden...

Evtl. kannst du dieses Linkerscript anpassen...

Try and error.

Also den Startup-Code braucht man auf jeden Fall. Das Linker-Script, das ich nutze scheint auch richtig zu sein. Zumindest habe ich etliche andere Beispiele im Netz gefunden die das selbe Skript nutzen. Außerdem war es ja auch im FWLib mit dabei (nur mit noch anzupassender RAM-Größe). Wird also schon stimmen.
Dann wird der Fehler wohl im Makefile liegen. Was mir hier noch nicht ganz klar ist. Welche Dateien muss ich unter APP_DEP = ... eintragen? Alle Header-Dateien?
Und welche Dateien muss ich im folgenden Abschnitt eintragen? Scheinbar alle *.c und *.s Dateien.

Code:

---

$(BINDIR)/$(APP_NAME).elf : \
        ./ld/$(APP_NAME).ld \
        $(BINDIR)/startup_stm32f10x_md.o \
        $(BINDIR)/stm32f10x_exti.o \
        $(BINDIR)/stm32f10x_flash.o \
        $(BINDIR)/stm32f10x_gpio.o \
        $(BINDIR)/stm32f10x_rcc.o \
        $(BINDIR)/stm32f10x_usart.o \
        $(BINDIR)/misc.o \
        $(BINDIR)/core_cm3.o \
        $(BINDIR)/main.o \
        $(BINDIR)/stm32_eval.o \
        $(BINDIR)/stm32f10x_it.o \
        $(BINDIR)/system_stm32f10x.o
        $(LINK) \
        $(BINDIR)/startup_stm32f10x_md.o \
        $(BINDIR)/stm32f10x_exti.o \
        $(BINDIR)/stm32f10x_flash.o \
        $(BINDIR)/stm32f10x_gpio.o \
        $(BINDIR)/stm32f10x_rcc.o \
        $(BINDIR)/stm32f10x_usart.o \
        $(BINDIR)/misc.o \
        $(BINDIR)/core_cm3.o \
        $(BINDIR)/main.o \
        $(BINDIR)/stm32_eval.o \
        $(BINDIR)/stm32f10x_it.o \
        $(BINDIR)/system_stm32f10x.o \
        $(LINKFLAGS)

---

Aber was ist zum Beispiel mit der stm32f10x_conf.h Datei? Hierzu gibt es ja kein .c Gegenstück. Muss ich diese Datei auch noch irgendwie berücksichtigen?

Achso, mir ist auch gerade aufgefallen, dass ich den Startupcode aus dem ARM-Ordner genommen hatte. Ich denke die aus dem GCC-Ordner wird aber die richtige sein? Diese Korrektur hat aber auch keine Besserung gebracht. Die .bin Datei ist immer noch 384MB groß.

Hat hier eigentlich schonmal jemand ein Beispiel aus der FWLib 3.1.2 zum laufen bekommen. Dann bitte mal die Makefile und Linkerscript posten.

Theoretisch kann ein Startup-Code entfallen, da der M3 keine festen Interruptsprungadressen mehr hat, sondern direkt an die Adressen im Interruptcontroller springt. Den wiederum kann man in C konfigurieren und das ram und stack initialisieren kann man auch aus C raus machen, wenn man das mit entsprechendem __attribute an entsprechende Adressen linkt.
Daher wäre es generell denkbar, auf einen Startup-code zu verzichten, wobei ich es nicht gut finden würde.

Ich kanns nur nochmal sagen; Dein Problem liegt irgendwo beim Linkerscript (bzw.Startup-Code) begraben!
Das Makefile sorgt nur dafür dass alles entsprechend deinen Vorstellungen compiliert und gelinkt wird.
Ich habe das Gefühl du verstehst nicht, was diese einzelnen Dateien machen. Was das Makefile angeht, kannst du dir da Abhilfe schaffen, indem du dir einfach mal durchliest, was ein Makefile ist und wie es funktioniert (was ich jetzt schon x mal gesagt habe).
Was Linkerscripts und startups angeht möchte ich für einen groben Überblick auf das Tutorial weiter oben verweisen.

Wenn man mit ARMs rumexperimentiert ist leider nichtmehr alles so schön einfach mit einem Klick auf "Build project" erledigt. Bis mein erstes ARM-Projekt funktioniert hat, hats seine 3 Monate gebraucht...
Da muss man sich halt einarbeiten, ich sags echt ungern, aber vor ARM kommt leider RTFM...;)

Sicher kann man auch ohne Startupcode auskommen, aber das wäre dann nicht mehr im Sinne der neuen FWLib.

Interessanterweise hatte ich mit dem Linkerscript vom ATM9 eine Binärdatei bekommen deren Größe in Ordnung war. Ich habe dann gestern den ganzen Abend nach einer Lösung gegoogelt, und so wie es aussieht haben auch andere das gleiche Problem (z.B. im STM Forum), dass die Datei leer war bzw. dass diese viel zu groß ist. Das scheint wohl an der neuen Lib zu liegen, die wohl noch total verbuggt ist und die man daher noch gar nicht erfolgreich compilieren kann.

EDIT:
Mir ist zufällig aufgefallen, dass Eclipse in der core_cm3.h Datei eine ganze Reihe von Syntax-Fehlern anzeigt. Und zwar bei jeder Funktion der Form:

Code:

---

static __INLINE void NVIC_SystemReset(void)
{
...
}

---

Jedoch gibt Eclipse dann keine Fehler oder Warnungen nach dem Compilieren an. Kann ich diese Syntax-Fehler also ignorieren bzw. sind diese evtl. nur eine Macke von Eclipse?

So, nachdem ich heute gesehen habe, dass es eine neue IDE namens Coocox speziell für den ARM Cortex M3 gibt, habe ich diese sofort ausprobiert. Allerdings sieht man sofort, dass diese IDE nur auf Eclipse aufbaut. Das Erzeugen eines kompilierfähigen Projektes lässt sich hier alleine durch ein paar Mausklicks erledigen. Allerdings hat die so erzeugte .bin Datei auf meinem Board leider nicht funktioniert. Aber ich habe mir mal die build.xml genauer angeschaut und die Einstellungen für den Compiler und den Linker für mein Makefile übernommen. Jetzt klappt auch bei mir das Erzeugen der Binärdatei. Allerdings funktioniert auch diese nicht auf meinem Board. Warum kann ich nicht sagen, da ich keine Möglichkeit zum Debuggen habe. Oder kann man auch über den seriellen Anschluss debuggen?

Und wie kann man in Eclipse anstatt einer Makefile eine solche .xml Datei verwenden?

Falls sich jemand an der Fehlersuche beteiligen möchte. Der Code befindet sich im Anhang.