Hallo,
ich habe mir ein STM32F103 Board auf ebay gekauft. Ich wollte dies nun
mit System Workbench for STM32 programmieren.
Was ich gemacht habe:
Donwload + installation.
Projekt angelegt, Prozessor angelegt und dann mit viel trickerei die
Standardbibliothek runtergeladen (ging leider nicht automatisch).
Jetzt habe ich ein einfaches Projekt erstellt und will die LED auf dem
Board einschalten.
Leider klappt es nicht und es kommt folgende Fehlermeldung:
>>>>
Error in final launch sequence
Failed to execute MI command:
load E:\\xxx\\00_WorkspaceSTM32\\BlinkLED\\Debug\\BlinkLED.elf
Error message from debugger back end:
Error erasing flash with vFlashErase packet
Error erasing flash with vFlashErase packet
<<<<
Ich habe mal meine main.c und mein config file angehängt. Debugger ist
ein ebay ST-Link V2.
Ich bin etwas ratlos, wäre für Tipps dankbar (auch für brauchbare
Anleitungen).
Vielen Dank und schönen Abend
Joe
Joe schrieb:> Ich bin etwas ratlos, wäre für Tipps dankbar (auch für brauchbare> Anleitungen).
Also, diese ebay.cfg ist wohl eher ein schlechter Witz.
So, also:
1. besorge dir eine Toolchain, also einen "Klumpen" Software, mit der du
selbstgeschriebene Quellen für deinen µC auf deiner Leiterplatte
übersetzen kannst. Das kann (muß aber nicht) eine Toolchain für die
C-Programmiersprache sein. Soweit ich weiß, gibt's bei
"http://www.mikroe.com/"; auch Toolchains für Basic und Pascal. Hab
selbst damit aber keine Erfahrungen. Wenn C, dann würde ich dir zuerst
zum "Keil" raten, ist bis 32 K frei und wenn viel später dein Zeugs mal
> 32 K werden sollte, kannst du immer noch auf was Anderes wechseln.
2. Lies das Datenblatt und das Referenzmanual zu deinem Chip. Oder
überfliege selbige wenigstens
3. Besorge dir ein Programmier-Geschirre. Lies dazu die hoffentlich
vorhandene Dokumentation zu deiner Leiterplatte. Schau nach, wie es dort
vorgesehen ist, den Maschinencode in den Controller zu bekommen. Die
STM32 haben einen fest eingebauten Bootlader, den man über einen COM
Port benutzen kann, sofern auf der LP vorgesehen, Software für den PC
dazu gibt es frei. Alternative wäre ein JTAG/SWD-Adapter. Den muß man
aber erst besorgen und man braucht dafür auch Software auf dem PC. Das
kostet Geld oder Nerven. Oder beides.
4. Übe mit deinem Programmiergeschirre. Zunächst sowas wie ID-Signatur
auslesen, Leertest, Chip löschen und so. Wenn das alles klappt, dann
erst geht es mit all dem Software-Gehampel los. Wie? na je nachdem, was
du unter 1. dir besorgt hast.
W.S.
Moin ws,
danke für deine Antwort. Das von dir beschriebene mache ich doch genau.
Es klappt leider nur nicht.
zu 1.
Das System Workbench ist doch eine komplette Toolchain, wird sogar von
STM empfohlen. Ist halt Eclipse mit Compiler und Debug Unterstützung von
ST
Und es muss C oder C++ sein, das kann ich ziemlich gut.
zu 2.
Habe ich gemacht, kommt dann später mehr, wenn ich spezielle Sachen in
Betrieb nehmen will.
zu 3. Ich habe einen ST-Link V2 also einen JTAG/ SWD Adapter, ohne
Debugging Programmieren will ich nicht. Debugger sollte in dem System
Workbench Paket enthalten sein.
Warum ist mein cfg ein schlechter Witz... Über den Namen kann man
streiten :-) Habe das Board halt auf ebay gekauft. Doku zu dem Board
gibt es nicht, ist aber auch nicht viel drauf.
Hast du noch eine Idee?
Viele Grüße
Joe
Joe schrieb:> Das System Workbench ist doch eine komplette Toolchain, wird sogar von> STM empfohlen.
Mit "Toolchain" war nicht "IDE" gemeint, sondern "Compiler und
Buildscripts". Buildscripts können unter Windows z.B. Batchfiles sein,
unter Linux Shellscripte.
Passt schon alles.
Das Problem ist die Kommunikation von openocd mit dem ST-Link V2.
Wird fehlerfrei compiliert?
Sieh dir die Debug Configuration genauer an.
Hallo,
super, das bringt mich schon mal weiter.
ST-Link habe ich heruntergeladen und ein Firmewareupdate gemacht.
Unter den Options habe ich die "Read Out Protection" deaktiviert und
kann das Teil nun mit ST-Link beschreiben (leider geht die LED nicht an,
aber das ist erstmal zweitrangig).
Debuggen geht noch nicht....
Danke für eure HIlfe.
Muss also mit deiner ebay103.cfg zu tun haben...
Joe schrieb:> da sagt er bei mir SCRIPT NOT FOUND.
Sagt er bei mir auch, geht aber trotzdem.
Müsste bei mir erst suchen was benutzt wird, ist aber Linux.
Hm man kann es auch direkt eingeben. Funktioniert leider aber auch
nicht. Den ST-Link findet er auch.
nfo : The selected transport took over low-level target control. The
results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
srst_only separate srst_nogate srst_open_drain connect_assert_srst
srst_only separate srst_nogate srst_open_drain connect_assert_srst
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v27 API v2 SWIM v6 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.244504
Info : stm32f1x.cpu: hardware has 6 b
Reset ist angeschlossen, trotzdem nicht...
Es hat jedoch doch was mit der Resetleitung zu tun.
mit reset_config none separate im config file konnte ich gerade das
erste mal auf den Controller.
Vielen Dank an alle!!!
Joe schrieb:> Hast du noch eine Idee?
Ja, selbstverständlich.
Also, das Board ist ein Minimal-Brettl, wo so ziemlich alle Pins einfach
so herausgeführt sind - jedenfalls sieht es auf dem Ebay-Foto so aus.
Wenn du noch keinen Stromlaufplan dafür hast, dann nimm ihn von der LP
her auf. Du mußt ja wenigstens herauskriegen, wie du mit den Jumpern
umgehen mußt - und ein kompletter Stromlaufplan ist immer hilfreich.
So, zur Toolchain: Ich meine damit NICHT irgend eine IDE, sondern das,
wo die eigentliche Musike spielt. Das ist Compiler, Assembler, Linker,
RT-Libs, Fromelf und so. Du solltest lernen, selbige selbst aufzurufen,
damit du nicht auf die 1000 Befindlichkeiten irgendwelcher IDE's
angewiesen bist. Wenn du mit den eigentlichen Tools flott gekommen bist,
dann ist immer noch Zeit genug, sich irgend eine IDE auszugucken -
sofern dir dann immer noch der Sinn danach steht.
Das mit dem Programmiergeschirre und dem PC-Programm dazu meine ich
bitterernst. Sieh zu, daß du eine funktionable Standalone-Lösung für
dich zusammenbekommst. Ob dann später deine Lieblings-IDE sowas
ähnliches auch integriert hat, ist zweitrangig. Ich würde an deiner
Stelle zuerst mal auf den integrierten Bootlader orientieren, denn das
Geschirre dazu besteht nur aus einem simplen USB-zu-TTL-Serial-Adapter,
den es vom Chinesen billigst gibt. Ja - auch ein chinesischer JLink ist
billig, aber mit dem Bootlader bleibt man anständig. Und mit einem
ST-Link ist man auf das Zeugs von ST festgenagelt - sehr unschön. Den
Keil'schen ULINK sollte man lieber vergessen, ist auch ein
Festnagel-Produkt.
Zum Debuggen:
Was zum Kuckuck willst du debuggen? Wofür willst du den Debugger
überhaupt haben? Meine Erfahrung ist, daß der Debugger nur dafür gut
ist, daß jemand bei allzu gewagten C-konstrukten herausbekommt, was der
Compiler draus gemacht hat.
So etwa in der Art:
const struct Fontheader* const FontPool[FontAnzahl] = {...
Das was du hingegen viel dringender brauchst, ist eben das Zeugs, womit
man deinen erzeugten Maschinencode in den Controller gebrutzelt bekommt.
Ansonsten brauchst du nen funktionablen Startupcode, ne Headerdatei für
die Hardware-Register deines µC und ne Batchdatei zum Aufrufen von
Compiler, Linker etc. Der Rest ist absolut fakultativ.
Ich hänge dir mal ein paar Dateien hier dran, die ich soeben
zusammengekratzt habe. Einige davon sind HW-unabhängig. Die anderen
solltest du dir durchsehen und an deinen µC anpassen. Wie die ccc.bat
funktioniert, sollte klar ersichtlich sein, ebenso beide .xcl, beides
ist für den Keil ausgelegt. Nimm den Keil für den Anfang, der ist
wesentlich benutzerfreundlicher als alle GCC-Distributionen die ich
kenne. Du wirst sehen, daß man mit 32 K an Code ganz schön weit kommt.
Im Paket sind:
- Konfiguration (hier für STM32F3..)
- serielle I/O per USART's und per USB
- Kommandoprogramm
- Systick
- Events
- Konvertierungen
Die beiden STM32Fxx.h solltest du dir kritisch anschauen und ggf. nach
Refmanual redigieren. Die für den F302 ist neuer, da hab ich den
häßlichen Zirkus mit struct's bleiben lassen. Nach meiner Erfahrung
nimmt der Compiler sowieso all diese HW-Struct's komplett auseinander
und adressiert das Zeugs auf seine Weise.
W.S.
