STM32-Toolchain mit Eclipse CDT 4.3, GnuArmEclipse, OpenOCD 0.8.0, Gnu Arm GCC 4.8, STM32CubeMX

Hallo STMUser,

generell kannst Du derartige Einstellungen in <Kontextmenü des 
Projektes> -->Properties -->C/C++ Build --> Settings -->Tool Settings 
-->Target Processor ändern. Ich bin allerdings einerseits überfragt, 
welche Bedeutung die Optionen haben und andererseits sind IMHO derartige 
Überlegungen für die Zielgruppe meines Tutorials noch (!) nicht 
sonderlich relevant ;-)

Grüße
Klaus

Hallo STMUser,

ich habe mich nun doch ein wenig mit der Materie beschäftigt und eine 
kleinen Test für die FPU programmiert. Mit den von mir im Tutorial 
angegebene Compileroptionen (<Kontextmenü des Projektes> -->Properties 
-->C/C++ Build --> Settings -->Tool Settings -->Target Processor; dort 
"Float ABI" und "FBU Type") erzeugt die Toolchain einerseits 
Initialisierungscode für die FPU und nutzt diese dann auch. Letzteres 
erkennt man im Disassembly (siehe Screenshot, der vmul-Befehl).

Grüße
Klaus

Hallo zusammen,

heute habe ich RTOS 8.0.1 in meine Umgebung integriert und eine 
Schritt-für-Schritt-Anleitung parallel mitgeschrieben. Das Ergebnis 
findet ihr hier: 
http://klaus4.blogspot.com/2014/05/rtos-801-auf-dem-stm32f4-discovery.html

Grüße
Klaus

Hi,

ich habe mal versucht nach deiner Anleitung vorzugehen. Danke dafür.

Hier hänge ich fest:
>>> In der STM32CubeMX-Oberfläche: -->Help -->Updater Settings -->
>>> Verzeichnis auf c:\stm32ws\CubeRepo (“Cube Repository”) einstellen -->ok

dort gibt es kein "Updater Settings" es gibt nur "About" und "Help F1"

Hast Du einen Tipp ?

Gruß T.

Hallo Thilo,

ich habe die Menüpunkte im "Help"-Menü nochmals geprüft. Sowohl bei 
einem geöffneten als auch bei geschlossenem CubeMX-Projekt waren bei mir 
neben "Help" und "About" noch drei weitere Menüpunkte sichtbar. Weshalb 
die bei Dir nicht sichtbar sind, kann ich leider nicht beantworten.

Möglicherweise hakt es bei der Integration der CubeMX-Oberfläche in 
Eclipse. Versuche es mal mir der Standalone-Version von CubeMX: 
http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1533/PF259242#

Viele Grüße
Klaus

Hallo Klaus,

danke für deinen Post.
Das sieht nach einem Java - Problem oder einm Problem der Rechte für 
java - Paket aus. Welche Java - Version verwendest Du ?

Gruß T.

Hallo Thilo,

ja, das könnte sein! Ich habe im STM-Forum einige Posts gelesen, in 
denen von Problemen mit Java 1.8 berichtet wurde. Ich verwende bei mir 
noch die Version 1.7.0_45-b18.

vg Klaus

Hallo,

nachdem ich die JRE 8 Update 5 deinstalliert habe und die ältere Version 
JRE 7 Update 55 installiert habe klappt alles.

Zunächst habe ich versucht beide Versionen zu installieren und über die 
Java - Konsole nur die Version 7 zu aktivieren. Das funktioniert leider 
auch nicht.

Danke und Gruß
T.

Guten Tag,

ich suche auch gerade eine IDE. Ist Eclipse CDT besser als z.B. CooCox 
CoIDE? Sind die Libraries gleich? Ändern sich die befehle um z.B. einen 
Pin zu toggeln?

Hallo Martin,

auch die CoIDE nutzt Eclipse als Basis, allerdings wurde hier ein 
starkes "Customizing" betrieben. Dies vereinfacht so manches, aber setzt 
auch in bestimmten Bereichen engere Grenzen. Ich persönlich schätze es 
sehr, eine Toolchain ohne diese Grenzen aufgebaut zu haben, die dennoch 
nicht unkomfortabel ist. Für mich war die Integration von CubeMX eine 
wichtige Anforderung. Ob das mit der CoIDE problemlos möglich ist, wage 
ich zu bezweifeln.

Welche IDE nun "besser" ist, hängt von Deinen Vorlieben ab. Ich könnte 
mir aber vorstellen, dass Du mit der CoIDE für den Einstieg besser 
bedient bist.

Nein, die Libraries sind meines Wissens nicht gleich. Die CoIDE basiert 
noch auf der "alten" Firmware-Struktur von STM und setzt dort noch einen 
eigenen Überbau "CoX" drauf. Meine Toolchain nutzt die "neue" 
Firmware-Struktur ohne weiteren Überbau. Insofern sind dann auch die 
Befehle zum Toggeln eines Pins verschieden.

vg Klaus

Hallo nhd,
diesen Fehler hatte ich immer dann, wenn ich die Symboldefinition 
(USE_HAL_DRIVER & STM32F407XX) oder die Angabe des Linkerscriptes 
vergessen habe. Prüfe das mal bitte.

Viele Grüße aus dem ICE

Klaus

Hallo nhd,

tja, bei der Vielzahl der Schritte passieren einfach Fehler. Das ist 
menschlisch und hat sicher nichts mit "dumm" zu tun. Im Gegenteil: Das 
Du den Fehler selbst gefunden hast, zeigt doch, dass Du mit Sachverstand 
bei der Sache bist!

Happy coding
Klaus

Hallo Klaus,

erst einmal vielen Dank für die wirklich sehr gute Anleitung!
Hat alles gut (glaube ich) funktioniert bis zum Klick auf den Hammer 
(Build Debug Projekt). Es kommt fogende Fehlermeldung:

08:41:19 **** Incremental Build of configuration Debug for project 
kl_tut_01 ****
make all
MAKE Version 5.2  Copyright (c) 1987, 1998 Inprise Corp.
Error makefile 6: Command syntax error
.
.

Offensichtlich hat Eclipse ein falsches make.exe gestartet. Ich habe 
auch auf dem Computer diverse Compiler von Borland (=Inprise..) 
installiert.
Ich habe daraufhin in "Properties for kl_tut_01" gesucht und in 
C/C++Build->Environment variable PATH gefunden, in der auch die ganzen 
Borland, Codegear Pfade definiert waren. Daraufhin habe ich alle gelösch 
und es ist nur mehr C:\stm32tc\gcc48\bin gesetzt. Leider hat das nicht 
gebracht, er verwendet weiter das falsche make.

Irgendewelche Ideen dazu?

Danke im Voraus

Guten Morgen Friedrich,

neben den Pfaden in Eclipse selbst kann man natürlich auch im 
Betriebssystem noch Pfade definieren. Ich unterstelle mal Windows 7. 
Dann findest Du die Pfade unter Systemsteuerung -> System und Sicherheit 
-> System -> Erweiterte Systemeinstellungen -> Erweitert -> 
Umgebungsvariablen. Prüfe dort mal, was alles in "PATH" steht.

vg Klaus

Hallo Klaus,

