Hier komme ich im Moment einfach nicht weiter, ich hoffe einer von euch
kann mir weiter helfen.
Im Anhang findet ihr das Eclipse-Projekt, Makefile und die komplette
Fehlerausgabe.
Gruß
Marco
PS.: Mir ist klar dass das erzeugt Kompilat nicht unbedingt für das
STM32F4-Descovery geeignet ist.
Hm. Ich verwende IAR Workbench und kann Dir also bei den Link-Files und
Project-Files nicht im Detail weiterhelfen.
Ich weiss nicht ob ich Dich da richtig verstehe. Aber wenn ich das hier:
>mit dem Unterschied das sich die Verzeichnisse für die StdPeriph der >STM32F4-Reihe geändert haben.
wortwörtlich nehme, sich Deine Anpassungen ggü. der Beschreibung in dem
Link auf eben den neuen Pfad beschränken, dann hast Du ein Template
Projekt für das Discovery kopiert und angepasst.
Falls das so ist würde ich Dir empfehlen, den selben Ablauf aber eben
mit einem Template-Projekt für den STM32F4, den das Discovery hat den
STM32F1 drauf. Das würde zumindest ansatzweise die fehlenden Funktionen
erklären.
Die undefined references deuten letztlich darauf hin, dass Du in Deinem
Project irgendwo noch diese Funktionen aufrufst, wobei sie nicht
definiert sind.
Alternativ wäre der erste Schritt also, diese Namen in Deinem Project zu
suchen und entweder den Aufruf oder sogar die gesamte Datei aus dem
Projekt zu entfernen.
Dem Namen nach wirst Du zumindest _init noch brauchen. Aber das sehen
wir dann, würde ich vorschlagen.
>denn das Discovery hat den STM32F1 drauf
Hm. Da hab ich mich falsch ausgedrückt. Es gibt natürlich auch ein F4
Discovery. Aber in der von Dir verlinkten Anleitung wird das F1
Discovery bzw. desssen Template Projekt verwiesen. Vermutlich hast Du
das dann eben schon mit dem F4 Template Projekt gemacht.
Aber das kann ich ja nicht wirklich wissen, wenn Du es nicht
ausdrücklich sagst. Und ich weiss auch nicht wieviel Erfahrung Du hast,
ob sie insbesondere ausreicht zumindest auf den Gedanken zu kommen.
Also, nichts für ungut, falls ich da offene Türen eingerannt habe.
:-)
Noname schrieb:> Ich verwende IAR Workbench...
Schöne heile Windows-Welt :P
Noname schrieb:> Hm. Da hab ich mich falsch ausgedrückt. Es gibt natürlich auch ein F4> Discovery. Aber in der von Dir verlinkten Anleitung wird das F1> Discovery bzw. desssen Template Projekt verwiesen. Vermutlich hast Du> das dann eben schon mit dem F4 Template Projekt gemacht.
Das meinte ich mit anpassen der Verzeichnisse fürs STM32F4, weil die
verlinkte Seite halt ein STM32F1 verwendet. Hätte ich deutlicher
schreiben sollen.
>Schöne heile Windows-Welt :P
Naja. Was tut man nicht alles fürs tägliche Brot. :-) Wenn es denn die
AG so haben wollen. Hab mich so ans Essen gewöhnt... ;-)
Bin auch eher ein Linux Fan. Aber das nur nebenbei.
Also Du hast schon das STM32F4 Template benutzt.
Dann musst Du halt doch mal schauen wo genau und in welchem Kontext die
fehlenden Funktionen aufgerufen werden.
Benutzt Du eigentlich ein eigenes Board oder das STM32F4 Discovery?
Es wird vermutlich auf irgendwelche fehlenden oder falschen Defines in
den Template-Dateien hinauslaufen. Ich würde erstmal darauf schauen, von
welchen defines der Aufruf der Funktionen abhängig ist.
Die Periphery Library und die Templates sind voll von defines die
eigentlich spezifisch für das Evaluation Board sind und nicht
verallgemeinerbar.
Noname schrieb:> Benutzt Du eigentlich ein eigenes Board oder das STM32F4 Discovery?
Ja ich habe hier ein STM32F4-Discovery hier.
Noname schrieb:> Die Periphery Library und die Templates sind voll von defines die> eigentlich spezifisch für das Evaluation Board sind und nicht> verallgemeinerbar.
Ziemlich ungeschickt für eine allgemeine Bibliothek. :/
Noname schrieb:> Es wird vermutlich auf irgendwelche fehlenden oder falschen Defines in> den Template-Dateien hinauslaufen. Ich würde erstmal darauf schauen, von> welchen defines der Aufruf der Funktionen abhängig ist.
Die Fehler sind alle in den Quelltext-Dateien aus dem Ordner _STM32F4xx
StdPeriphLib V1.0.0/Utilities/STM32_EVAL/STM3240_41_G_EVAL_.
Die c-Dateien habe ich mal rausgeschmissen, die Header-Datein aber
drinnen gelassen. Denn in der main.c von IO_Toggle wird die Datei
stm324xg_eval.h eingebunden die in diesem Ordner drinnen ist.
Jetzt habe ich nur noch einen Fehler:
undefined reference to `_init' IO_Toggle
Schaut man sich die Ausgabe des Compilers an stolpert man über fplgende
Aufruf:
/opt/CodeSourcery/arm-2011.09/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib/thumb2/libc.a(lib_a-init.o): In function `__libc_init_array':
>Verstehe ich das richtig das der Fehler hier in der Bibliothek libc ist?
Hm. Aber das taucht noch nach dem ende des linkens auf. Nach der Nennung
von stm32f4xx_cryp_tdes.c
Warum wird da eigentlich mit stm32f4xx_cryp_tdes.c gelinkt?
Du willst doch nur nen Pin toggeln?
Evtl. erledigt sich das, wenn Du das cryp_tdes modul aus dem Projekt
nimmst.
Ich habe mal in der Library und in den Codebeispielen gesucht.
Dort wird das _init weder referenziert noch definiert.
Kommt also vermutlich wirklich aus der libc.
Könnte sein, das Du den startup code noch um den für die libc
notwendigen ergänzen musst.
Hast Du das Problem mit der Dateiendung von Assemblerdateien
berücksichtigt und kontrolliert?
Ich sehe auch nicht das in der Anleitung ausdrücklich auf die libc
eingegangen wird. Möglicherweise gibts da noch flaws/issues.
Eine andere Sache die mir noch einfällt, ist, das es da evtl. CMSIS
Probleme geben könnte. Ich hatte mal das umgekehrte Problem, das IAR
nicht mehr mit den in der in den STM Libs bereitgestellten CMSIS files
klarkam. Das war im Oktober/November. Falls sich die Anleitungen und die
Libs zeitlich stark unterscheiden könnte da was im argen liegen.
Noname schrieb:> Warum wird da eigentlich mit stm32f4xx_cryp_tdes.c gelinkt?> Du willst doch nur nen Pin toggeln?
Ich habe die komplette Bibliothek mit in das Projekt geladen. Welche
Teile der Bibliothek verwendet werden sollen wird ja in der
stm32f4xx_conf.h festgelegt. Was aber anscheinend nicht so funktioniert,
selbst wenn ich nur stm32f4xx_gpio.h aktiviere, nimmt er alles andere
mit. Was irgendwo auch klar ist, da er ja versucht alle c-Dateien zu
kompilieren.
Ich habe jetzt mal alles rausgeschmissen bis auf das GPIO-Modul und das
RCC-Modul welches für IO_Toggle benötigt wird. Problem bleibt bestehen.
Der Fehlertext oben ist glaube ich irreführend, den habe ich aus Eclipse
kopiert, Eclipse würfelt die Ausgaben aber anscheinend durcheinander.
Hier mal der Fehlertext wie er jetzt ist nur mit make direkt auf der
Konsole ausgeführt.
/opt/CodeSourcery/arm-2011.09/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib/thumb2/libc.a(lib_a-init.o): In function `__libc_init_array':
3
init.c:(.text+0x38): undefined reference to `_init'
An sich sollte das mit dem ..._conf nicht schaden, da der Linker nicht
versuchen sollte was zu linken, was nicht aufgerufen wird, denke ich.
Ich selbst verwende allerdings das ..._conf nicht.
hp-freund schrieb:> https://github.com/texane/stlink/tree/081eae3087ac...>> von:>> https://github.com/texane/stlink>> ist ein schöner leichter Startpunkt fur das Board.
Danke habe gerade mal kurz reingeschaut, auf dem ersten Blick schaut es
genauso aus wie bei mir jetzt auch. Wird also wahrscheinlich auf den
selben Fehler hinauslaufen.
Noname schrieb:> Hast Du das Problem mit der Dateiendung von Assemblerdateien> berücksichtigt und kontrolliert?
Ja habe ich berücksichtigt, wird auch kompiliert die Datei.
*OH MEIN GOTT. Noname du bist der Held des Tages!* vorerst ;-)
Nur um mal den Bug mit der Dateiendung zu verifizieren, habe ich aus dem
grossen S ein kleines s gemacht. Plötzlich und unerwartet kompiliert der
durch. Die Assembler-Datei mal gelöscht, kompiliert/linkt immer noch.
Allerdings ohne startup-code -> Bug existiert also noch.
Nun weiß ich das der Fehler in der Assembler-Datei liegt, das Projekt
welches hp-freund verlinkt hat, verwendet dieselbe Datei (mit
.s-endung).
Nun also weiter. Den Startup-Code kann ich sicherlich nicht weglassen,
zumal ich auch eine Warnung erhalte.
1
warning: cannot find entry symbol Reset_Handler; defaulting to 08000000
>Nur um mal den Bug mit der Dateiendung zu verifizieren, habe ich aus dem
grossen S ein kleines s gemacht. Plötzlich und unerwartet kompiliert der
durch.
Hm. Bin nicht sicher ob ich Dich recht verstehe. Wenn es so geht, warum
löschst Du dann die Assembler-Datei nur um dann bei
>Die Assembler-Datei mal gelöscht, kompiliert/linkt immer noch.>Allerdings ohne startup-code -> Bug existiert also noch.
zu landen?
Ich habe die Datei nur gelöscht um sehen ob das Ergebnis dasselbe ist
als wenn ich die Endung mit kleinem s habe. Nicht das er die Datei doch
nimmt.
Dank des Hinweise im Beitrag
http://www.mikrocontroller.net/topic/goto_post/715100 konnte ich nun das
Beispiel mit startupcode kompileren, in der Datei gibt es eine Zeile
1
bl __libc_init_array
die ich jetzt einfach mal auskommentiert habe.
Werde das ganze gleich in den Prozessor flashen um zu sehen ob alles
klappt.
>Ich habe die Datei nur gelöscht um sehen ob das Ergebnis dasselbe ist>als wenn ich die Endung mit kleinem s habe. Nicht das er die Datei doch>nimmt.
Hmm. Vielleicht kommen wir ja klar ohne das zu klären.
Aber wenn es nicht funktioniert weil sie ein grosses S hat, dann
funktioniert es, nach meinem Verständnis, auch nicht, wenn die Datei
nicht existiert.
Daumen drück.
Na endlich, es geht .. korrigiere es leuchtet :P
Kurz zur Aufklärung der Geschichte mit der Endung für Assembler-Dateien.
Assembler-Dateien für Eclipse müssen_ mit einem _grossemS enden,
sonst wird die Datei einfach ignoriert. Also auch nicht dem Compiler
übergeben.
Wenn die Datei also mit kleinem s endet hat dies denselben Effekt als
währe sie überhaupt nicht da.
Der Linker-Fehler lag also in der Assembler-Datei mit dem StartUp-Code.
Danke für deine Hilfe Noname, jetzt kann ich in die nächsten Tage den
Artikel weiter führen und die gewonnen Erkenntnisse endlich mal
dokumentieren ;)
Thread beobachten
Seitenaufteilung abschalten