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

[Klaus L. (keyel80)]

Hallo zusammen

nachdem ich nun einige Male passiver Nutznießer dieses Boards war,
möchte ich einen Teil des erworbenen Wissens wieder an Euch zurück
geben. Mein Tutorial "STM32-Toolchain mit Eclipse CDT 4.3,
GnuArmEclipse, OpenOCD 0.8.0, Gnu Arm GCC 4.8, STM32CubeMX" beschreibt,
wie man unter Nutzung von freier sehr guter Software eine wirklich
brauchbare Toolchain für den STM32F4 (STM32F4 Discovery) zusammenstellt.

http://klaus4.blogspot.com/2014/05/stm32f4-discovery-mit-opensource.html

Ich hoffe sehr, dass meine Ausführungen dem einen oder anderen Anfänger
weiter helfen. Dies ist mein erstes Tutorial diese Art. Es würde mich
deshalb sehr freuen, wenn von Euch Verbesserungsempfehlungen kommen
würden.

Happy Coding

Klaus

[STMUser (Gast)]

Vielen Dank für deine Mühe und die gute Anleitung. Kannst du erklären, 
wie man die FPU mit dieser Toolchain nutzen kann?

[Klaus L. (keyel80)]

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

[Klaus L. (keyel80)]

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

[Klaus L. (keyel80)]

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

[STMUser (Gast)]

Danke für die Antwort. Das war genau was ich wissen/sehen wollte. Mach 
weiter so!

[Thilo H. (thaala)]

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.

[Klaus L. (keyel80)]

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

[Thilo H. (thaala)]

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.

[Klaus L. (keyel80)]

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

[Thilo H. (thaala)]

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.

[Martin R. (m-joy)]

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?

[Klaus L. (keyel80)]

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

[nhd0420 (Gast)]

Hallo Klaus,

zuerst einmal ein großes Kompliment an dich. Das ist wirklich die beste 
und ausführlichste Anleitung, die ich bisher gefunden habe. Das sieht 
alles sehr aufgeräumt und gut strukturiert aus. Genau so etwas habe ich 
gesucht. Nun zu meinem Problem: Leider haut bei mir irgendetwas noch 
nicht so ganz hin, obwohl ich streng nach deiner Anleitung vorgegangen 
bin. Bei mir wird die stm32f4xx.h von der stm32f4xx_hal_def.h nicht 
gefunden (siehe Anhang) und ich komme nicht drauf, was ich hier 
übersehen habe.Vielleicht kann mir einer von euch auf die Sprünge 
helfen? Was habe ich falsch gemacht?

[Klaus L. (keyel80)]

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

[nhd0420 (Gast)]

Hallo Klaus,

dankeschön für deine Hilfe. ich bin daraufhin das alles noch mal in Ruhe 
durchgegangen. Der Fehler, den ich gemacht habe, war ziemlich dumm, aber 
für den Fall, dass Andere auf ein ähnliches Problem stoßen, teile ich 
ihn euch mal mit.
Ich habe bei der Definition der includes, wo die unnötigen header-files 
ausgeschlossen werden sollten, den Fehler gemacht. Und zwar habe ich 
dabei am Anfang nicht verstanden, dass man jede auszuschließende 
header-Datei einzeln ausschließen muss und habe stattdessen einfach im 
übergeordneten Ordner "CMSIS" einfach "All Configuration, „Exclude 
resource from build“" angeklickt. Dadurch wiederum wurde der Unterordner 
"Include" komplett ausgeschlossen. Später, als ich den Fehler dann 
bemerkt habe, habe ich übersehen, dass der komplette Ordner "Include" 
immer noch ausgeschlossen war. deshalb wurde die "stm32f4xx.h" nicht 
gefunden. Wie gesagt, ein ziemlich dummer Fehler.

Viele Grüße

[Klaus L. (keyel80)]

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

[Christopher Johnson (Gast)]

Servus Klaus,

vielen Dank für deine ausführliche Anleitung. Insbesondere der Hinweis 
wie man den Code aus dem STM32CubeMX importiert hat mir sehr 
weitergeholfen.

Die komplette Toolchain lief bei mir bereits problemlos unter Linux und 
Windows aber ich wollte natürlich auch gerne mal mit dem 
Klickibunti-Konfiguratordingens herumexperimentieren ;)
Das einzige was mich noch ein bisschen stört ist die dämliche Lizenz von 
dem Linkerscript aber vielleicht findet sich da ja noch eine 
Alternative.