danke für die Antwort, habe in Windows die Path Systemvariable mit 
C:\stm32tc\GnuWin32\bin; erweitert (ganz am Anfang gestellt). Danach 
compilierte der "Hammer" ohne Fehler.
Das nächste Problem das ich jetzt habe ist der Debugger.
Wenn ich wie beschrieben den Debugger über run-> debug configuration 
starte kommt die Fehlermeldung:

Error while launching command: arm-none-eabi-gdb --version
CreateProcess error=2, Das System kann die angegebene Datei nicht finden

Findet elclipse den gdb nicht?

Die datei arm-none-eabi-gdb.exe ist aber in stm32tc\gcc48\bin\ 
vorhanden.

???

Hallo Friedrich,

beim Anlegen eines neuen Projektes wirst Du im letzten Schritt gefragt, 
in welchem Verzeichnis Deine Toolchain liegt (präziser: das 
bin-Verzeichnis, also z.B. C:\stm32tc\gnuarm48\bin). Hast Du da die 
richtigen Angaben gemacht?

vg Klaus

Hallo Klaus,

Danke fürs erste, habe das gecheckt und bin drauf gekommen, dass ich 
eine falsche eclipse.zip hertuntergeladen habe.
Also wieder fast von vorne, ergab zwar immer nach das Problem mit dem 
falschen make.exe von Borland (warum ?), ließ sich aber wieder durch 
ändern der Path Variablen in Windows behben.
Läuft nun bis zum debuggen richtig aber nach "Debug Configuration .." 
und "debug" gibt es die Fehlermeldung:

Open On-Chip Debugger 0.8.0 (2014-04-28-08:42)
Licensed under GNU GPL v2
For bug reports, read
  http://openocd.sourceforge.net/doc/doxygen/bugs.html
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : This adapter doesn't support configurable speed
Error: read version failed
in procedure 'transport'
in procedure 'init'

LG Fritz

Hallo Klaus,

P.S.
Eclipse konnte ich nur 4.4 runterladen, die ältere 4.3 Version fand ich 
nicht.

Hallo Stefan,

ich habe einige leichte Anpassungen an der Seite vorgenommen, aber wohl 
vergessen, hinterher auf "Veröffentlichen" zu klicken. Die Seite ich 
jetzt wieder online.

Zwischenzeitlich wurden viele Fehler korrigiert und die Toolchain 
funktioniert problemlos mit den neuesten Versionen von Windows (8.1), 
Eclipse, Java und dem STM32CubeMX.

Viele Grüße

Klaus

Hallo Martin,

das ist jetzt nicht wirklich eine Lösung für Dein Problem, aber 
möglicherweise ein gangbarer Work-Around: Nutze nicht das Eclipse-Plugin 
vom CubeMX, sondern die Standalone-Version.

vg Klaus

Martin schrieb:
> Hallo zusammen,
>
> beim Aufbau der TC kann ich das Cube Eclipse-Plugin nicht konfigurieren.
> Beim Aufruf Help->Updater Settings kommt immer die Meldung "Updater is
> already in use", obwohl m.W. kein Updater läuft. Hat jemand eine Idee
> woran es liegen könnte. Ich verwende java 1.7.0 Update 71 und Eclipse
> Luna Service Release 1 (4.4.1).
>
> Vielen Dank,
>
> Martin

Habe das gleiche Problem. Konnte das schon jemand lösen?

VG Deepdiver99

Super Tutorial!

Zu diesem Abschnitt ist mir aufgefallen, dass dieser Fehler bei mir 
nicht aufgetreten ist und wahrscheinlich behoben wurde:
------------------------------------------------------------------------ 
--
Ein Fehler ist den CubeMX-Entwicklern bei der Definition wohl doch 
unterlaufen. Suche weiter unten diesen Codeabschnitt
/*Configure GPIO pins : PD12 PD13 PD14 PD15
PD4 */
GPIO_InitStruct.Pin = GPIO_PIN_12|GPIO_PIN_13|GPIO_PIN_14|GPIO_PIN_15
|GPIO_PIN_4;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_LOW;
HAL_GPIO_Init(GPIOD, &GPIO_InitStruct);

...und füge vor der "Pull"-Zeile noch diese Zeile ein:

GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
------------------------------------------------------------------------ 
--

Außerdem habe ich auch das Problem dass das CubeMX Plugin in Eclipse 
nicht starten will (habe auch schon mehrmals das Problem gegoogelt). 
Aber es funktioniert mit der Alternative als standalone verison ja auch 
sehr gut. Oder gibt es dies bezüglich eine Lösung?

Hallo,

habe Eclipse mit ARM GCC nach deiner Anleitung zum compilieren eines 
Projektes erstellt mit STM32Cube gebracht (für Nucleo F334, Prozessor 
und includes entsprechend angepasst). Danke hierzu. Leider funktioniert 
OpenOCD hier unter Windows 8 nicht wirklich. Irgendein Problem mit 
libusb...

Das erstellte bin-File kopiere ich dann einfach auf das Mass Storage von 
meinem Nucleo F334. Leider scheint das Programm nicht zu laufen. Keine 
LED blinkt und auch der externe Quarz schwingt nicht (wurde im der Cube 
Software allerdings ausgewählt). Ohne Debugger habe ich jetzt leider 
keine Idee wie ich heraus finde, was falsch ist.

Hat jemand eine Idee?

Danke,
Stefan

Füge noch "ARM_MATH_CM4" zu den defines dazu.

Hallo,

vielen Dank für das tolle Tutorial.

Als eine allgemeine Anmerkung:
* Ich hatte viele Probleme mit nicht aufgelösten Symbolen in Dateien die 
für das Einfach-Beispiel gar nicht benötigt werden.
==> Die Lösung war in CubeMX in --> Project Settings --> Code Generator 
--> STM32Cube Firmware Library Package --> Copy only the necessary 
library files zu wählen.


Da ich ein STM32F411RE Nucleo Board verwende, mussten ein paar Dinge 
abgewandelt werden. Da ich mir nicht sicher bin, ob das Kommentieren in 
deinem Blog funktioniert hat, hier  nochmal die notwendigen Änderungen 
für das Nucleo Board:

* Das zu definierende Symbol heißt hier "STM32F411xE", man beachte die 
Groß- und Kleinschreibung"

* Die LED2 ist hier mit dem GPIO PA5 verbunden, somit lautet der Befehl 
in der main-loop
HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_5); // GPIO Pin sollte durch CubeMX 
korrekt initialisiert sein

* OpenOCD 0.8.0 kennt das Board nicht, Verwendung von 
st_nucleo_f401re.cfg schlägt auch fehl, da die Verbindung zu GDB 
abgelehnt wird weil OpenOCD den F411 nicht als STM32 erkennen mag.
==> OpenOCD 0.9.0 behebt dieses Problem (Binaries können auch von 
freddiechopin.info heruntergeladen werden).

Hans W. schrieb:
> * OpenOCD 0.8.0 kennt das Board nicht, Verwendung von
> st_nucleo_f401re.cfg schlägt auch fehl, da die Verbindung zu GDB
> abgelehnt wird weil OpenOCD den F411 nicht als STM32 erkennen mag.
> ==> OpenOCD 0.9.0 behebt dieses Problem (Binaries können auch von
> freddiechopin.info heruntergeladen werden).

