Hallo zusammen,
ich hoff auf eure Hilfe, ich versuche das Olimex Bord LPC2378-STK-A mit
Eclipse und GNUARM zum Laufen zubringen.
Das Standardbeispiel einer blinkenden LED hab ich hinbekommen. Nun
wollte ich die CAN-Schnittstelle testen aber sobald ich das Programm
erstellen will, macht mir der Linker Probleme:
arm-elf-ld: Warning: ./startup.o does not support interworking, whereas CAN_test.elf does
6
arm-elf-ld: failed to merge target specific data of file ./startup.o
7
./startup.o: In function `Undef_Addr':
8
(.text+0x24): undefined reference to `UNDEF_Routine'
9
./startup.o: In function `SWI_Addr':
10
(.text+0x28): undefined reference to `SWI_Routine'
11
./startup.o: In function `PAbt_Addr':
12
(.text+0x2c): undefined reference to `UNDEF_Routine'
13
./startup.o: In function `DAbt_Addr':
14
(.text+0x30): undefined reference to `UNDEF_Routine'
15
./startup.o: In function `IRQ_Addr':
16
(.text+0x34): undefined reference to `IRQ_Routine'
17
./startup.o: In function `FIQ_Addr':
18
(.text+0x38): undefined reference to `FIQ_Routine'
19
make: *** [CAN_test.elf] Error 1
So wie ich es verstehe, ist Startup mit hardware FP und der Rest mit
software FP übersetzt wurden, daher der ERROR.
Hab schon gegoogelt und wie vorgeschlagen versucht die entsprechende
Bibliothek libgcc.a zu ersetzen und Flags mit anzugeben. Hat aber alles
nicht geholfen (ggf. Hab ich auch die falsche erwischt)
Ich habe mal das komplette Build-Listing als .txt angehangen. Hab mir
das jetzt auch noch mal genauer angeschaut, denke der Assembler
übersetzt die Startup.s und verursacht so denn Fehler aber ehrlich
gesagt weis nicht mehr weiter und hoffe nun auf euch.
LG Steffen
1. -msoft-float Option sollte man erstmal weglassen, wenn es eine nicht
gar zu ungewöhnlich konfigurierte toolchain ist.
2. Assemblieren einer Assembler-Datei ebenfalls über Frontend arm-*-gcc
durchführen, nicht direkt per Aufruf von arm-*-as. Dabei dann zumindest
-mcpu-Parameter mitgeben.
3. Linken ebenfalls über arm-*-gcc, den Linker (arm-*-ld) nicht direkt
aufrufen - das bring nur Frust. Beim Linken auch einfach die CFLAGS
mitgeben (zumindest aber die -mcpu option). Dann ruft das Frontend(gcc)
den Linker(ld) intern automatisch mit den richtigen Optionen.
mglw. hilfreich:
1
-------- begin (mode: ROM_RUN) --------
2
arm-eabi-gcc (devkitARM release 23b) 4.3.0
3
Copyright (C) 2008 Free Software Foundation, Inc.
4
This is free software; see the source for copying conditions. There is NO
5
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Hallo,
ich muss zugeben, ich seh da nicht so richtig durch. Als Toolchain hab
ich einfach das GNUARM von
http://www.gnuarm.com/
runtergeladen, installiert und Eclipse Plugin eingefügt.
Hab aber grad festgestellt das ich meine Version nicht mehr auf
gnuarm.com zu finden ist. Lade jetzt erstmal noch mal eine andere
Version (binutils-2.16.1, gcc-4.1.0...) runter und teste obs besser
geht.
Die Gänderungen hab ich gemacht, mun bekomm ich aber den Fehler:
Steffen H. schrieb:
> OK mit der neuen Version gibt es andere Fehler, laufen tut aber gar> nichts mehr:> bei mein Programm zum LEB-blinken bekomme ich den Error:> [code]Building target: BLINK.elf> Invoking: ARM Windows GCC C Linker> arm-elf-ld -T"D:\work\workspace\BLINK\demo2378_blink_flash.cmd"> [code]
Linker wird immer noch direkt aufgerufen, versteht aber die für das
Frontende bestimmte Option nicht. Punkt 3 in meinem Getippse 08.12.2009
17:45 erfolgreich überlesen.
> bei meinem CAN-Testprogramm siehts so aus:> [code]Building target: CAN_test.elf> Invoking: ARM Windows GCC C Linker> arm-elf-gcc -T"D:\work\workspace\CAN_test\demo2378.cmd" -nodefaultlibs> -Wl,-Map,CAN_test.map -v -mcpu -mapcs -mcpu=arm7tdmi-s -g3 -ggdb> -o"CAN_test.elf" ./can.o ./fio.o ./irq.o ./main.o ./startup.o> ./target.o> [...]
Siehe Optionen zum Linken in der Beispielausgabe im o.g. Beitrag.
Zaunpfahl: -nostartfiles
Dokumentation von gcc und binutils/ld lesen ist zwar teilweise etwas
mühsam aber ganz bestimmt erhellender als ein etwas zielloses Gestocher
in den Optionen.
Also nochmal mit genannten Modifikationen ausprobieren und mglw.
verbleibende Fehler zeigen. Viel besser wäre allerdings, ein minimales
Beispiel mit allen erforderlichen Datein, bei dem man mit einem "make
all" die Fehler nachvollziehen kann (Makefile sollte also dabei sein,
sonst kann zumindest ich nicht helfen). Spart dann wahrscheinlich ein
paar Iterationen in diesem Thread.
Nicht dass man unbedingt mit dem neusten Werkzeug arbeiten muss aber gcc
4.1.0 ist schon eine Weile auf dem Altenteil. Man google nach Yagarto,
Codesourcery lite for arm und DevKitARM, dort findet sich Aktuelleres
fertig compiliert.
HAllo,
danke noch mal, das mit dem Linker habe ich gestern kurz vor
Arbeitsschluss auch noch gemerkt und nach etwas frimeln funktioniert nun
der Aufruf über den GCC.
Sollten doch noch Probleme auftreten, werd ich wie du sagst mal das
BLINK-Projekt anhängen. Ansonsten werd ich auch deinem Vorschlag zu
aktuelleren Versionen folgen und noch mal nachschau.
Großen Danke für die Hilfe!!!
LG Steffen