Für den Fall, das jemand nach der Anleitung ein STM32Cube Projekt 
importieren will und nicht die ganzen Standard-Include-Pfade von Hand 
eingeben möchte habe ich mal eine XML-Datei angehängt, welche die 
Includes und Defines beinhaltet. Die muss man dann nur importieren 
(einmal für Debug und einmal Release).

Noch ein paar kleine Anmerkungen:

Statt die ganzen stm32-header von Hand auszuschließen, kann man die, die 
man nicht braucht ja auch einfach löschen. Ich verstehe sowieso nicht 
warum die mit erzeugt werden wo sie doch nicht gebraucht werden.

Was die Assembler-Endung angeht, da funktioniert unter Linux auch die 
Standard-Endung .S ganz prima (mit großem S). Soweit ich das sehe frisst 
das auch Windows ohne mucken.

Alles in allem weiß ich nicht so recht wie begeistert ich jetzt von dem 
gnuarmeclipse-plugin bin. Auf der einen Seite erlaubt es sehr sinnvolle 
Einstellmöglichkeiten wie Projektbezogene PATH-Variablen und das mit dem 
Debugging ist auch erste Sahne aber auf der anderen Seite macht es das 
Build-System ein bisschen konfus.

Gespannt bin ich mal auf die zukünftige kompatibilität mit CMSIS-Packs. 
Sieht auf jeden Fall schonmal sehr vielversprechend aus. Da hat der gute 
Livius auf jeden Fall großes vor ;)

Für die, die mit dem STM32F4-Discovery und STM32CubeMX die ersten 
gehversuche starten wollen kann ich dann noch das Pinout von hier 
empfehlen: http://www.espruino.com/ReferenceSTM32F4DISCOVERY
Das hat ST leider nicht hinbekommen das noch zu integrieren.

[Friedrich S. (fseuhs)]

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

[Klaus L. (keyel80)]

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

[Friedrich S. (fseuhs)]

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.

???

[Klaus L. (keyel80)]

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

[Friedrich S. (fseuhs)]

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

[Friedrich S. (fseuhs)]

Hallo Klaus,

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

[Stefan (Gast)]

Hallo,

ich kann Klaus' Beschreibung zur Installation der Entwicklungsumgebung 
nicht mehr aufrufen. Der Blog-Eintrag scheint gelöscht worden zu sein. 
Hat jemand die Seite gespeichert und kann sie mir zur Verfügung stellen?

Vielen Dank,
Stefan

[Klaus L. (keyel80)]

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

[Martin (Gast)]

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

[Klaus L. (keyel80)]

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

[deep d. (deepdiver99)]

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

[greg (Gast)]

Ich hab mal spaßeshalber GNU ARM Eclipse ausprobiert. Sonst habe ich 
bisher mein eigenes Setup basierend auf Makefiles verwendet. Irgendwie 
kann ich das Ding nicht dazu bewegen, mein Makefile zu benutzen, das 
möchte immer sein eigenes Buildsystem nutzen. Wenn ich dagegen ein 
"normales" CDT-Projekt nutze, klappt es mit dem eigenen Makefile. Dann 
funktioniert die OpenOCD-Integration für das Debugging aber nicht. 
Irgendeine Idee?

PS: wenn man Eclipse nicht verwenden will, dann geht Nemiver ganz gut 
als grafischer Standalone-Debugger.

[Tobi Z. (amadozard)]

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?

[ChrisG_Cornwall_UK (Gast)]

Apologies for a reply in English but I though I would supply my fix to 
"Updater is already in use".

It happens when I use the standalone STM32CubeMX then go back to using 
the Eclipse plugin. Disable all network connections. Restart Eclipse. 
Somehow the Updater state is set and needs no connection to reset it.

I hope it helps.

Google Translate below: (Please correct)
Wir entschuldigen uns für eine Antwort in Englisch, aber ich dachte, ich 
würde mein fix auf "" Updater wird bereits verwendet " zu liefern.

