Hallo, Ich habe ein Problem, nach langem erfolglosem probieren .. Ich habe nach nach dieser Anleitung http://www.mikrocontroller.net/articles/STM32F4-Discovery erfolgreich * Sourcery Toolchain * CDT, ARM, GDB plug ins installiert * Stlink devices erscheint beim einstecken des Boards und ich kann auch darauf schriben bzw lesen Probleme habe ich mit Eclipse!! Zum Thema Beispiel-Projekte sollte ein Neues Projekt angelegt werden. Zum einem finde ich keine *ARM Linux GCC (Sourcery G++ Lite)* sondern stattdessen *ARM Linux GCC (Sourcery Lite Linux)* oder *ARM Linux GCC (Sourcery Bare)* vor .. ich hoffe das ist kein problem Desweiteren sollten die drei includes vorhanden sein, das ist bei mir nich so! /opt/CodeSourcery/arm-2011.09/arm-none-eabi/include /opt/CodeSourcery/arm-2011.09/lib/gcc/arm-none-eabi/4.6.1/include /opt/CodeSourcery/arm-2011.09/lib/gcc/arm-none-eabi/4.6.1/include-fixed ich habe aber die die PATH gesetzt ... in der console finde ich arm-none-eabi-gcc und co (mit dem selben user, mit dem eclipse gestartet wird) .... nun ich habe dies alles erstmal ignoriert und am ende erhalte ich den fehler das arm-gnu-linux-eabi-gcc (oder so ähnlich .. ich bin mir nicht mehr sicher wie sich das nannte, da ich im eclipse alle einträge arm-gnu-linux-eabi-gcc zu arm-none-eabi-gcc gerändert habe) nicht gefunden werden kann
**** Build of configuration Debug for project stm32l1xx_template_test1 **** make all Building file: ../test/main.c Invoking: ARM Linux GCC C Compiler (Sourcery Lite Linux) arm-none-eabi-gcc -DUSE_STDPERIPH_DRIVER -DUSE_STM32_DISCOVERY -D"HSE_VALUE Value=8000000" -I/opt/STM32L1xx_StdPeriph_Lib_V1.2.0/Libraries/CMSIS/Include/ -I/opt/STM32L1xx_StdPeriph_Lib_V1.2.0/Libraries/CMSIS/Device/ST/STM32L1x x/Include -I/opt/STM32L1xx_StdPeriph_Lib_V1.2.0/Libraries/STM32L1xx_StdPeriph_Driv er/inc/ -I"../ //home/rendeb/workspace/stm32l1xx_template_test1" -O0 -ffunction-sections -fdata-sections -Wall -Wa,-adhlns="test/main.o.lst" -c -fmessage-length=0 -MMD -MP -MF"test/main.d" -MT"test/main.d" -mcpu=cortex-m3 -mthumb -g3 -o "test/main.o" "../test/main.c" /bin/sh: 1: arm-none-eabi-gcc: not found make: *** [test/main.o] Error 127 **** Build Finished ****
So jetzt habe ich ein anderes Problem und zwar beim compilieren eines example-programms erhalte ich folgende meldung: **** Build of configuration Debug for project t **** make all Building file: /opt/STM32L1xx_StdPeriph_Lib_V1.2.0/Libraries/STM32L1xx_StdPeriph_Driver /src/misc.c /bin/sh: 1: arm-none-eabi-gcc: not found Invoking: ARM Linux GCC C Compiler (Sourcery Lite Linux) make: *** [StdPeriph/misc.o] Error 127 arm-none-eabi-gcc -DUSE_STDPERIPH_DRIVER -DUSE_STM32_DISCOVERY -DHSE_VALUE=8000000 -I/opt/CodeSourcery/arm-2011.09/arm-none-eabi/include -I/opt/CodeSourcery/arm-2011.09/lib/gcc/arm-none-eabi/4.6.1/include -I/opt/CodeSourcery/arm-2011.09/lib/gcc/arm-none-eabi/4.6.1/include-fixe d -I/opt/STM32L1xx_StdPeriph_Lib_V1.2.0/Libraries/CMSIS/Include -I/opt/STM32L1xx_StdPeriph_Lib_V1.2.0/Libraries/CMSIS/Device/ST/STM32L1x x/Include -I/opt/STM32L1xx_StdPeriph_Lib_V1.2.0/Libraries/STM32L1xx_StdPeriph_Driv er/inc -O0 -ffunction-sections -fdata-sections -Wall -Wa,-adhlns="StdPeriph/misc.o.lst" -c -fmessage-length=0 -MMD -MP -MF"StdPeriph/misc.d" -MT"StdPeriph/misc.d" -mcpu=cortex-m3 -mthumb -g3 -o "StdPeriph/misc.o" "/opt/STM32L1xx_StdPeriph_Lib_V1.2.0/Libraries/STM32L1xx_StdPeriph_Drive r/src/misc.c" **** Build Finished ****
PATH stimmt nicht, denn
> /bin/sh: 1: arm-none-eabi-gcc: not found
heisst, dass er das Binary nicht gefunden hat. Kannst Du es an der
Konsole ausführen (z.B. "arm-none-eabi-gcc -v")?
Bei Eclipse kann man PATH in den Einstellungen (Preferences) umsetzen.
Da könnte also durchaus was verstellt sein.
>PATH stimmt nicht, denn > > /bin/sh: 1: arm-none-eabi-gcc: not found > >heisst, dass er das Binary nicht gefunden hat. Kannst Du es an der >Konsole ausführen (z.B. "arm-none-eabi-gcc -v")? arm-none-eabi-gcc -v ist erreichbar, ich hab die PATH Variable in .profiles meines user gesetzt mit dem ich elcipse starte. Folgendes hab ich in die Profile reingesetzt:
1 | EABI_PATH="/opt/gcc-arm-none-eabi" |
2 | if [ -d "$EABI_PATH/bin" ] ; then |
3 | PATH="$EABI_PATH/bin:$PATH" |
4 | fi
|
rendeb@rendeb-virt:~/Downloads$ arm-none-eabi-gcc -v Using built-in specs. COLLECT_GCC=arm-none-eabi-gcc COLLECT_LTO_WRAPPER=/opt/gcc-arm-none-eabi-4_7-2013q3/bin/../lib/gcc/arm -none-eabi/4.7.4/lto-wrapper Target: arm-none-eabi Configured with: /home/build/work/GCC-4-7-build/src/gcc/configure --target=arm-none-eabi --prefix=/home/build/work/GCC-4-7-build/install-native --libexecdir=/home/build/work/GCC-4-7-build/install-native/lib --infodir=/home/build/work/GCC-4-7-build/install-native/share/doc/gcc-ar m-none-eabi/info --mandir=/home/build/work/GCC-4-7-build/install-native/share/doc/gcc-arm -none-eabi/man --htmldir=/home/build/work/GCC-4-7-build/install-native/share/doc/gcc-ar m-none-eabi/html --pdfdir=/home/build/work/GCC-4-7-build/install-native/share/doc/gcc-arm -none-eabi/pdf --enable-languages=c,c++ --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib --with-headers=yes --with-python-dir=share/gcc-arm-none-eabi --with-sysroot=/home/build/work/GCC-4-7-build/install-native/arm-none-ea bi --build=i686-linux-gnu --host=i686-linux-gnu --with-gmp=/home/build/work/GCC-4-7-build/build-native/host-libs/usr --with-mpfr=/home/build/work/GCC-4-7-build/build-native/host-libs/usr --with-mpc=/home/build/work/GCC-4-7-build/build-native/host-libs/usr --with-ppl=/home/build/work/GCC-4-7-build/build-native/host-libs/usr --with-cloog=/home/build/work/GCC-4-7-build/build-native/host-libs/usr --with-libelf=/home/build/work/GCC-4-7-build/build-native/host-libs/usr --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-pkgversion='GNU Tools for ARM Embedded Processors' --with-multilib-list=armv6-m,armv7-m,armv7e-m,armv7-r Thread model: single gcc version 4.7.4 20130913 (release) [ARM/embedded-4_7-branch revision 202601] (GNU Tools for ARM Embedded Processors) Und Path ist: gcc version 4.7.4 20130913 (release) [ARM/embedded-4_7-branch revision 202601] (GNU Tools for ARM Embedded Processors) rendeb@rendeb-virt:~/Downloads$ echo $PATH /opt/gcc-arm-none-eabi/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games :/usr/games
Hallo Rene, ich habe gerade das gleiche Problem. Ich denke die HOWTO hier braucht ein update. Ich habe es jetzt soweit bekommen das ich einen link erstellen musste: ln -s /opt/CodeSourcery/arm-2011.09/bin/arm-none-eabi-gcc /usr/bin/arm-none-linux-gnueabi-gcc damit wird mir bei einem neuen projekt (ich wähle Sourcery Lite Linux). diese include dateien reinkopiert. allerdings scheitere ich dann beim kompilieren: make: *** [test.hex] Fehler 127 viel erfolg ;-)
Welche Linux Distros verwendet Ihr denn? die meisten neuen Distros haben den arm-none-eabi in den Packetquellen debian basiert zum Bsp. sudo apt-get install gcc-arm-none-eabi dann klappt das mit dem arm-eclipse plugin ohne Frickelei. Wenn Ihr wollt kann ich ein paar Templates fuer die Discovery's posten.
:
Bearbeitet durch User
Hallo Juergen, Ich nutze Debian wheezy 7.0.1, ich konnte leider nicht fetstellen das gcc-arm-none-eabi im Debian repo vorhanden ist.
dieses paket ist bei mi rnicht vorhanden, weder mit apt-get noch mit aptitude. liegt es etwas daran, das ich ein debian wheezy 64bit verwende?
Dann versuche es mal mit der alternativen Packet-Quelle.
"sudo add-apt-repository ppa:terry.guo/gcc-arm-embedded"
"sudo apt-get update"
"sudo apt-get install gcc-arm-none-eabi"
ich nutze Ubuntu. Die Pakete habe ich. werde es damit mal versuchen. was für templates meinst du?
also ich kann die toolchain zwar auch mit apt-get installieren. die bins sind dann unter /usr/bin und fangen mit: arm-none-eabi-* an. so lege ich jetzt ein neues C Projekt in Eclipse mit der Toolchain "Sourcery Lite Linux" an sucht er aber nach binarys die mit "arm-none-linux-gnueabi-*" anfangen, ergo funzt es natürlich wieder nicht!
ok projekt templates sicher? da hänge ich jetzt auch, die aktuelle version der Std. Libs von ST ist 1.2.0 die howto bezieht sich auf 1.0.0, da hat sich auch wieder einiges getan. durchkompilieren ist nicht drin mit den einstellungen die man dort erklärt werden. vielleicht kannst du uns doch deine templates schicken? (sofern diese auch schon für die 1.2.0 libs sind)
Verwendet Ihr alle die STM32L1xx Diesen Type habe ich noch nicht verwendet. Gebt mir mal ein paar Minuten, dann poste ich ein Template.
Koennt Ihr mir mal einen Link auf die von Euch verwendete StdLib posten. Auf der ST Page finde ich unter den STM32L1 nur aeltere Versionen als 1.2
Angehängte Dateien:
-
impProj.png
71 KB
Hier jetzt ein eclipse Projekt. Vorab, da ist nicht die von Euch gewollte StdPerphLib drin sondern eine fuer einen cm0. Das laesst sich aber ganz leicht aendern. Dazu aber weiter unten mehr. 1. Die Datei irgendow im Dateisystem ausserhalb des eclipse Workspaces entpacken. 2. eine Kopie davon in das eclipse Workspace Directorie machen und das Projekt-Directorie nach belieben umbenennen. Dann in eclipse 3. File->Import->General->existing project into workspace next unter "Select root Directory" den Projectordner auswaehlen (die Kopie im Eclipse Workspace" Das sollte dann so aussehen wie im Bild oben Finish Damit ist das Projekt im Workspace 4. Im Projekt Explorer den Ordner "Release" des aktuellen Projectes loeschen, damit keine Geister Dateien vom Original Projekt im aktuellen Projekt rumfliegen. 5. dann mit dem Hammer(Symbol) neu kompilieren. Aendern der verwendeten StdPerphLib Der Ordner Libraries ist der selbe Ordner mit selben Namen wie er innerhalb der von ST kommenden StdPerphLib zu finden ist. zBsp.: $DownloadOrdner/STM32F0-Discovery_FW_V1.0.0/Libraries Also den im Projekt befindlichen Ordner Libraries loeschen und durch den Ordner aus dem ST-Download ersetzen nochmal den Ordner Release loeschen und neu Kompilieren.
Hallo Jürgen, also die stdlib habe ich aus dem Link der im Artikel http://www.mikrocontroller.net/articles/STM32F4-Discovery#Eclipse_IDE ist und der geht da hin: http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1743/PF257901 Version 1.2.0 dein Template werde ich nachher mal ausprobieren und schauen ob es bei mir tut. danke erstmal. grüße
Angehängte Dateien:
-
stm.jpg
310 KB
Hallo Jürgen, ich habe jetzt dein template ausprobiert das kompliert auch soweit. du hast ja dem stm32f0 und ich den stm32f4. Habe also die StdLib von dir gelöscht, die für den f4 rein kopiert, die pfade unter den ProjectProperties angepasst, Release ordner gelöscht und mit Hammer neu kompiliert. leider ohne erfolg 200 error meldungen wegen fmc.. das kann doch nicht so schwierig sein mit eclipse unter linux einen stm32f4 zu programmieren grrrr
Asche auf mein Haupt. In den Original Quellen von ST sind auch Beispiele mit in dem Library Tree. Ob Beispiele in einen Lib Tree gehoeren oder nicht ist Ansichtssache in meinen Augen nicht, also habe ich die Beispiele aus dem Lib Tree von ST entfernt und verwende in meinen Projekten eine Kopie die nur das zu Begin Notwendigste enthaelt. Den Rest Kopiere ich dann bei Bedarf in das Projekt. Die USB Geschichten die da noch in dem ST Tree drin sind habe ich auch nicht in meinem Template Tree, die kann man je nach Bedarf aus den Original Quellen in sein Projekt kopieren. Im Anhang ein minimal Projekt fuer den F4.
kein problem :-) kompilieren tut jetzt soweit, jetzt nur noch programmieren und debuggen dann hab ichs geschaft :-D st-link hab ich installiert, gibts da auch die möglichkeit aus eclipse heraus den mc zu programmieren (nicht debuggen)
Angehängte Dateien:
-
ExtTootlConfig.png
18 KB -
ExtTootlConfig_menu.png
11 KB -
startOpenOCD.png
84 KB -
flash.png
89 KB -
reset.png
85 KB -
shutdown.png
86 KB -
bbl.png
68 KB
Ja geht beides, flashen und debuggen Die Dateien zum flashen findest Du in dem Ordner openocd im jeweiligen Projekt um das zu benutzten musst Du die Pakete openocd und libnet-telnet-perl installiert haben sudo apt-get install openocd libnet-telnet-perl danach dann in eclipse einige externe tools configurieren Schau Dir die Bilder oben an. Das sind die extern tool configs um OpenOCD zu starten den uC zu flashen einen Reset im uC zu veranlassen OpenOCD zu stoppen Stelle sicher das in allen Tools unter dem Reiter Build Build before launch deaktiviert ist. Wenn Du die tools eingerichtet hast kannst Du unter Organize Favorits die Tools in das Menu integrieren
:
Bearbeitet durch User
Fehler in der openocd.cfg fuer den STM32F4 muss die openocd.cfg so aussehen # # Flash programming script for stm32f4 discovery # Using the swd transport # source [find interface/stlink-v2.cfg] source [find target/stm32f4x_stlink.cfg]
:
Bearbeitet durch User
Noch was zum STLink auf den Discovery boards in dem Verzeichnis /etc/udev/rules.d/ muss die Datei XX-stlinkv2.rules vorhanden sein wenn nicht, die im Anhang befindlichen Dateien dahin Kopieren und sudo service udev restart aufrufen
Wow cool du bist ja ein eclipse Linux stm crack :-) Danke schon mal für deine !! werd es morgen mal testen. Wie ist das mit dem flash tools? du nutzt ja nicht st-flash, ist deine eingesetzte Variante besser wie die st-flash?
Es ist openocd, also eigentlich ein Debug-Tool. Damit kann man nicht nur flashen sondern auch gleich debuggen wenn mans braucht. Meiner Erfahrung nach ist es auch schneller als st-flash.
also das funktioniert (fast) soweit. mit dem flash gibt es noch ein problem irgendwie läuft es nicht aber ohne erkennbaren grund, außer das das programm nicht läuft. der ganze flash vorgang dauert auch nur 1-2 sek. so viel schneller kann das mit openocd ja auch nicht sein ;-) was mir auffällt: Info : device id = 0x10016413 Info : flash size = 1024kbytes flash 'stm32f2x' found at 0x08000000 auto erase enabled target state: halted target halted due to breakpoint, current mode: Thread xPSR: 0x61000000 pc: 0x20000042 msp: 0x4c06b510 wrote 16384 bytes from file /home/martin/eclipseworkspace/vorlage/Release/vorlage.bin in 0.994898s (16.082 KiB/s)
Ja und die letzte Zeile der Ausgabe ist Info : dropped 'telnet' connection das heisst alles ist OK und Dein Programm ist im Flash des uC's Was ist jetzt das Problem? Blinken die Led nicht?
nein blinken nicht, aber wenn du sagst die ausgabe sieht "normal" aus dann schaue ich mir lieber noch mal mein program an! vielleicht hab ich da etwas übersehen..
nimm einfach das Projekt fuer den F4 was ich oben gepostet habe, das ist das Standard blinky (IO_Toggle im Ordner Peripheral_Examples) aus der ST FirmwareLib fuer das F4-Discovery. bei mir blinken die vier Led auf dem F4-Discovery.
Ja das läuft, war also noch ein fehler im programm.. wenn ich jetzt noch das debugging hinbekommen würde :-) hab das mal konfiguriert so das er den arm gdb immt und sich auf den port 4444 von openocd verbindet. kommt aber nur ne cryprische fehlermeldung.. habs mal angehängt, vielleicht weißt du noch rat.. danke schon mal
ok habs hinbekommen, musste bei PORT den 3333 nehmen nicht 4444. geschaft :-)
Gratulation. Eclipse ist wie ein Schweizer Taschenmesser. Kann vieles, man muss sich aber damit befassen um es zu verstehen, erst dann kann man es richtig anwenden. Einfach drauflosklicken und hoffen es kommt was vernuenftiges dabei raus is bei eclipse nich.
Vielen Dank für die Bereitstellung des Beispiels mit der 1.0er Bibliothek. Ich habe es mit der 1.2er auch nicht geschafft, die FMC_BANK-Fehler zu beseitigen. Warum die (sehr wohl vorhandenen) defines nicht übernommen werden, habe ich noch nicht verstanden.
Ich glaube nicht das es an der Version liegt. Gib mir mal einen Link auf die Version 1.2, wie weiter oben geschrieben habe ich diese auf der ST Webseite nicht gefunden. Wenn ich diese Version habe kann ich auch ein Template dafuer erstellen und hier posten.
Sehr gern; unter http://www.st.com/web/en/catalog/tools/PF257901 sollte die Version 1.2 der StdPeriph-lib für den STM32F4 liegen. Dort bekam ich immer FMC_BANKx not defined, obwohl ich defines dafür händisch gefunden habe. Ich glaube ebenfalls, dass der Fehler eher vor dem Bildschirm zu suchen ist, habe ihn allerdings noch nicht gefunden.
Angehängte Dateien:
-
STM32_Eclipse_Symbols.png
110 KB
OK, ich hab die V1.2 in das von mir gepostete Template eingebaut. Ja, da hat es einige Aenderungen, auch einige wo ich noch nicht ganz durchsteige. Aber ich kann das Problem eingrenzen. Es liegt ganz klar an den Definitionen die den verwendeten Chip beschreiben. Ich hab mir jetzt nicht alle Datenblaetter der einzelnen Chips angesehen, aber ich sehe in den Definitionen das es da grosse Unterschiede gibt und die header files definieren Peripherie in Abhaengigkeit von den entsprechenden Chip Definitionen. Ein Problem ist, dass die Header Files zwar Peripherie definieren oder nicht, eclipse aber immer alle *.c files kompilieren will. Da knallt's dann natuerlich. Ein workaround so auf die Schnelle ist. 1. die Chip definition in eclipse vorzunehmen. Also in den Symbols den richtigen Chip zu definieren, !NICHT im entsprechenden Header file (aus)kommentieren. 2. nur die wirklich benoetigten .c Files der StdPeriph_Lib in das Projekt zu kopieren.
Um eines noch mal zu Unterstreichen. Das gilt fuer alle STM's und LPC's mit den jeweiligen vom Hersteller bereitgestellten Lib's. Wenn Ihr mit dem Standard eclipse CDT und den jeweiligen Lib's vom Hersteller arbeiten wollt, versucht moeglichst keine Aenderungen in den original Header files vorzunehmen. Alle Symbole lassen sich in eclipse, wie oben im Bild gezeigt, definieren. Damit haben wir dann in eclipse auch die Moeglichkeit .c files in Abhaengigkeit der .h files zu kompilieren oder wegzulassen. Ich muss nur einen Weg finden wie man das am einfachsten direkt im eclipse build-system unterbringen kann. Die angebotenen auf eclipse basierenden IDE's machen das auch nicht anders. Nur haben die Programmierer dieser IDE's ein anders Verhaeltnis zu java als ich es habe. ;-)
Ja, ich handhabe es auch so, dass ich alles über Symbole in Eclipse belege, aber ich komm mit der neuen Version noch nicht klar. Ich finde es etwas schade, dass auf freie Entwicklungsumgebungen seitens ST nicht wirklich eingegangen wird (oder habe ich etwas übersehen?). Auch wäre es schön gewesen, wenn die Änderungen in der Lib besser beschrieben wären. Naja, das Projekt pressiert und dann muss das eben erstmal mit der älteren Version erstellt werden.
Das Problem ist groesser als es aussieht. Die Hardwareentwickler stehen an einer Schwelle. Die groesseren Microcontroller stellen mittlererweile Microprozessoren vom Umfang her in den Schatten. Immer mehr und komplexere Peripherie kommt auf die Chips. Das heisst die Komplexitaet steigt um ein vielfaches. Es gibt aber noch kein Tool das die Charakteristiken des uC's erkennt so wie autoconf heute die Eigenheiten eines Betriebssystems erkennen kann. Da bleibt es in der Verantwortung des Entwicklers dem Build-System zu sagen was er auf seinem Chip hat und was nicht. Das war vor 20 Jahren bei den Betriebssystemen genauso, da gab es auch noch keine auto-tools und der Programmierer musste die verwendeten Libs haendisch auswaehlen, in sein Projekt uebernehmen und im Makefile eintragen. Auf der anderen Seite steht die Kurzlebigkeit der Chips und der Time-To-Market Druck bei den Geraete-Herstellern welche die Chips verwenden. Die Loesung fuer Chiphersteller und Applications-Entwicklung ist, sich auf vorgefertigte Tools zu konzentrieren. ST und NXP zBsp. versuchen zumindest den Entwicklern die deren uC's verwenden Werkzeuge in die Hand zu geben die unabhaengig von Kompiler/IDE-Herstellen sind. Auch versucht ST und NXP auf die Open-Source Welt Ruecksicht zu nehmen und zumindest ein paar der freien Kompiler oder IDE's zu unterstuetzen. Microchip zBsp. macht das nicht. Desweiteren fehlen den Chipherstellern die festen Ansprechpartner in der Open-Source Welt. Somit koennen Sie auch keine Ruecksicht auf alles nehmen was da geboten wird. Was ich speziell bei ST zu beanstanden habe ist, dass Sie (bis jetzt) nur Microsoft basierte Betriebssysteme unterstuetzen.
Juergen G. schrieb: > Was ich speziell bei ST zu beanstanden habe ist, dass Sie (bis jetzt) > nur Microsoft basierte Betriebssysteme unterstuetzen. Ja, wieviele Leute gibt es denn, die im prof. Embedded/Automation Umfeld unter Linux entwickeln? Die ideologischen Grabenkämpfe der pubertären Linux-Frickel-Fraktion (nette Alliteration gell), interessieren dort nichts und niemanden. gruß cyblord
cyblord ---- schrieb: > Juergen G. schrieb: > >> Was ich speziell bei ST zu beanstanden habe ist, dass Sie (bis jetzt) >> nur Microsoft basierte Betriebssysteme unterstuetzen. > > Ja, wieviele Leute gibt es denn, die im prof. Embedded/Automation Umfeld > unter Linux entwickeln? Viele. Nämlich diejenigen, die heute mal was für ein embedded Linux (du würdest dich wundern wo überall eins drin ist) auf ARM, und morgen für einen nackten ARM Mikrocontroller entwickeln. Die dabei nicht alle Nase lang ihre gewohnte Umgebung verlassen wollen und erwarten, dass Hersteller ihre Kunden ernst nehmen. Die gewohnte Umgebung ist dabei ein Desktop-Linux, da man dort am sinnvollsten für ein embedded Linux entwickeln kann. > Die ideologischen Grabenkämpfe der pubertären > Linux-Frickel-Fraktion (nette Alliteration gell), interessieren dort > nichts und niemanden. Das Problem bei ST ist, dass in diesem Fall ST aus ideologischen Gründen nichts anderes als Windows unterstützt. Da werden einem Steine in den Weg gelegt, die wirklich nicht sein müssen. Etwas Wohlwollen oder wenigstens Neutralität statt Boshaftigkeit würde ST wesentlich besser aussehen lassen.
Ist es eigentlich schon jemand gelungen, die USB-Bibliotheken in einem Eclipse-Projekt zu verwenden? Ich bekomme immer Probleme. Es kompiliert durch, aber willkürliche Funktionen haben dann "undefined references" beim Linken. Darunter so sachen wie GPIO_Init, die bei bisherigen Projekten (vor dem Versuch der Einbindung von USB-CDC) immer funktionierten. Ein Makefile-Projekt, worauf hier im Froum verwiesen wurde, funktioniert dagegen problemlos und dient mir vorerst als Krücke, aber die Entwicklung dauert da für jede neue Funktion des Prozessors doch schon recht lang, wenn man ständig auf solche Probleme stößt. Wenn ich weiter so machen muss, dann werde ich wohl den Hersteller wechseln. Wahrscheinlich bin ich zu doof für die erweiterten Funktionen (StdPeriph ging bisher problemlos)...
versuch es mal das linkerscript und die startups aus Deinem Makefile Project in eclipse zu verwenden.
Hallo zusammen! Bin auch gerade dabei eclipse für die Entwicklung auf dem STM32F4Discovery zu installieren, habe gestern den ganzen Tag verbracht es mit der StdLib V1.2.0. zum kompilieren zu bekommen, bin aber auch an dem 'FMC_Bank1' Fehler gescheitert... Meine ersten Versuche auf Linux und STM32F4 - keine Zeile geschrieben und schon kurz vor dem Aufgeben :-( Zum Glück habe ich den thread hier gefunden, habe Juergens Template heruntergeladen und es kompiliert, jetzt gehts mir schon etwas besser :-) Bin jetzt dabei openocd wie von Jürgen beschrieben in eclipse zu konfigurieren, habe es auch alles so gemacht wie o.g., aber es funktioniert leider nicht... wo müssen denn die ganzen STM32_*.pl Dateien sein? Wenn ich das richtig verstehe in einem Ordner 'openocd' im Projektverzeichnis, oder? Wenn ja, wo bekomme ich die her? Wenn das klappt sollte es ja recht einfach sein den debugger zum laufen zu bekommen :-) Vielen Dank, besonders and Jürgen (jup)! Jan
Ok, bin schon ein Stückchen weiter: stm32_flash.pl findet man im Netz, die anderen beiden für reset und shutdown leider nicht... Die Verbindung zum ST-Link klappt auch schon zum Teil, debugging scheitert aber noch: Open On-Chip Debugger 0.7.0 (2013-11-06-10:29) Licensed under GNU GPL v2 For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.html Info : This adapter doesn't support configurable speed Info : STLINK v2 JTAG v14 API v2 SWIM v0 VID 0x0483 PID 0x3748 Info : Target voltage: 2.915303 Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints Info : accepting 'gdb' connection from 3333 Info : device id = 0x10016413 Info : flash size = 1024kbytes Warn : acknowledgment received, but no packet pending undefined debug reason 6 - target needs reset Error: Target not halted Error: failed erasing sectors 0 to 0 Error: flash_erase returned -304 Info : dropped 'gdb' connection Was geht denn hier schief?
Die openocd files sind im ersten von mir geposteten Projekt template. das zweite Template war eigentlich nur um zu zeigen wie man die abgespeckte STDLib fuer den F4 compilieren kann. Im Anhang dann nochmal ein F4 Projekt template mit den openocd files.
Zum allgemeinen Verstaendnis. Openocd ist komplett unabhaengig von eclipse und laeuft normalerweise in einer separaten shell als server. ueber Telnet in einer anderen shell kann man sich dann mit dem openocd server verbinden. telnet localhost <PORT> wobei default-maessig (openocd install defaults) Port 3333 der debug Port ist und Port 4444 der Port zum algemeinen "schwatzen" mit der MCU (oder zum flashen) Es ist natuerlich laestig, das immer alles einzutippen. So kann man jede beliebige scriptsprache nehmen um das zu "automatisieren" Diese scripte kann man dann natuerlich in eclipse einbinden. Wer einen anderen microcontroller oder anderes Board verwendet muss das in der openocd.cnf entsprechend anpassen. fuer den F4 mit dem STLink-V2 sieht openocd.cnf zBsp. so aus
1 | #
|
2 | # Flash programming script for stm32f0 discovery
|
3 | # Using the swd transport
|
4 | #
|
5 | |
6 | source [find interface/stlink-v2.cfg] |
7 | source [find target/stm32f4x_stlink.cfg] |
die entsprechenden config files findet man zum grossen Teil forgefertigt in den Verzeichnissen openocd/interface und openocd/target Die Dateien in diesen Ordnern sind Kopien aus dem openocd Projekt und nur in meinem Ordner damit ich sie schneller zur hand habe Wer irgendetwas exotisches verwendet kann sich mit der openocd Doku auch selbst seine eigenne cfg files zusammenbauen.
Hallo Jürgen, vielen Dank für das Template! Funktioniert soweit, aber die rot/gruene LED auf dem ST-Link Teil des discovery bleibt gruen, ich kann daher den ST-Link nicht nochmal starten nach einem shutdown: Open On-Chip Debugger 0.7.0 (2013-11-06-10:29) Licensed under GNU GPL v2 For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.html Info : This adapter doesn't support configurable speed Info : STLINK v2 JTAG v14 API v2 SWIM v0 VID 0x0483 PID 0x3748 Info : Target voltage: 2.915608 Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints Info : accepting 'telnet' connection from 4444 target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x0800026c msp: 0x2001c000 Info : device id = 0x10016413 Info : flash size = 1024kbytes Info : device id = 0x10016413 Info : flash size = 1024kbytes flash 'stm32f2x' found at 0x08000000 auto erase enabled wrote 16384 bytes from file /home/jan/workspace/STM32F4_StdPerphLib_Eclipse_Template/Release/STM32F4 _StdPerphLib_Eclipse_Template.bin in 0.760251s (21.046 KiB/s) Info : dropped 'telnet' connection Info : accepting 'telnet' connection from 4444 Info : dropped 'telnet' connection Info : accepting 'telnet' connection from 4444 shutdown command invoked Wenn ich dann wieder starte passiert folgendes: Open On-Chip Debugger 0.7.0 (2013-11-06-10:29) Licensed under GNU GPL v2 For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.html Info : This adapter doesn't support configurable speed Error: read version failed in procedure 'transport' in procedure 'init' Muss das board abstecken und wieder einstecken um es wieder nutzen zu können... Woran mag das liegen?
Den shutdown musst Du nicht immer machen, er beendet den openocd server. nur einmal de openocd server starten, dann viele male flashen oder den uC resetten und bevor Du das projekt verlaesst dann einen shutdown, damit eclipse ohne meckern beendet.
Das debugging scheitert auch noch leider (port 3333 fuer gdb ist richtig, oder?): Error in final launch sequence Failed to execute MI command: load /home/jan/workspace/STM32F4_StdPerphLib_Eclipse_Template/Debug/STM32F4_S tdPerphLib_Eclipse_Template.elf Error message from debugger back end: Error erasing flash with vFlashErase packet Error erasing flash with vFlashErase packet Und dazu die Ausgabe von der Konsole: Open On-Chip Debugger 0.7.0 (2013-11-06-10:29) Licensed under GNU GPL v2 For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.html Info : This adapter doesn't support configurable speed Info : STLINK v2 JTAG v14 API v2 SWIM v0 VID 0x0483 PID 0x3748 Info : Target voltage: 2.913574 Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints Info : accepting 'gdb' connection from 3333 Info : device id = 0x10016413 Info : flash size = 1024kbytes Warn : acknowledgment received, but no packet pending undefined debug reason 6 - target needs reset Error: Target not halted Error: failed erasing sectors 0 to 0 Error: flash_erase returned -304 Info : dropped 'gdb' connection Info : accepting 'gdb' connection from 3333 Warn : acknowledgment received, but no packet pending undefined debug reason 6 - target needs reset Error: Target not halted Error: failed erasing sectors 0 to 0 Error: flash_erase returned -304 Info : dropped 'gdb' connection
Hab jetzt mal auf telnet localhost 4444 mitgehört: Open On-Chip Debugger accepting 'gdb' connection from 3333 acknowledgment received, but no packet pending Target not halted failed erasing sectors 0 to 0 flash_erase returned -304 dropped 'gdb' connection
Du musst einmal am Anfang Deiner Arbeit den openocd starten Wenn Du Deinen eclipse workspace so konfiguriert hast wie weiter oben mit den Bildern beschrieben kannst Du einfach auf start_STLink in den Faforiten im extern tool menu klicken dann kannst du so oft flashen und resetten wie Du willst jeweils mit flash oder reset im extern tool menu und nur wenn Du eclipse verlassen willst oder den openocd nicht mehr brauchst auf shutdown klicken
Hi Jürgen! Flashen klappt, reset auch :-) Nur debugging klappt nicht, da ist noch irgendwo ein Problem: Error in final launch sequence Failed to execute MI command: load /home/jan/workspace/STM32F4_StdPerphLib_Eclipse_Template/Debug/STM32F4_S tdPerphLib_Eclipse_Template.elf Error message from debugger back end: Error erasing flash with vFlashErase packet Error erasing flash with vFlashErase packet Kann es an einem Verstaendigungsproblem zwischen debugger und openocd liegen?
Ich verwende den Debugger kaum, besser gesagt nur zum probieren ob openocd anspringt, fuer meine Projekte gar nicht. Aber schau mal weiter oben, Martin hat das am laufen mit dem F4 und er hat uns da auch seine Bilder rangehaengt.
hast Du in den Extern Tool Eistellungen den Haken bei Build before xxx im Build Tab deaktiviert? Sollte deaktiviert sein in allen Tools. Es erschein mir etwas rar, das der Debugger den Flash erasen will. Wenn Du nach dem Flashen mit dem Debugger auf den uC gehst sollte das Programm gestoppt und vor dem Anfang, also vor dem Startup stehen.
>die meisten neuen Distros haben den arm-none-eabi in den Packetquellen
Dann braucht man unter Ubuntu das ganze Paket von CodeSourcery überhaupt
nicht ?
JensH schrieb: > Dann braucht man unter Ubuntu das ganze Paket von CodeSourcery überhaupt > nicht ? Das ist richtig. Die Compiler in den Paketquellen sind zZ. auch aktueller als die OpenSource Version von CodeSourcery.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.