Danke für den Hinweis auf OpenOCD 0.9.0. Jetzt funktioniert auch mit 
meinem F334. Hatte zuvor immer einen libusb Error.

Und mein Problem von weiter oben hat sich mit einem anderen linker 
Script gelöst (Im Anhang). Somit funktioniert die Anleitung dann auch 
für das Nucleo F334. Danke

Falls du unter Windows entwickelst, hast du geprüft, ob der 
Kommandozeilenbefehl für das Linken mehr als 8192 Zeichen beträgt? Das 
passiert z.B. wenn man mit Stm32CubeMX alle Bibliotheken zum Projekt 
hinzufügen lässt und dementsrpechend viele Object-Files gelinkt werden 
müssen.

Unter Windows gibt es in diesem Fall Probleme, so dass einzelne Zeichen 
verschluckt werden und somit der Linker über nciht gefundene Dateien 
meckert.

Siehe z.B. [1] für einen (umständlichen) Workaround

[1] https://answers.launchpad.net/gcc-arm-embedded/+question/247577

Interessante Alternative: System Workbench for STM32

http://www.openstm32.org/HomePage

Hallo "Eclipse",

Häufig kursiert der Tipp, den Index für die AutoVervollständigung neu 
aufzubauen (Project --> C/C++ Index --> Build Index).

Viele Grüße
Klaus

eclipse schrieb:
> Hallo,
>
> erst mal auch von mir danke für das tolle toturial.
>
> Leider tut in eclipse die Autovervollstädigung nicht,
> also wenn ich z.B. HAL_D schreibe schlägt er mit nichts vor. Ist das
> Normal ? oder hab ich da was verbockt?
>
> Grüße

Meinst so Visual Studio like, dass du die Vorschläge direkt bekommst?
Meines Wissens geht das nur eingeschränkt mit CDT und du musst 
STRG+Leertaste drücken.
Unter Preferences -> C/C++ -> Editor -> Content Assist kannst du die 
Punkte für "Auto-Activation" auswählen.
Ich stand letztens auch vor der Frage (bei TrueStudio, was ja auf 
Eclipse basiert). Bei Java gibt bei "Auto-Activation" wohl die 
Möglichkeit frei zu definieren, bei welchen geschriebenen Zeichen das 
Vorschlagsfenster aufpoppt.

Hallo Max,
kannst Du "make" auf der Kommandozeile aufrufen?

vg Klaus

Ist dein eclipse_home richtig oder überhaupt gesetzt?

Ich habe jetzt keine Ahnung von Eclipse, weil ich keine IDE mag, aber 
notfalls kannst du bei deinen Variablen (letztes Bild) doch mal in PATH 
den vollen Pfad angeben (C:\stm32tc\GnuWin32\bin statt oder zusätzlich 
zu $(eclipse_home)\GnuWin32\bin).

Hallo Max,

ja, ein wenig mehr Arbeit ist das schon, dafür bekommst Du 100x mehr 
Leistung für das gleiche Geld und insbesondere ausgereifte 
Debugging-Funktionaliät.
ich meinte die Windows-Kommandozeile (DOS-Box), die Du im Startmenü mit 
"cmd" starten kannst.

vg Klaus

Tatsächlich weiß ich nicht so wirklich, wie in Eclipse die Pfade 
verwaltet werden ...
Füge den Pfad zu make/rm/echo einfach mal direkt in den 
Windows-Systemsteuerung (Startmenü --> "Umgebungsvariablen") hinzu.

Kann man bei der Installation denn etwas "falsch" machen? Hast Du 
vielleicht mehrere "make" im Pfad und kann sich das System deshalb nicht 
für eines entscheiden?

Klaus L. schrieb:
> kann sich das System deshalb nicht
> für eines entscheiden?

Das System nimmt üblicherweise das erste was es findet.

Eclipse wird die benötigten Pfade aber nicht systemweit einstellen. 
Insofern finde ich diese herangehensweise nicht so zielführend. Wobei 
der Umkehrschluß, also das make funktioniert in cmd, schon sehr positiv 
gewesen wäre.

PATH_C_stm32tc_GnuWin32_bin.JPG
Ich bin mir unsicher, ob Zugriff verweigert wirklich als nicht gefunden 
zu interpretieren ist. Dann schon eher ein falsches make. Aber das 
sollte ja einfach auf dem System zu finden und auszuschließen sein.

Er hat ja ein File compiliert. Dafür mußte er bereits make ausführen und 
ein passendes Makefile haben. Wenn nicht vorab ein clean gemacht wurde, 
könnte der nächste Schritt das Linken gewesen sein?

max schrieb:
> Ich könnte AtmelStudio einfach deinstallieren oder bringt das nichts?

Nicht immer gleich alles durcheinander bringen. Für einen Test würde es 
reichen das make im  Atmelstudio umzubenennen und zu testen. Ich glaube 
nicht, das dein Problam daran liegt. Und du willst doch sicher auch 
später noch das AtmelStudio nutzen.

baster:
> ich hab lange
> gesucht, bis ich gemerkt habe, dass das compilat nicht gelöst werden
> kann.

In dem Falle wäre die Fehlermeldung korrekt (Zugriff verweigert). Idee 
finde ich gut.

Vielleicht mal ein 'Clean' und schauen, was im Debug-Ordner übrig 
geblieben ist. Zum testen auch mal per Hand löschen und dann ein Build.

Anm: Hoffe, du hast das automatische Build after Clean aus. Sonst kann 
man die Einzelschritte schlecht nachprüfen.

Hallo zusammen,

ich habe mich jetzt hier mal als 00maxi angemeldet (war bisher ja nur 
Gast)


Der Tip von bastler has nicht geholfen (ich bin immer als Admin 
angemeldet)


Auch der Tip das make aus dem Atmel-Studio umzubenennen hat nichts 
geändert.