Es passiert, wenn ich den Standalone- STM32CubeMX dann gehen Sie zurück 
zur Verwendung der Eclipse-Plugin . Deaktivieren Sie alle 
Netzwerkverbindungen. Starten von Eclipse . Es erscheint der Updater 
Linkslauf und benötigt keine Verbindung , es zu töten .

Ich hoffe, es hilft.

[Hans Zimmer (Gast)]

@ChrisG thanks taht worked. there was an Proxy setting in the tool maby 
the problem @ the first start.

Hatte mit dem Projekt dann doch noch ein paar Probleme

und zwar doppelte definition der hal funktionen einmal war schon eine 
stm32f4_hal_msp.c im Ordner mit der Main vorhanden und noch mal 
stm32f4xx_hal_msp_template.c unter driver die ich dann erstmal excluded 
habe mit dem header file dazu.

Danach hatte ich leider dann ein Problem mit dem Linker:

Building file: 
../Drivers/CMSIS/Device/ST/STM32F4xx/Source/Templates/system_stm32f4xx.c
Invoking: Cross ARM C Compiler
arm-none-eabi-gcc -mcpu=cortex-r4 -mthumb -mfloat-abi=softfp 
-mfpu=fpv4-sp-d16 -O0 -fmessage-length=0 -fsigned-char 
-ffunction-sections -fdata-sections  -g3 -DUSE_HAL_DRIVER -DSTM32F407xx 
-I"C:/Users/Hans/workspace/F4Discovery/Drivers/CMSIS/Device/ST/STM32F4xx 
/Include"  -I"C:/Users/Hans/workspace/F4Discovery/Drivers/CMSIS/Include" 
-I"C:/Users/Hans/workspace/F4Discovery/Drivers/STM32F4xx_HAL_Driver/Inc" 
-I"C:/Users/Hans/workspace/F4Discovery/Inc" -std=gnu11 -MMD -MP 
-MF"Drivers/CMSIS/Device/ST/STM32F4xx/Source/Templates/system_stm32f4xx. 
d" 
-MT"Drivers/CMSIS/Device/ST/STM32F4xx/Source/Templates/system_stm32f4xx. 
o"  -c -o 
"Drivers/CMSIS/Device/ST/STM32F4xx/Source/Templates/system_stm32f4xx.o" 
"../Drivers/CMSIS/Device/ST/STM32F4xx/Source/Templates/system_stm32f4xx. 
c"
Finished building: 
../Drivers/CMSIS/Device/ST/STM32F4xx/Source/Templates/system_stm32f4xx.c

Building target: F4Discovery.elf
Invoking: Cross ARM C++ Linker
arm-none-eabi-g++ -mcpu=cortex-r4 -mthumb -mfloat-abi=softfp 
-mfpu=fpv4-sp-d16 -O0 -fmessage-length=0 -fsigned-char 
-ffunction-sections -fdata-sections  -g3 -T 
"C:\Users\Hans\workspace\F4Discovery\Projects\TrueSTUDIO\F4Discovery 
Configuration\STM32F407VG_FLASH.ld" -Xlinker --gc-sections 
-Wl,-Map,"F4Discovery.map" -o "F4Discovery.elf"  ./Src/main.o 
./Src/stm32f4xx_hal_msp.o ./Src/stm32f4xx_it.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_adc.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_adc_ex.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_can.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_cortex.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_crc.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_cryp.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_cryp_ex.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_dac.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_dac_ex.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_dcmi.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_dma.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_dma2d.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_dma_ex.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_eth.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_flash.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_flash_ex.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_flash_ramfunc.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_gpio.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_hash.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_hash_ex.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_hcd.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_i2c.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_i2c_ex.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_i2s.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_i2s_ex.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_irda.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_iwdg.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_ltdc.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_nand.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_nor.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_pccard.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_pcd.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_pcd_ex.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_pwr.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_pwr_ex.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_rcc.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_rcc_ex.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_rng.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_rtc.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_rtc_ex.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_sai.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_sd.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_sdram.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_smartcard.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_spi.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_sram.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_tim.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_tim_ex.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_uart.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_usart.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_wwdg.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_ll_fmc.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_ll_fsmc.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_ll_sdmmc.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_ll_usb.o 
./Drivers/CMSIS/Device/ST/STM32F4xx/Source/Templates/gcc/startup_stm32f4 
07xx.o 
./Drivers/CMSIS/Device/ST/STM32F4xx/Source/Templates/system_stm32f4xx.o
c:/program files (x86)/gnu tools arm embedded/4.9 
2014q4/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ 
ld.exe:  error: 
./Drivers/CMSIS/Device/ST/STM32F4xx/Source/Templates/gcc/startup_stm32f4 
07xx.o:  Conflicting architecture profiles M/R
c:/program files (x86)/gnu tools arm embedded/4.9 
2014q4/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ 
ld.exe:  failed to merge target specific data of file 
./Drivers/CMSIS/Device/ST/STM32F4xx/Source/Templates/gcc/startup_stm32f4 
07xx.o
collect2.exe: error: ld returned 1 exit status
make: *** [F4Discovery.elf] Error 1

