Forum: Mikrocontroller und Digitale Elektronik DAVE3/Eclipse compile error, das muss doch gehen!


von Stefan N. (suckiden)


Lesenswert?

Hallo Leute,

ich spiele mich gerade mit der IDE DAVE3 von Infineon. Ich versuche 
verzweifelt uCOSIII auf meinem XMC4500 Relax Kit zum laufen zu bringen. 
Micrium bietet das RTOS leider nur für Keil, IAR und TrueSTUDIO als 
Vorlage Projekt an. Also für alle die über DAVE3 nichts wissen es ist 
Eclipse basierten womit mir hoffentlich jemand helfen kann der Erfahrung 
mit Eclipse hat. Wenn ich mein Projekt builde bekomme ich folgenden 
Output:
1
**** Build of configuration Debug for project XMC4500_uCOSIII ****
2
3
"C:\DAVE-3.1.10\ARM-GCC\bin\make" all 
4
'Building target: XMC4500_uCOSIII.elf'
5
'Invoking: ARM-GCC C Linker'
6
"C:\DAVE-3.1.10\ARM-GCC/bin/arm-none-eabi-gcc" -T"D:\Dokumente\Dropbox\FH\4Semester\BAK_Arbeit\workspace\XMC4500_uCOSIII\XMC4500_uCOSIII.ld" -nostartfiles -L"C:\DAVE-3.1.10\eclipse\/../CMSIS/Infineon/Lib" -L"D:\Dokumente\Dropbox\FH\4Semester\BAK_Arbeit\workspace\XMC4500_uCOSIII\Libraries\uC-CPU" -L"C:\DAVE-3.1.10\eclipse\/../Examples/Lib" -L"C:\DAVE-3.1.10\eclipse\/../emWin/Start/GUI" -Wl,-Map,"XMC4500_uCOSIII.map" -mcpu=cortex-m4 -mthumb -g3 -gdwarf-2 -o "XMC4500_uCOSIII.elf" "@makefile.rsp"  
7
Libraries/uCOS-III/Source/os_core.o: In function `OSIntExit':
8
D:\Dokumente\Dropbox\FH\4Semester\BAK_Arbeit\workspace\XMC4500_uCOSIII\Debug/../Libraries/uCOS-III/Source/os_core.c:344: undefined reference to `OSIntCtxSw'
9
Libraries/uCOS-III/Source/os_core.o: In function `OSSched':
10
D:\Dokumente\Dropbox\FH\4Semester\BAK_Arbeit\workspace\XMC4500_uCOSIII\Debug/../Libraries/uCOS-III/Source/os_core.c:421: undefined reference to `OSCtxSw'
11
Libraries/uCOS-III/Source/os_core.o: In function `OSStart':
12
D:\Dokumente\Dropbox\FH\4Semester\BAK_Arbeit\workspace\XMC4500_uCOSIII\Debug/../Libraries/uCOS-III/Source/os_core.c:728: undefined reference to `OSStartHighRdy'
13
Libraries/uCOS-III/Ports/ARM-Cortex-M4/Generic/GNU/os_cpu_c.o: In function `OSTaskSwHook':
14
D:\Dokumente\Dropbox\FH\4Semester\BAK_Arbeit\workspace\XMC4500_uCOSIII\Debug/../Libraries/uCOS-III/Ports/ARM-Cortex-M4/Generic/GNU/os_cpu_c.c:336: undefined reference to `OS_CPU_FP_Reg_Push'
15
D:\Dokumente\Dropbox\FH\4Semester\BAK_Arbeit\workspace\XMC4500_uCOSIII\Debug/../Libraries/uCOS-III/Ports/ARM-Cortex-M4/Generic/GNU/os_cpu_c.c:340: undefined reference to `OS_CPU_FP_Reg_Pop'
16
collect2.exe: error: ld returned 1 exit status
17
make: *** [XMC4500_uCOSIII.elf] Error 1
18
19
**** Build Finished ****

fällt jemanden auf die schnell auf was ich falsch machen könnte?
Ich kann auch gerne mal das Project file online stellen falls das eine 
Hilfe ist.


lg

von K. H. (hegy)


Lesenswert?

Stefan N. schrieb:
> os_cpu_c.c:336:
> undefined reference to `OS_CPU_FP_Reg_Push'
> os_cpu_c.c:340:
> undefined reference to `OS_CPU_FP_Reg_Pop'

Den Fehlermeldungen und meiner Eclipse-Erfahrung nach, findet der 
Compiler die Headerdateien nicht weil in der Eclipse-Umgebung bzw. im 
Eclipse-Projekt die nicht mit eingebunden werden. Ich hatte so einen 
Fehler auch mal, allerdings mit C++ unter Ubuntu. Es lag, wenn ich es 
richtig im Kopp habe, an den Suchpfaden des Compilers. Die habe ich dann 
als Parameter im Eclipse-Projekt ergänzt. Der Aufruf war danach dann 
sowas:
1
g++ -I../subdir/include ....

Mit dem Problem ging es dann weiter beim Linken.

Aus der gcc man-page:
1
-Idir Add the directory dir to the head of the list of directories
2
      to be searched for header files. This can be used to override a system
3
      header file, substituting your own version, since these directories are
4
      searched before the system header file directories.  However, you should
5
      not use this option to add directories that contain vendor-supplied system
6
      header files (use -isystem for that).  If you use more than one -I option,
7
      the directories are scanned in left-to-right order; the standard system
8
      directories come after.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Nein, das sind /Linker/-Fehlermeldungen.

Der Compiler selbst ist glücklich, an den Include-Anweisungen muss nicht 
herumgebastelt werden.

Was fehlt, ist die Library (irgendwas.a) oder die Objektdatei(en) 
(sonstwas.o), in der die angekreideten Funktionen bzw. Variablen 
definiert sind.

In ersterem Fall muss dem Linkeraufruf per Kommandozeilenparameter -l 
die gewünschte Library beigefügt werden, in letzterem Falle werden 
vermutlich die Sourcefiles, die die Funktionen/Variablen enthalten, im 
Makefile nicht aufgeführt und deswegen nicht übersetzt, und obendrein 
dem Linker nicht zum Fraß vorgeworfen.

von Stefan N. (suckiden)


Angehängte Dateien:

Lesenswert?

Also die include Pfade müssten eigentlich alle richtig eingestellt sein, 
ich glaube auch dass hier der Linker meckert. Ich habe jetzt alle files 
meines projekt nach `OSIntExit' durchsucht und in dem file os_cpu_a.S 
(siehe Anhang) folgendes in Zeile 33 gefunden: .extern  OSIntExit.