Steffen Roses Tips haben folgendes ergeben:
 - Einen 'clean' durchführen  (rechte Maustaste aufs Projekt und dann 
'Clean Project' ausführen hat in der Verzeichnisstruktur unter 
kl_tut_04\Debug anscheinend keine Veränderung gebracht (siehe 
Screenshot)
(auf welche Datei sollte ich hier genau schauen?)

 - wenn ich den makefile unter kl_tut_04\Debug\Src manuell lösche und 
das Hammersymbol ( Build 'Debug' for Project ) anklicke erscheint wieder 
die ursprüngliche makefile-Datei.


Hmm, was kann ich noch tun?

00maxi

Max schrieb:
> ich habe den Pfad bei den Umgebungsvariablen hinzugefügt.
> Nach "make" in der Eingabeaufforderung wieder die selbe Fehlermeldung.

Danach ist evtl auch abmelden/anmelden angesagt bevor es wirksam wird. 
Wenn es dann immer noch nicht geht dann hast Du Dich vertippt. Überprüfe 
den Pfad nochmals genauestens. Wenn es im Pfad ist dann wird es auch 
gefunden werden.

Maximilian Scherff schrieb:
> Hmm, was kann ich noch tun?

Ich (und bastler vermutlich auch) bezog mich auf den Stand "23.03.2015 
21:23"
Da wurde make gefunden, aber der Zugriff auf irgendwas verweigert.
(kl_tut_3)

Jetzt bist Du wieder ganz am Anfang, wo make nicht gefunden wurde.

Kannst Du den Zustand aus PATH_C_stm32tc_GnuWin32_bin.JPG wieder 
herstellen? Der war ein Fortschritt gegenüber deinem jetzigen Zustand.

Anm:
'Clean' benötigt auch make. Insofern muss dieser Test wiederholt werden, 
wenn Dein make wieder gefunden wird.

Nach deinem Bild zu urteilen ist eine mögliche erzeugte Datei nicht im 
Weg, da bisher nicht erstellt (*.elf direkt im Debug Ordner). Der 
Bildausschnitt ist aber gut gewählt.

Hallo Steffen,

Danke für Deine Hinweise.

ich habe unter
Window - Preferences - C/C++ - Build - Environment
wieder den PATH   c:\stm32tc\GnuWin32\bin eingestellt (Siehe Anhang 
'c_PATH'; vorher war es $(eclipse_home)\GnuWin32\bin ).

Nach drücken des 'Hammer'-Symbols läuft der Build-Prozess durch. Dabei 
wird in der CDT-Build-Console eine risige Liste an Meldungen angezeigt, 
die mit
'
!make: *** 
[Drivers/CMSIS/DSP_Lib/Source/TransformFunctions/arm_bitreversal.o] 
Fehler 1
22:45:16 Build Finished (took 4s.384ms)
'
endet .

Nach einem 'Clean' mit rechter Maustaste auf das Project und dann 
'Clean' erscheint die folgende Meldung  (siehe Anhang 'Clean_Project')


Nach einem 'Clean..' (Hauptmenue - Project - Clean..) bei abgeschalteten 
automatischen Build (Hauptmenue - Project - Build Automatically) läuft 
anscheinend ganz kurz der Clean- und dann der Build-Prozess mit den zig 
Meldungen hintereinander ab (siehe Anhang 'Clean'). --> das 
automatische-Build-after-Clean scheint noch aktiv zu sein. Wie schalte 
ich das denn tatsächlich ab, kein Häkchen scheint nicht zu genügen?

Lösche ich den make-File manuell und mache einen 'Clean..' (Hauptmenue - 
Project - Clean..) kommen wieder die vielen Meldungen und der make-File 
erscheint wieder im Projektordner.


Bei allen Tests war die Änderung der Umgebungsvariablen aktiv (siehe 
Anhang; ist das richtig eingestellt)

Wat nu?

OK, jetzt funktioniert das make wieder.

build:
Die Meldungen sind Compiler Fehler. Hier mußt du mal auf die erstem 
Meldungen schauen. Ich würde auf fehlende Include Pfade tippen.

clean:
Auch dein clean funktioniert scheinbar nicht. Zumindest sieht mir die 
Befehlszeile etwas merkwürdig aus. Prinzipiell darf das clean Fehler 
bringen, falls die Dateien nicht da sind. Jedoch sind bei Dir die 
Dateien auch nach einem clean noch da.
Da ich die Umgebung jedoch nicht genau wie du einsetze, kann ich dies 
nicht genau einschätzen.

Hallo zusammen,

die obersten Zeilen der CDT-Build-Console lauten  (Anhang)
'
uint16_t numTaps;             /**< number of coefficients in the filter. 
*/
     ^
C:/stm32ws/kl_tut_04/Drivers/CMSIS/Include/arm_math.h:4713:5: error: 
unknown type name 'uint16_t'
     uint16_t stateIndex;          /**< state buffer index.  Points to 
the oldest sample in the state buffer. */
'
Es laufen aber wirklich viele Meldungen durch. Wohlmöglich gab es noch 
mehr Meldungen, die nicht mehr durch scrollen erreicht werden können?

Hängt das 'Clean' denn auch mit dem Compiler zusammen?

Max

Der eigentliche Fehler scheint schon durcu zu sein.
- Klicke eine *.c Datei an.
- Rechte Maustaste - Build Selected File

Das sollte nur ein File übersetzen und hoffentlich nicht so viele Fehler 
bringen.


Maximilian Scherff schrieb:
> '
> uint16_t numTaps;             /**< number of coefficients in the filter.
> */

Deine Standard Includepfade scheinen nicht zu passen.
Du solltest vermutlich in den jeweiligen C-Files etwas wie
#include <stdint.h>
finden. Den Header findet der Compiler nicht.

Das sollte er aber eigentlich automatisch finden. Keine Ahnung, wo man 
diese Systemincludes einstellt. Dies ist Sache der gcc-Installation - 
nicht von Eclipse.

Du kannst C:\stm32tc\gcc49\include mit in deinen Anwenderinlcudes 
nehmen.
(Pfad prüfen!) Aber richtig ist das eigentlich nicht.

> Hängt das 'Clean' denn auch mit dem Compiler zusammen?

Clean == make clean
Build == make all

D.h. beides basiert auf make und den generierten makefiles.

Micha:
> $(eclipse_home)\..\GnuWin32\bin
Maximilian scheint die Eclipse Umgebung an eine andere Stelle 
installiert zu haben?

ist alles unter Laufwerk C installiert (Anhang).

Ich wollte grad mal Steffens Tip ausprobieren
'
Der eigentliche Fehler scheint schon durcu zu sein.
- Klicke eine *.c Datei an.
- Rechte Maustaste - Build Selected File
'

aber nach dem Rechner Hochfahren ist die main.c Datei nicht mehr unter 
kl_tut_04 Src vorhanden??

Maxi

@Micha:
lt.
(Partielle) Erfolgskontrolle
sollte eclipse_home in diesem Artikel c:\stm32tc sein und wie du schon 
sagst, GnuWin32 in diesem enthalten sein.

Wenn ich es richtig verstanden habe, funktioniert
C:\stm32tc\GnuWin32\bin
aber nicht
$(eclipse_home)\GnuWin32\bin

D.h. eclipse_home ist nicht C:\stm32tc.
Dein Vorschlag nimmt an, dass eclipse_home eine Ebene tiefer ist.

@Maximilian:
In welchem Verzeichnis liegt bei dir die eclipse.exe?


@Maximilian:
Dass deine Compilierung an uint16_t scheitert ist schon merkwürdig.

Im verlikten Artike wird unter
> Dialog “C Project, Cross GNU ARM Toolchain”
noch der gcc4.8 genutzt.
Ich gehe mal davon aus, dass due hier den von dir installierten 4.9 
eingetragen hast. Da Compilerfehler kommen, sollte das aber passen.

Vielleicht nochmal alle Punkte durchgehen und prüfen, ob die jeweiligen 
Pfad-Angaben mit denen bei Dir übereinstimmen.

Hallo

@Steffen schrieb
'Wenn ich es richtig verstanden habe, funktioniert
C:\stm32tc\GnuWin32\bin
aber nicht
$(eclipse_home)\GnuWin32\bin'
  --> stimmt, aber die eclipse.exe liegt in C:\stm32tc (siehe 
screenschot 'c-Ordner')


Steffen schrieb
'Ich gehe mal davon aus, dass due hier den von dir installierten 4.9
eingetragen hast. '
  --> Ich meine ja. Unter kl_tut_04 Properties c/C++ Settings Toolchains 
Toolchain pat: steht zumindest 'C:\stm32tc\gcc49\bin' (siehe Screenshot 
'Aktuel 7')


Die Pfadangaben stimmen soweit, allerdings sind mir noch zwei 
Unterschiede aufgefallen.
1) im vorletzten Screenshot des Tutorial (Debug Configurations Debugger) 
sieht die Seite anders aus als bei mir (vergleiche mit screenshot 
'Aktuel 6')