hier sitze ich etwas auf dem Trockenen und weiss nicht so recht woran es 
liegt.

btw. mit der Toolchain sollte eigentlich auch ein Build mit Hardware FPU 
gehen. witzigerweise klappt das bei diesem Prejekt nicht.

[Hans Zimmer (Gast)]

ok Problem solved habe es noch mal neu angelegt und habe da jetzt auch 
die option C linker statt c++

[T. F. (sar)]

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

[Martin l. (Gast)]

Auch von mir Danke für das Tutorial.
Leider hatte ich nicht so viel erfolg. Habs mehrmals probiert, aber es 
kommen beim compilieren immer eine Menge Fehler

'uint16_t' undeclared here (not in a function)  arm_common_tables.h  /Test1/Drivers/CMSIS/Include  line 90  C/C++ Problem
...

Das Problem scheint etwas mit der folgenden Zeile zu tun zu haben 
(dieser error wird jedenfalls ausgegeben):
#error "Define according the used Cortex core ARM_MATH_CM7, 
ARM_MATH_CM4, ARM_MATH_CM3, ARM_MATH_CM0PLUS or ARM_MATH_CM0"

Hab ich irgendwo eine falsche Einstellung? Den Prozessortyp (cortex-m4) 
habe ich laut Anleitung eingestellt.

[T. F. (sar)]

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

[Hans W. (schnuckibaer)]

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).

[T. F. (sar)]

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

[Jonas W. (Gast)]

Hallo,

ersteinmal vielen Dank für das Tutorial.

Trotzdem habe ich noch ein Problem.
Zuerst bereitete wie bei Martin I. die arm_math.h Probleme. Durch 
hinzufügen von ARM_MATH_CM4 und __FPU_PRESENT als Symbole konnte das 
Problem beseitigt werden und er kompiliert alle Dateien ohne Warning und 
Error durch.

Allerdings besteht weiterhin ein Problem beim Linken.
Hier schreibt die Console:

Invoking: Cross ARM C Linker
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 -T "D:\stm32tc\kl_tut_01\TrueSTUDIO\kl_tut_01_Configuration\STM32F407VG_FLASH.ld" -Xlinker --gc-sections -Wl,-Map,"kl_tut_01.map" -o "kl_tut_01.elf"  

...

      0 [main] sh 1652 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
    190 [main] sh 1652 open_stackdumpfile: Dumping stack trace to sh.exe.stackdump
make: *** [kl_tut_01.elf] Error 101120

Die geladenen Objekt files habe ich der Übersichtlichkeit durch die drei 
Punkte ersetzt.

Hatte jemand ein ähnliches Problem, oder einen Lösungsansatz parat?

Viele Grüße

Jonas

[Hans W. (schnuckibaer)]

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

[Peter S. (psavr)]

Interessante Alternative: System Workbench for STM32

http://www.openstm32.org/HomePage

[eclipse (Gast)]

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

[Klaus L. (keyel80)]

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

[Jens E. (surfjenser)]

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.

[eclipse (Gast)]

Perfekt Danke, habs hinbekommen. Die content assist "auto activation" 
funktionen für c/c++ sind leider sehr beschränkt.

grüße

[Sebastian__ (Gast)]

Hallo,
ich habe ein kleines Problem.
Grundsätzlich scheint meine Toolchain mit dem OpenOCD 0.9.0 zu laufen, 
also debug, upload compilieren usw.
Ich benutzte die CubeMX Version 1.4, aber sobald die DSP Libs im mit im 
HAL sind, hagelt es beim Compilieren Fehlermeldungen.