Soweit ich das verstanden habe, wird aus einer .asm oder .S datei eine 
.o datei gemacht, die dann der Linker mit den restlichen files zu einem 
executable file zusammenfügt? Muss ich jetzt jedoch die .S file in einer 
der Einstellungen hinzufügen oder muss ich mir das daraus generierte .o 
File suchen?

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Stefan N. schrieb:
> ich glaube auch dass hier der Linker meckert

Das ist bei einer Ausgabe, die so anfängt:
1
"C:\DAVE-3.1.10\ARM-GCC\bin\make" all 
2
'Building target: XMC4500_uCOSIII.elf'
3
'Invoking: ARM-GCC C Linker'

ja auch nicht wirklich unwahrscheinlich ...

von Pit S. (pitschu)


Lesenswert?

Offensichtlich wird os_cpu_a.S gar nicht gelinked. Benenne die mal um in 
os_cpu_a.s (mit kleinem s am Ende). Eclipse hat ein Mapping, welche 
Endung mit welchem Tool kompiliert wird. Schau mal unter Window > Unter 
Preferences > General > Content types im Eintrag Assembly source file. 
Bei mir steht da *.asm und *.S. Bei Dir evtl. nur *.s

PS

von Stefan N. (suckiden)


Lesenswert?

nicht schlecht der Specht!

Problem gelöst, danke sehr! habe das File einfach statt .S am Dateiende 
mit .s umbenannt und jetzt kompiliert er wie er soll. Leider kann ich 
*.S nicht hinzufügen denke er meint das ist das gleiche wie *.s aber so 
lange es funktioniert soll mir das egal sein :)

Danke auf jeden Fall nochmal, das hätte ich vermutlich nie gefunden

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Peter Schulten schrieb:
> Offensichtlich wird os_cpu_a.S gar nicht gelinked. Benenne die mal um in
> os_cpu_a.s (mit kleinem s am Ende).

Wenn das unter Windows nötig ist, ist das ein Fehler in der 
Eclipse-Portierung.

von Pit S. (pitschu)


Lesenswert?

Der Fehler ist wohl eher der, dass man nicht beide Endungen *.S und *.s 
eintragen kann. Die Unterscheidung der beiden in Eclipse ist m.E. OK

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Peter Schulten schrieb:
> Die Unterscheidung der beiden in Eclipse ist m.E. OK

Nein, auf einem Betriebssystem, dessen Dateisystem nicht zwischen Groß- 
und Kleinschreibung unterscheidet, ist das ein Fehler.

von Pit S. (pitschu)


Lesenswert?

na wenn NTFS nicht unterscheiden würde, hätte der Stefan ja gar kein 
Problem gahabt.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Die Anzeige von Dateinamen ist was anderes als das Interpretieren. 
Zwar wird die Schreibweise von Dateinamen beibehalten (also nicht alles 
in Groß- oder Kleinbuchstaben umgewandelt), aber es wird ein und die 
gleiche Datei angesprochen, egal, wie ihr Name geschrieben wird.

Und damit ist es ein Fehler, beim Öffnen einer Datei auf der 
"korrekten" Groß- oder Kleinschreibung zu beharren; die unterliegenden 
Dateisystemmechanismen nämlich tuns nicht.

Wer das nicht versteht, sollte vielleicht besser keine Software von 
einem auf ein anderes Betriebssystem portieren.

von Pit S. (pitschu)


Lesenswert?

Das ist von den Leuten, die Eclipse und andere Linux basierende tools 
portiert haben (z.B. GNUARM, cygwin etc.) bewusst so gemacht worden, um 
maximale Kompatibilität zu erhalten. Aus der MS-Knowledge base:

NTFS supports two slightly different modes of operation that can be 
selected by the subsystem of the application interacting with NTFS. The 
first is fully case sensitive and demands that file names supplied by 
the application match the names stored on disk including case if the 
file on disk is to be selected. The second mode of operation is case 
preserving but not case sensitive. This means that applications can 
select files on the disk even if the supplied name differs in case from 
the name stored on the disk. Note that both modes preserve the case used 
to create the files. The difference in behavior noted here applies only 
when an application needs to locate an existing file. POSIX takes 
advantage of the full case sensitive mode, while MS-DOS, WOW, and Win32 
subsystems use the case insensitive mode.

Eclipse nutzt offenbar den POSIX mode.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.