2) Im Tutorial (viertletzter Screenshot; kl_tut_01 Properties C/C++ 
Build Settings Tool-settings General) ist ist der Pfad anders. Dort 
taucht im gegensatz zu meinem Pfad nach dem Projektnamen (kl_tut_01) 
noch zusätzlich der Unterordner '\Projects\' auf.

Ich meine alle Pfade sond OK!?

Max

Hallo

@Micha
Danke für den Hinweis. Die Seite kannte ich noch nicht


 1) Das erste wass mir dort auffällt ist, das ich eclipse Luna4.4.2 
installiert habe anstelle des dort propagierten Kepler.
'
The plug-ins also work on Eclipse 4.4 Luna, but the initial Luna release 
has some small problems (for example occasionally disabled buttons when 
starting the debugging session). If you want to live on the edge, these 
problems can be overcome, but if you want to play safe, better use 
Kepler 4.3 SR2.
'
wie könnte ich den auf Kepler zurückrüsten? oder ist das für LUNA4.4.2 
nicht mehr nötig?


 2) In der PlugIn Install Anleitung wird bei der Kelper Installation 
unter 'Programming Languages' von 'C/C++ Development Tools' gesprochen 
und in der entsprechenden Abbildung taucht als installierte Software 
'Autotools support for CDT' auf. Das finde ich bei den bei mir 
installierten Paketen nicht. Dort gibt es nur ein 'CDT Standalone 
Debugger Support' Paket (siehe Screenshot)

Im Tutorial steht nichts von einer separaten CDT Installation. Ist das 
Bei eclipse LUNA schon drinn?

Max

Ich habe jetzt mal 'CDT 8.6.0 for Eclipse Luna' von 
http://download.eclipse.org/tools/cdt/releases/8.6  nachinstalliert, 
eclipse neu gestartet

  --> gleicher Fehler (1000 Meldungen)

CDT hast/hattest Du bereits.
Ob Du jetzt zwei hast, die sich stören, kann ich nicht sagen.
Bei den verschiedenen Eclipse Versionen kenne ich mich auch nicht aus.


Übersetze mal nur ein einzelnes File. Die ersten Fehler-Meldungen sind 
relevant. Die späteren, die Du zeigt, deuten auf ein Fehlen/Nichtfinden 
von stdint.h hin. Wäre aber arg ungewöhnlich. gcc kennt die Pfade 
eigentlich selbst.

> - Klicke eine *.c Datei an.
> - Rechte Maustaste - Build Selected File

Maximilian Scherff schrieb:
> The plug-ins also work on Eclipse 4.4 Luna, but the initial Luna release
> has some small problems (for example occasionally disabled buttons when
> starting the debugging session). If you want to live on the edge, these
> problems can be overcome, but if you want to play safe, better use
> Kepler 4.3 SR2.

Diese Probleme scheinen weg zu sein. Ganz am Anfang beobachtete ich das 
Problem daß manchmal die Buttonleiste für den Debugger ausgegraut war. 
Dieses Problem habe ich aber wenn ich so drüber nachdenke seit Monaten 
nicht mehr gesehen (trotz Eclipse Luna) sowohl unter Windows als auch 
unter Linux, es läuft momentan alles anscheinend alles vollkommen rund. 
Kein Grund zum Downgrade.

Ich benutze übrigens nicht die Release sondern die nightly Test-Version 
der Plugins http://gnuarmeclipse.sourceforge.net/updates-test/

@ Steffen

 1.) Ich habe den Build selektiv für die main.c gemacht. Ergebnis
'
19:53:44 **** Building Selected Files of configuration Debug for project 
kl_tut_04 ****
Info: Internal Builder is used for build
arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=softfp 
-mfpu=fpv4-sp-d16 -O0 -fmessage-length=0 -fsigned-char 
-ffunction-sections -fdata-sections -g3 -DSTM32F407xx -DUSE_HAL_DRIVER 
-IC:/stm32ws/kl_tut_04/Drivers/CMSIS/Device/ST/STM32F4xx/Include 
-IC:/stm32ws/kl_tut_04/Drivers/CMSIS/Include 
-IC:/stm32ws/kl_tut_04/Drivers/STM32F4xx_HAL_Driver/Inc 
-IC:/stm32ws/kl_tut_04/Inc -std=gnu11 -c -o "Src\\main.o" 
"..\\Src\\main.c"

19:53:45 Build Finished (took 1s.198ms)
'


@ Bernd
Ich habe die Testversion-Plug-Ins installiert und eclipse neu gestartet.
  --> Build des Projektes geribt wieder die 1000 Meldungen

wird nur ein selected Build der main.c durchgeführt kommt die gleiche 
Meldung wie grad für Steffen beschrieben

Max

zwei allgemeine Fragen

Was bedeuten die kleinen X-Symbole auf rotem Hintergrund an den 
Ordnersymbolen (Anhang 'rotes-X') ?

Wie kann man hier die Zitate grün hinterlegen?

Max

Maximilian Scherff schrieb:
> wird nur ein selected Build der main.c durchgeführt kommt die gleiche
> Meldung wie grad für Steffen beschrieben

Mach doch einen kompletten build, dann scroll ganz nach oben wo er 
anfängt und suche die erste Warnung (gelb) und die erste Fehlermeldung 
(rosa).

@ Bernd

Beim 'Build Project' von kl_tut_04 kommt die Meldung wie im Anhang 
'kompletter Build' zu sehen. Der Build-Prozess hängt jetzt bei ca. 20% 
(grüner Balken)

Maxi

hier der Anhang

@Steffen

ich habe das Anzeigelimkit der CDT Build Console von 500 Zeilen auf 5000 
erweitert, jetzt sehe ich auch die erste Meldung nach einem 'Build'

erste Meldung (siehe auch screenshot 'erweiterte Console')

20:48:40 **** Incremental Build of configuration Debug for project 
kl_tut_04 ****
make all
'Building file: 
../Drivers/CMSIS/DSP_Lib/Source/TransformFunctions/arm_bitreversal.c'
'Invoking: Cross ARM C Compiler'
arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=softfp 
-mfpu=fpv4-sp-d16 -O0 -fmessage-length=0 -fsigned-char 
-ffunction-sections -fdata-sections  -g3 -DSTM32F407xx -DUSE_HAL_DRIVER 
-I"C:/stm32ws/kl_tut_04/Drivers/CMSIS/Device/ST/STM32F4xx/Include" 
-I"C:/stm32ws/kl_tut_04/Drivers/CMSIS/Include" 
-I"C:/stm32ws/kl_tut_04/Drivers/STM32F4xx_HAL_Driver/Inc" 
-I"C:/stm32ws/kl_tut_04/Inc" -std=gnu11 -MMD -MP 
-MF"Drivers/CMSIS/DSP_Lib/Source/TransformFunctions/arm_bitreversal.d" 
-MT"Drivers/CMSIS/DSP_Lib/Source/TransformFunctions/arm_bitreversal.o" 
-c -o 
"Drivers/CMSIS/DSP_Lib/Source/TransformFunctions/arm_bitreversal.o" 
"../Drivers/CMSIS/DSP_Lib/Source/TransformFunctions/arm_bitreversal.c"
In file included from 
../Drivers/CMSIS/DSP_Lib/Source/TransformFunctions/arm_bitreversal.c:41: 
0:
C:/stm32ws/kl_tut_04/Drivers/CMSIS/Include/arm_math.h:299:4: error: 
#error "Define according the used Cortex core ARM_MATH_CM7, 
ARM_MATH_CM4, ARM_MATH_CM3, ARM_MATH_CM0PLUS or ARM_MATH_CM0"
   #error "Define according the used Cortex core ARM_MATH_CM7, 