konkret geht es um den Ordner:

C:\stm32ws\CubeRepo\STM32Cube_FW_F4_V1.4.0\Drivers\CMSIS\DSP_Lib\Source

wahrscheinlich kommt das Problem von hier: TransformFunctions
aber so richtig kann ich das nicht eingrenzen.

Kann das eventuell mal jemand testen ;)

MfG
Sebastian

[Max (Gast)]

Hallo zusammen,

zunächst einmal vielen Dank für das umfangreiche Tutorial. Genau soetwas 
hatte ich gesucht. Ich bin STM32-Neuling und komme vom Arduino.

Um den Toolchain zu installieren habe ich das Tutorial jetzt ein paar 
mal durchexerziert, bekomme es aber nicht zum laufen. Vermutlich ist es 
nur ein kleiner Fehler, aber ich komme einfach nicht dahinter. Nach 
drücken des "Hammer-Symbols" erscheint folgende Fehlermeldung:
" Error: Program "make" not found in PATH
PATH=[C:\stm32tc\gcc49\bin;$(eclipse_home)\GnuWin32\bin]"

Im bin-Ordner des GnuWin32 ist eine "make"-Datei vorhanden, im gcc49\bin 
allerdings nicht. Habe ich vegessen irgendetwas zu installieren?

Im Anhang habe ich noch ein paar screenshots um den Status zu erläutern.

Wie kann ich den Fehler eingrenzen?

Danke im Voraus

Max

[Klaus L. (keyel80)]

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

vg Klaus

[Max (Gast)]

Hallo Klaus,

Danke für die schnelle Antwort.

Ich bin nochmal alles durchgegangen und habe in STM32CubeMX und in 
Eclipse nochmal ein neues Projekt nach Deiner Anleitung erzeugt. Es 
kommt immer die gleiche Fehlermeldung.

Es klingt vermutlich ernüchternd, aber wo finde ich in Eclipse die 
Komandoziele?. In der Console kann ich nichts eingeben (Auch in der 
Eclipse-Anleitung bin ich nicht fündig geworden).
Es scheint doch um einiges aufwändiger zu sein als bei den Arduinos.

Danke

Max

[Klaus W. (mfgkw)]

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).

[Klaus L. (keyel80)]

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

[Max (Gast)]

Hallo Klaus Wachtler,

Deinen Vorschlag mit dem anderen Pfad hatte ich auch schon ausprobiert.
In KLaus L's Tutorial sind ja beide Versionen aufgeführt. Dein Vorschlag 
steht im Text, allerdings ohne "..\bin" am Ende.

"  In Eclipse -->Windows -->Preferences -->Build -->Environment: Bitte 
der Variable >>PATH<< den Wert c:\stm32tc\GnuWin32 hinzufügen. So kann 
Eclipse das Tool „make“ und „make“ wiederum die Tools „rm“ und „echo“ 
finden.  "

Es kommt eine andere Fehlermeldung --> siehe screenshot


Trotzdem danke für den Tip

Max

[Max (Gast)]

Hallo Klaus L.

nach dem Aufruf von "make" in der Komandozeile wird dieser nicht 
gefunden.

Ich habe zwei screenshots dazu angehängt (Komandozeile und bin-Ordner).

Kann es evtl. mit dem Coreutils zusammenhängen, es ist ja auch dort 
installiert?
In dem GnuWin32-Ordner sind die Versionen make-3.81 und coreutils-5.3.0 
installiert.

Max

[Max (Gast)]

und noch der Anhang

max

[Klaus L. (keyel80)]

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.

[Max (Gast)]

Hallo Klaus,

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

Könnte es sein, dass ich Make unter GnuWin32 falsch installiert habe?

Max

[Klaus L. (keyel80)]

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?

[Steffen R. (steffen_rose)]

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 (Gast)]

Hallo zusammen,

Steffen schrieb
"Dann schon eher ein falsches make. Aber das
sollte ja einfach auf dem System zu finden und auszuschließen sein."

Ich habe mein c-Laufwerk nach "make" durchsucht und ein Weiteres unter 
AtmelStudio gefunden (Oktober 2014). Das "make" unter 
C:\stm32tc\GnuWin32\bin hat ein Änderungsdatum von November 2006 -> Kann 
gar nicht sein! Was ist denn hier schiefgelaufen?

