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
:
Verschoben durch User
Vielen Dank für deine Mühe und die gute Anleitung. Kannst du erklären, wie man die FPU mit dieser Toolchain nutzen kann?
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
Danke für die Antwort. Das war genau was ich wissen/sehen wollte. Mach weiter so!
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
:
Bearbeitet durch User
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 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?
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 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
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
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.
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, 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
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 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
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
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.
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?
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.
@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.
ok Problem solved habe es noch mal neu angelegt und habe da jetzt auch die option C linker statt c++
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
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
1 | 'uint16_t' undeclared here (not in a function) arm_common_tables.h /Test1/Drivers/CMSIS/Include line 90 C/C++ Problem |
2 | ...
|
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.
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
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:
1 | Invoking: Cross ARM C Linker |
2 | 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" |
3 | |
4 | ...
|
5 | |
6 | 0 [main] sh 1652 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION |
7 | 190 [main] sh 1652 open_stackdumpfile: Dumping stack trace to sh.exe.stackdump |
8 | 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
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
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
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.
Perfekt Danke, habs hinbekommen. Die content assist "auto activation" funktionen für c/c++ sind leider sehr beschränkt. grüße
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:
1 | 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
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
Hallo Max, kannst Du "make" auf der Kommandozeile aufrufen? vg Klaus
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
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
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
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
und noch der Anhang max
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.
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
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?
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
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
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.
:
Bearbeitet durch User
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.
Eclipse kann übrigens auch sowas: $(eclipse_home)\..\GnuWin32\bin Damit kann man etwas mehr Ordnung halten und einzelne Teile besser aktualisieren, wie ich finde.
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?
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.
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
Habt ihr euch egtl. mal die einzelnen Anleitungen unter http://gnuarmeclipse.livius.net/blog/install/ angesehen? Die haben mir seinerzeit geholfen.
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
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
@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.
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.
@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, 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?
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 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.
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: > 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?
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.
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)
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.
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 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.
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.
Anbei 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
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.
@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
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
was du weggelassen hast, ist nicht so spannend. Eher, was du nicht wegelassen hast :-) Ist in dem Quelltext stdint.h #includet?
>/test122/Drivers/CMSIS/Include/arm_math.h:4713:5: error: unknown type >name 'uint16_t' Da fehlt ein #include <stdint.h>
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...
und beim Kompilieren welcher C-Datei wird das angemeckert?
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
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
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.