ARM_MATH_CM4, ARM_MATH_CM3, ARM_MATH_CM0PLUS or ARM_MATH_CM0"
    ^

screenshot

Maximilian Scherff schrieb:
> #error "Define according the used Cortex core ARM_MATH_CM7,
> ARM_MATH_CM4, ARM_MATH_CM3, ARM_MATH_CM0PLUS or ARM_MATH_CM0"

Also ich hab mal kurz gegooglet (während Du das file direkt auf der 
Festplatte hast und direkt reinschauen könntest) und das sieht wohl so 
ähnlich aus wie hier:

1

/**

2

 * @defgroup groupExamples Examples

3

 */

4

#ifndef _ARM_MATH_H

5

#define _ARM_MATH_H

6

7

#define __CMSIS_GENERIC         /* disable NVIC and Systick functions */

8

9

#if defined(ARM_MATH_CM7)

10

  #include "core_cm7.h"

11

#elif defined (ARM_MATH_CM4)

12

  #include "core_cm4.h"

13

#elif defined (ARM_MATH_CM3)

14

  #include "core_cm3.h"

15

#elif defined (ARM_MATH_CM0)

16

  #include "core_cm0.h"

17

#define ARM_MATH_CM0_FAMILY

18

  #elif defined (ARM_MATH_CM0PLUS)

19

#include "core_cm0plus.h"

20

  #define ARM_MATH_CM0_FAMILY

21

#else

22

  #error "Define according the used Cortex core ARM_MATH_CM7, ARM_MATH_CM4, ARM_MATH_CM3, ARM_MATH_CM0PLUS or ARM_MATH_CM0"

23

#endif

Na also dann definier doch mal das symbol "ARM_MATH_CM4" und dann 
probiers nochmal.


Alternativ würd ich vorschlagen der bessere Weg ein komplett neues 
System kennenzulernen ist sich erstmal vorsichtig ranzutasten und 
erstmal ein absolut simples Blinky-Projekt aus nur einer Handvoll 
Dateien ohne HAL und zwölftausend Zusatzlibs zu kompilieren (Es gibt 
einige Minimalbeispiele im Web) und dann schrittweise nur das an libs 
reinzunehmen was Du wirklich brauchst (wenn überhaupt) anstatt so einen 
unübersichtlichen Riesen-Moloch am Stück von null auf beherrschen zu 
wollen in einer Umgebung mit der man noch nicht komplett vertraut ist.

Also fang erstmal mit was kleinerem an das nur aus 5 Dateien besteht und 
nicht aus 500, so daß Du eine Chance hast das in endlicher Zeit zu 
komplett zu überblicken und zu verstehen und dann nimmst Du das als 
Ausgangspunkt. Das wird Dir mehr Sicherheit und Kontrolle geben.

Hallo Bernd,

Danke für den Tip.

Ich habe das Symbol ARM_MATH_CM4 definiert (Screenshott) und dierekt 
durchlaufen lassen. Hier kamen nur noch drei Meldungen und der Hinweis, 
dass der Zugriff auf 'make' verweigert wurde (Screenshot 1.Durchlauf).

Nach dem Restart von eclipse kommt etwar 100 mal (auch schon die erste) 
die selbe Meldung (rosa Hintergrund).

'C:/stm32ws/kl_tut_04/Drivers/CMSIS/Include/core_cm4.h:131:8: warning: 
#warning "Compiler generates FPU instructions for a device without an 
FPU (check __FPU_PRESENT)" [-Wcpp]'

und zum Schluss

'make: *** [kl_tut_04.elf] Fehler 1'


Bzgl. der Projektgröße bin ich nur dem Tutorialm gefolgt. Anscheinend 
ist ein mithilfe des STMCubeMX-Toll erstelltes Project automatisch so 
gross. Im Tutorial werden ja nur noch zwei Zeilen hinzugefügt.
Hast Du nen guten Tip für Einsteiger?

Danke nochmal

Max

@bastler

Aha, jetzt hab ichs mit dem Adminstart geschnallt!!
Läuft jetzt auch viel schneller durch mit nur einer Fehlermeldung am 
Ende
'
make: *** [kl_tut_04.elf] Fehler 1
'

Was ist den Fehler 1??  Gibt es irgendwo ne Fehlerliste??

Max

Maximilian Scherff schrieb:

> Was ist den Fehler 1??  Gibt es irgendwo ne Fehlerliste??

Steht doch da warum er abbricht.

Wie wärs du wirfst endlich dieses kaputte Beispielprojekt aus diesem 
komischen Tutorial weg und fängst stattdessen mit was einfachen an für 
den Anfang, zum Beispiel ein simples LED-Blink-Projekt ohne CubeMX HAL 
und den ganzen überflüssigen Schrott bis Du wenigstens Dein Buildsystem 
halbwegs im Griff hast? Nur mal so als Vorschlag?

Und übrigens: Eclipse als Administrator ausführen ist ja wohl der größte 
Unfug den ich seit mindestens 2 Wochen irgendwo (inclusive hier!) 
gelesen habe. Vergiss das mal ganz schnell wieder und such stattdessen 
die Ursache.

@Bernd

Ich habe hier ein anderes Blink Projekt gefunden und über File Import 
General Existing_Project_into_Workspace Copy_project_into_workspace 
importiert.

http://tecsploit.com/stm32f4-discovery/hello-world-using-an-stm32f4-discovery/

ein Build erzeugt folgend Meldung
'
22:06:58 **** Build of configuration Default for project blink1 ****
make all
Das System kann den angegebenen Pfad nicht finden.
process_begin: CreateProcess(NULL, arm-none-eabi-gcc --version, ...) 
failed.
make (e=2): Das System kann die angegebene Datei nicht finden.

make: *** [start] Fehler 2

22:06:58 Build Finished (took 292ms)
'

Maximilian Scherff schrieb:
> Import
> General Existing_Project_into_Workspace

Ein Projekt das bereits ein Makefile hat und dafür vorgesehen ist mit 
dem Makefile kompiliert zu werden muss mit "c/C++ -> Existing Code as 
Makefile Project" importiert werden.

Aber ich würde erstmal sicherstellen daß das außerhalb von Eclipse an 
der Kommandozeile mit make kompiliert werden kann. Ansonsten kämpfst Du 
an 2 Fronten gleichzeitig. Also bring das erstmal an der Kommandozeile 
zum Laufen (finde heraus was noch fehlt oder was nötig ist um das zu 
erreichen) und im nächsten Schritt erst importierst Du es in Eclipse.