Ich könnte AtmelStudio einfach deinstallieren oder bringt das nichts?


Probehalber habe ich nocheinmal das alte Projekt gelöscht, ein neues 
Projekt in Cube MX und elipse erstellt und alles nach Anleitung 
konfiguriert --> wieder der gleiche Fehler.

Max

[bastler (Gast)]

probier mal eclipse als administrator zu starten... ich hab lange 
gesucht, bis ich gemerkt habe, dass das compilat nicht gelöst werden 
kann... und desshalb programmänderungen nicht wirksam waren... doofer 
fehler aber ja so wars halt...


gz bastler

[Steffen R. (steffen_rose)]

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.

[Maximilian S. (00maxi)]

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

[Bernd K. (prof7bit)]

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.

[Steffen R. (steffen_rose)]

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.

[Maximilian S. (00maxi)]

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?

[Steffen R. (steffen_rose)]

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.

[Micha (Gast)]

Eclipse kann übrigens auch sowas:
$(eclipse_home)\..\GnuWin32\bin
Damit kann man etwas mehr Ordnung halten und einzelne Teile besser 
aktualisieren, wie ich finde.

[Maximilian S. (00maxi)]

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

[Steffen R. (steffen_rose)]

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?

[Micha (Gast)]

Steffen Rose schrieb:
> Micha:
>> $(eclipse_home)\..\GnuWin32\bin
> Maximilian scheint die Eclipse Umgebung an eine andere Stelle
> installiert zu haben?
So wie das unter 
Beitrag "Re: STM32-Toolchain mit Eclipse CDT 4.3, GnuArmEclipse, OpenOCD 0.8.0, Gnu Arm GCC 4.8, STM32CubeMX" aussieht 
hat er sich an das Tutorial gehalten und alle weiteren Tools ins 
eigentliche Eclipse-Verzeichnis gepackt.

[Maximilian S. (00maxi)]

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

[Steffen R. (steffen_rose)]

@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.

[Maximilian S. (00maxi)]

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

[Micha (Gast)]

Habt ihr euch egtl. mal die einzelnen Anleitungen unter 
http://gnuarmeclipse.livius.net/blog/install/ angesehen? Die haben mir 
seinerzeit geholfen.

[Maximilian S. (00maxi)]

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

[Maximilian S. (00maxi)]

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)

[Steffen R. (steffen_rose)]

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

[Bernd K. (prof7bit)]

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/

[Maximilian S. (00maxi)]

@ 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

[Maximilian S. (00maxi)]

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

[Bernd K. (prof7bit)]

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).

[Maximilian S. (00maxi)]

@ 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

[Maximilian S. (00maxi)]

hier der Anhang

[Maximilian S. (00maxi)]

@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"
    ^

[Maximilian S. (00maxi)]

screenshot

[Bernd K. (prof7bit)]

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:

/**
 * @defgroup groupExamples Examples
 */
#ifndef _ARM_MATH_H
#define _ARM_MATH_H

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

#if defined(ARM_MATH_CM7)
  #include "core_cm7.h"
#elif defined (ARM_MATH_CM4)
  #include "core_cm4.h"
#elif defined (ARM_MATH_CM3)
  #include "core_cm3.h"
#elif defined (ARM_MATH_CM0)
  #include "core_cm0.h"
#define ARM_MATH_CM0_FAMILY
  #elif defined (ARM_MATH_CM0PLUS)
#include "core_cm0plus.h"
  #define ARM_MATH_CM0_FAMILY
#else
  #error "Define according the used Cortex core ARM_MATH_CM7, ARM_MATH_CM4, ARM_MATH_CM3, ARM_MATH_CM0PLUS or ARM_MATH_CM0"
#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.

[Maximilian S. (00maxi)]

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 (Gast)]

beim starten von eclipse rechtsklick drauf und als administrator 
ausführen wählen wie ich schon gesagt habe, es spielt keine rolle, dass 
dein benutzer zur gruppe adminisratoren gehört... aber so funktionierts 
bei mir, wenn ich eclipse unter dem benutzer laufen lasse, gehts nicht. 
Das mit dem benutzer ist admin spielt nur insofern eine rolle, dass du 
programme dann als admin ausführen kannst, ohne zuerst ein passwort 
eingeben zu müssen.....


