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
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.
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"
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)
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,
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)
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
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]
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
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.
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)...
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[findinterface/stlink-v2.cfg]
7
source[findtarget/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.