Das Kompilieren des Projekts mit make und das Verwenden des Projekts mit 
Eclipse sind zwei Dinge die man völlig getrennt und unabhängig 
voneinander betrachten kann (deshalb könntest später Du wenn das Projekt 
erstmal steht ohne irgendwelche Probleme jederzeit die IDE wechseln), Du 
kannst also die Fehlersuche dieses misslungenen Build-Prozesses auf eins 
der beiden eingrenzen ohne Dich mit beiden gleichzeitig rumzuschlagen, 
vor allem wenn noch nicht klar ist woran es letztlich liegt ist das eine 
große Hilfe.

Öffne also mal eine Kommandozeile in dem Projektordner (dort wo sich das 
Makefile befindet) und rufe make direkt von der Kommandozeile auf und 
bring das erstmal zum Laufen.

Maximilian Scherff schrieb:
> 1.) Ich habe den Build selektiv für die main.c gemacht. Ergebnis

Deine main.c wird doch sicher Standard Header includieren.

Dann mal direkt arm_bitreversal.c

Bernd K. schrieb:
> Mach doch einen kompletten build, dann scroll ganz nach oben wo er
> anfängt

Da er zuviele Meldungen bekommt konnte er die erste Meldung nicht 
mitteilen.

Maximilian Scherff schrieb:
> Der Build-Prozess hängt jetzt bei ca. 20%

Der verweigerte Zugriff ist ein zweiter Fehler und hat mit dem 
Compiler-Fehlermeldungen nichts zu tun.

Vermutlich hast Du ein Explorer-Fenster oder eine Konsole offen die in 
dein Projekt guckt und so das Löschen verhindert.

Maximilian Scherff schrieb:
> #warning "Compiler generates FPU instructions for a device without an
> FPU (check __FPU_PRESENT)" [-Wcpp]'

Das ist eine globale Projekteinstellung bei den Compiler Settings.

Maximilian Scherff schrieb:
> Was ist den Fehler 1??  Gibt es irgendwo ne Fehlerliste??

Du machst nicht jedesmal das Gleiche. Daher sind Vergleiche der 
verschiedenen Zustände unmöglich.

Mach immer ein clean am Anfang.

Hier fehlen 3 Objektfiles. Warum das 'Build' scheinbar trotzdem versucht 
zu linken, weiß ich nicht. Das mittlere hat aber einen Schreibfehler. 
Hast Du hier irgendwas geändert?

Micha schrieb:
> Möglicherweise darfst du als Nicht-Admin nicht einfach in einem
> C-Unterordner rumbasteln.

Prinzipiell hast Du schon recht, dass man bei Windows nicht einfach 
überall schreiben darf.

Relevanz hat aber hier der Debug-Ordner. Und den durfte er anlegen.

Bernd K. schrieb:
> (finde heraus was noch fehlt oder was nötig ist um das zu
> erreichen)

Ihm fehlen generell die Pfade. Er muss diese aktuell immer wieder von 
Hand nachziehen. Wo man dies korrekter Weise hinterlegt, weiß ich aber 
auch nicht. Ich nehme die Umgebung nur innerhalb von Eclipse. Außerhalb 
würde es ohne weitere Pfad-Einstellungen und Umgebungsvariable auch 
nicht laufen. Da ich jedoch viele verschiedene Umgebungen im Einsatz 
habe, wären solche globalen Einstellungen auf meinem System tödlich.

Hallo Ich bekomme bei dem Schritt

"Nun zu dem bereits als Datei herunter geladenen STM32CubeMX

    -->Help -->Install new Software -->Add -->Archive -->Zip-Datei vom 
STM32CubeMX-Plugin auswählen.
    Durchbestätigen"

die Fehlermeldung "Could not find..."


Kann mir jemand helfen?

Danke!

Wurde das File beim Compile-Schritt übersetzt?
- c-File Teil des Projektes
- kein Error beim compilieren

Bitte vorher immer ein clean machen.

Nimmst Du jetzt ein eigenes Makefile oder ein von Eclipse erzeugtes?
Eigentlich hätte es eine Abhängigkeit ziwschen c und o File geben müssen 
und die Übersetzung hätte bereits in diesem Schritt abbrechen sollen.

Gabriel E. schrieb:
> "Could not find..."

Sieht mir nicht gerade wir ein ordentlicher Pfad zu einer zip-Datei aus.
jar:file:...zip!/

Hallo zusammen,

nach den Osterferien bin ich wieder da.
In der Zwischenzeit bin ich etwas weiter gekommen. Ich habe mich dazu an 
den unten stehenden Tutorials gehalten, die das gleiche Thema haben, 
aber etwas umfangreicher beschrieben sind und das Nucleo-Board 
verwenden. Außerdem wird das CubeMX nicht ins eclipse implementiert, was 
Klaus L. in seinem Tutorial ja auch als mögliche Option anmerkt (aber 
nicht genau beschreibt).

http://www.carminenoviello.com/en/2014/12/28/setting-gcceclipse-toolchain-stm32nucleo-part-1/
http://www.carminenoviello.com/en/2015/01/07/setting-gcceclipse-toolchain-stm32nucleo-part-2/
http://www.carminenoviello.com/en/2015/01/16/setting-gcceclipse-toolchain-stm32nucleo-part-iii/

Das erste Tutorial wird nun erfolgreich umgesetzt und der 'Build' mit 
der Console:
"
22:05:02 **** Incremental Build of configuration Debug for project 
teset12 ****
make all
'Invoking: Cross ARM GNU Print Size'
arm-none-eabi-size --format=berkeley "teset12.elf"
   text     data      bss      dec      hex  filename
   8385      160      420     8965     2305  teset12.elf
'Finished building: teset12.siz'
' '

22:05:04 Build Finished (took 1s.934ms)
" abgeschlossen. Ich kann auch mit der ST-Link-Utility den code auf den 
MC transferieren.

Im zweiten Tutorial komme ich bis zur Hälfte
"Click on “Apply” and then on “Run“. You’ll see these messages in the 
Eclipse console"

Dort erhalte ich folgende (Fehler-)Meldung in der Console in roter 
schrift:
"
Open On-Chip Debugger 0.8.0 (2014-04-28-08:39)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : This adapter doesn’t support configurable speed
Error: read version failed
in procedure ‘transport’
in procedure ‘init’
"

Was läuft falsch

Setzt Du auch wirklich den OpenOCD Debugger ein und hast diesen 
erfolgreich installiert und den Server gestartet?
Oder nimmst Du eher den ST-Link?

Steffen Rose schrieb:
> Setzt Du auch wirklich den OpenOCD Debugger ein und hast diesen
> erfolgreich installiert und den Server gestartet?
> Oder nimmst Du eher den ST-Link?