gruss

[Maximilian S. (00maxi)]

@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

[Bernd K. (prof7bit)]

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.

[Micha (Gast)]

Möglicherweise darfst du als Nicht-Admin nicht einfach in einem 
C-Unterordner rumbasteln. Wirf mal den ganzen Krams in deinen 
User-Ordner oder auf den Desktop und versuch es nochmal von dort aus.

[Maximilian S. (00maxi)]

@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)
'

[Bernd K. (prof7bit)]

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.

[Steffen R. (steffen_rose)]

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

[Steffen R. (steffen_rose)]

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.

[Steffen R. (steffen_rose)]

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.

[Steffen R. (steffen_rose)]

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.

[Steffen R. (steffen_rose)]

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?

[Steffen R. (steffen_rose)]

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.

[Steffen R. (steffen_rose)]

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.

[Kai (Gast)]

Hallo,

beim Linken des kl_tut_01 bekomme ich folgenden Fehler:


arm-none-eabi-gcc: error: 
./Drivers/CMSIS/DSP_Lib/Source/StatisticsFunctions/arm_min_f32o: No such 
file or directory
arm-none-eabi-gcc: error: 
./Drivers/CMSIS/DSP_Lib/Source/FilterngFunctions/arm_fir_q7.o: No such 
file or directory
arm-none-eabi-gcc: error: 
./Drivers/CMIS/DSP_Lib/Examples/arm_fft_bin_example/GCC/arm_fft_bin_exam 
ple_f32.o:  No such file or directory
make: *** [kl_tut_01.elf] Fehler 1

Woran kann das liegen?

[Gabriel E. (borg316)]

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!

[kai (Gast)]

Kai schrieb:

> arm-none-eabi-gcc: error:
> ./Drivers/CMIS/DSP_Lib/Examples/arm_fft_bin_example/GCC/arm_fft_bin_exam 
ple_f32.o:
> No such file or directory
> make: *** [kl_tut_01.elf] Fehler 1

Kann mir jemand einene Tipp geben? Ich weiß einfach nicht wo das Problem 
liegt.

[Steffen R. (steffen_rose)]

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.

[Steffen R. (steffen_rose)]

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

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

[Maximilian S. (00maxi)]

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

[Steffen R. (steffen_rose)]

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

[Micha (Gast)]

Steffen Rose schrieb:
> 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.
Was meinst du damit?

[Maximilian S. (00maxi)]

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

[Steffen R. (steffen_rose)]

@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.

[Bernd K. (prof7bit)]

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.

[Maximilian S. (00maxi)]

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

[Bernd K. (prof7bit)]

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 (Gast)]

Steffen Rose schrieb:
> 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.

Das C-File wurde übersetzt, ohne Error. 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.

Wenn ich clean ausführe bekomme ich folgenden Output:
21:35:49 **** Clean-only build of configuration Debug for project 
kl_tut_01 ****
make clean
rm -rf  ./Src/main.o ./Src/stm32f4xx_hal_msp.o ./Src/stm32f4xx_it.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_adc.o 
./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_adc_ex.o ....
.
.
.
.
make (e=87): Falscher Parameter.

make: [clean] Fehler 87 (ignoriert)
' '

21:35:53 Build Finished (took 4s.531ms)

[Steffen R. (steffen_rose)]

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 (Gast)]

Steffen Rose schrieb:
> Merkwürdigerweise ist dies bei ihm aber nicht global bei Eclipse
> hinterlegt, sondern eine Projekteinstellung. Diese war bei einem neuen
> Projekt wieder weg.
Wenn ich nicht irre ist das aber im GNU-ARM-Eclipse-plugin ausdrücklich 
so gewünscht, so dass man verschiedene Projekte mit verschiedenen 
Compilerversionen vorhalten kann. Man will ja für ältere Software 
möglicherweise beim ursprünglichen Compiler bleiben um sich nichts neues 
einzufangen.

[Steffen R. (steffen_rose)]

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

OK. Danke.

[Kai (Gast)]

Steffen Rose schrieb:
> 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.