laut dem Tutorial
http://www.carminenoviello.com/en/2015/01/07/setting-gcceclipse-toolchain-stm32nucleo-part-2/
konfiguriere ich OpenOCD als externes Tool (siehe screeshot "External 
Tool-Configurations") und starte mit "Run" (erste Hälfte des Tutorial)

bis zum konfigurieren des GDB um es mit dem OpenOCD über den 3333 TCP 
port zu verbinden komme ich nicht (zweite Hälfte des Tutorial).

In einer frühreren Nachricht wurde mal gefragt ob ich make über die 
Kommandozeile starten kann --> geht nicht (siehe screenshot "make"). Wie 
muss die korrekte Meldung lauten?

Ich habe mal die aktuelle Verzeichnisstruktur und den PATH angehängt. 
Ist das alles konsistent? I

@Micha:
Dies war meine Entgegnung zum Vorschlag von Bernd, die Makeumgebung 
erstmal außerhalb von Eclipse zum Laufen zu bringen.

Beitrag "Re: STM32-Toolchain mit Eclipse CDT 4.3, GnuArmEclipse, OpenOCD 0.8.0, Gnu Arm GCC 4.8, STM32CubeMX"

Dies hat den Vorteil, wenn man seine Einstellungen global unter Windows 
macht, auch Windows die Eclipse Aufrufe auflösen kann. Hier gebe ich 
Bernd recht.

Das hatte Maximilian aber weiter oben schonmal angefangen und ist nicht 
weitergekommen (PATH Variable). Dadurch würde man hier auf zwei Fronten 
kämpfen.

Prinzipiell ist es ausreichen, Eclipse beizubringen, wo make und gcc 
liegen.
Das hat Maximilian mehrfach erfolgreich gemacht.
Merkwürdigerweise ist dies bei ihm aber nicht global bei Eclipse 
hinterlegt, sondern eine Projekteinstellung. Diese war bei einem neuen 
Projekt wieder weg.

Wie man dies aber korrekt dauerhaft hinterlegt, weiß ich auch nicht.

Maximilian scheint aber nach dem Bearbeiten der von ihm geposteten Links 
damit keine Probleme mehr zu haben. Der erste Link sollte der Relevante 
sein.

Maximilian Scherff schrieb:
> laut dem Tutorial
> 
http://www.carminenoviello.com/en/2015/01/07/setting-gcceclipse-toolchain-stm32nucleo-part-2/
> konfiguriere ich OpenOCD als externes Tool (siehe screeshot "External
> Tool-Configurations") und starte mit "Run" (erste Hälfte des Tutorial)

Das ist doch Unfug, schmeiß das Tutorial weg!

Eine Zeile tiefer ist "OpenOCD Debugging", das musst Du nehmen, das ist 
speziell dafür gemacht, nicht "GDB Hardware Debugging". Du musst auch 
kein externes Tool konfigurieren, einfach alles im "OpenOCD Debugging" 
Dialog korrekt ausfüllen.

Bernd K. schrieb:

> Eine Zeile tiefer ist "OpenOCD Debugging", das musst Du nehmen, das ist
> speziell dafür gemacht, nicht "GDB Hardware Debugging". Du musst auch
> kein externes Tool konfigurieren, einfach alles im "OpenOCD Debugging"
> Dialog korrekt ausfüllen.

OK, wenn ich "OpenOCD Debugging" auswähle (screenshot 'Debugger Tab') 
erscheint nach erfolgreichem Build:
'Missing mandatory configuration. Fill-in the 'Config options:' field in 
the Debugger tab.' (siehe screenshot 'Fehler fill in 'config options'')

Was muss in das Feld 'config options' eingetragen werden?
Was muss in die anderen Tabs?

Max

Maximilian Scherff schrieb:

> Was muss in das Feld 'config options' eingetragen werden?
> Was muss in die anderen Tabs?

Lass Dich mal von den Screenshots in diesem Posting im anderen Thread 
inspirieren: Beitrag "Re: STM32 unter Linux programmieren und debuggen"

Das wurde zwar unter Linux gemacht aber es ist sinngemäß (wenn man mal 
die Pfade entsprechend anpasst und die Tatsache berücksichtigt daß Du 
ein Discovery hast und ich ein Nucleo) mehr oder weniger identisch.

Kai schrieb:
> Allerdings bekomme ich die
> Warning-Meldungen beim ersten Übersetzen, das FPU Code erzeugt wurde für
> eine Device, das keine FPU hat. Ich habe aber das STM32F407-VGT6
> Discovery Board.

Da wird der Compiler recht haben.
Ich persönlich würde am Anfang erstmal alles ohne FPU Nutzung übersetzen 
und mich dann vorarbeiten. Die FPU muss ja an mehreren Stellen 
unterstützt werden (u.a. startup-file, Link-Libraries).

Ich gehe davon aus, dass Du an der Stelle, wo die Warnung kommt, ein 
falsches Setting hast. Aber auf die Idee bist du sicher schon gekommen.

Evtl. mal über das Setting '-mfloat-abi=' informieren.

Micha schrieb:
> ist das aber im GNU-ARM-Eclipse-plugin ausdrücklich
> so gewünscht

OK. Danke.

Kai schrieb:
> Das Subdirectory StaisticsFunctions gibt es nicht. Da fehlt ein "t"
> zwischen a und i. Wie kann das sein, dass es zu diesem Schreibfehler
> kommt? Ich habe definitiv keine falschen Verzeichnisnamen angegeben.
> Compiliert sind alle Dateien ohne Probleme.

Poste mal das Makefile.

Bernd K. schrieb:
> Maximilian Scherff schrieb:
>
>> Was muss in das Feld 'config options' eingetragen werden?
>> Was muss in die anderen Tabs?
>
> Lass Dich mal von den Screenshots in diesem Posting im anderen Thread
> inspirieren: Beitrag "Re: STM32 unter Linux programmieren und debuggen"

Hallo Bernd,
ich habe mich mal inspirieren lassen und in den 'Arguments' der 
"External Tools Configurations" und auch in den 'config Options' der 
"Debug Configurations" -f "scripts\board\stm32f4discovery.cfg" 
eingetragen.


Wird "Run" ausgeführt folgt immer folgende Meldung in roter Schrift in 
der Console:
"
Open On-Chip Debugger 0.8.0 (2014-04-28-08:39)
Licensed under GNU GPL v2
For bug reports, read
  http://openocd.sourceforge.net/doc/doxygen/bugs.html
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : This adapter doesn't support configurable speed
Error: open failed
in procedure 'transport'
in procedure 'init'
"

Wird "Debug" ausgeführt sich ein Fenster mit der Meldung (screenshot):
"Error in services launch sequence
Launching command [/C:\stm32tc\openocd8\bin -c gdb_port 3333 -c 
telnet_port 4444 -f scripts\board\stm32f4discovery.cfg -c echo "Started 
by GNU ARM Eclipse"] failed.
Launching command [/C:\stm32tc\openocd8\bin -c gdb_port 3333 -c 
telnet_port 4444 -f scripts\board\stm32f4discovery.cfg -c echo "Started 
by GNU ARM Eclipse"] failed.
Cannot run program "/C:\stm32tc\openocd8\bin": Launching failed

@kai
Keine Idee.

Bleibt das problem anhängig, wenn Du das komplette target-Verzeichnis 
löscht?

Ist in diesem Makefile etwas ungewöhnlich?
Drivers/CMSIS/DSP_Lib/Source/StatisticsFunctions/subdir.mk

Wie sehen im CDT die Linkersettings aus?

Evtl. auch hier:
C:\stm32ws\kl_tut_01\TrueSTUDIO\kl_tut_01 
Configuration\STM32F407VG_FLASH.ld

was du weggelassen hast, ist nicht so spannend.
Eher, was du nicht wegelassen hast :-)

Ist in dem Quelltext stdint.h #includet?

und beim Kompilieren welcher C-Datei wird das angemeckert?