Ich weiß warum der Linker Fehler bringt, als Beispiel die erste Datei. 
Der Linker meldet: 
./Drivers/CMSIS/DSP_Lib/Source/StaisticsFunctions/arm_min_q15.o: No such 
file or Directory

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. Die o-Dateien, die der 
Linker nicht findet existieren alle. Im Logfile habe ich auch gesehen, 
dass sie korrekt erstellt wurden.
Wo kann ich diese Pfade modifizieren.

FPU habe ich deaktiviert.

[Bernd K. (prof7bit)]

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.

[Kai (Gast)]

Anbei das makefile.

[Maximilian S. (00maxi)]

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 (Gast)]

Bernd K. schrieb:
> 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.

Kann mir jemand sagen warum der Linker den Pfad StaisticsFunctions 
verwendet? Makefile habe ich hochgeladen, weiter oben in diesem Thread.

[Steffen R. (steffen_rose)]

@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

[STMF103 (Gast)]

Hallo, danke für das klasse Toturial habe somit mein stmf4discovery 
board super zum laufen bekommen,

jetzt möchte ich jedoch einen STM32F103C8T6 programieren.
kommt immer folgender Fehler

/test122/Drivers/CMSIS/Include/arm_math.h:4713:5: error: unknown type 
name 'uint16_t'

eingestellt als includes habe ich:

    ${ProjDirPath}/Drivers/CMSIS/Device/ST/STM32F1xx/Include
    ${ProjDirPath}/Drivers/CMSIS/Include
    ${ProjDirPath}/Drivers/STM32F1xx_HAL_Driver/Inc
    ${ProjDirPath}/Inc

habe alle Include files bis auf

   stm32f103x6.h
   stm32f1xx.h
   system_stm32f1xx.h

deaktiviert

Als Symbole sind Definiert
USE_HAL_DRIVER
STM32F103x6

kann mir hier jemand helfen ?

Grüße Lukas

[Klaus W. (mfgkw)]

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

Ist in dem Quelltext stdint.h #includet?

[holger (Gast)]

>/test122/Drivers/CMSIS/Include/arm_math.h:4713:5: error: unknown type
>name 'uint16_t'

Da fehlt ein

#include <stdint.h>

[STMF103 (Gast)]

Das mit #include <stdint.h> hatte ich mir auch gedacht, habe es in die 
main.c mit reingenommen. Bewirkt leider garnichts. Sowohl vor als wie 
auch nach den anderen includes...

[Klaus W. (mfgkw)]

und beim Kompilieren welcher C-Datei wird das angemeckert?

[STMF103 (Gast)]

Der fehler ist in arm_math.h beim Builden des ganzen Projekts

/test122/Drivers/CMSIS/Include/arm_math.h:4713:5: error: unknown type
name 'uint16_t'

füge ich in arm_math.h das include stdint.h hinzu kommt folgender Fehler

/ARM/arm_class_marks_example_f32.o
arm-none-eabi-gcc: error: 
./Divers/CMSIS/DSP_Lib/Source/MatrixFunctions/arm_mat_cmplx_mult_f32.o: 
No such file or directory
arm-none-eabi-gcc: error: 
./Drivers/CMSIS/DSP_Lib/Source/FilteringFunctions/arm_lm_init_q15.o: No 
such file or directory
make: *** [test122.elf] Fehler 1

grüße

[STMF103 (Gast)]

Hab den Fehler gefunden... sau dämlich hatte im STM CUBE vergessen den 
Haken bei "Copy only the necessary library files" zu setzen

danke euch für die Hilfe

[Duten (Gast)]

STMF103 schrieb:
> Der fehler ist in arm_math.h beim Builden des ganzen Projekts
>
> /test122/Drivers/CMSIS/Include/arm_math.h:4713:5: error: unknown type
> name 'uint16_t'

Ich bin damit auch gerade zugange, habe auch zuviel ins Projekt kopiert, 
das lässt sich per -D ARM_MATH_CM3 (Je nach Cortex Typ) fixen. Werde 
aber das Projekt gleich noch mal neu erstellen, das 8KB Problem ist für 
2015 ziemlich unglaublich: 
http://mcuoneclipse.com/2015/03/29/solving-the-8192-character-command-line-limit-on-windows/

Hatte mir eingentlich extra eine Windows VM aufgesetzt um sklavisch das 
Tutorial abzuarbeiten um in keine anderen Fehler unter Linux zu laufen. 
Aber das Profi OS Windows hält auch immer wieder Überraschungen bereit.