Ein Erfahrungsbericht mit Fragen und (hoffentlich) eine Zusammenfassung
der bestehenden Threads bzgl. dieses Themas.
Ich habe aktuell einige Projekte mit STM32F103 und STM103F107. Dazu habe
ich hier zwei DevKits:
Das IAR (OLIMEX) STM32F103ZE-SK und das STM STM3210E-EVAL. Eines für
F107 ist noch im Zulauf.
Die Demos:
Das IAR Board liefert einige Demos mit, die man mit der IAR Workbench
schnell übersetzen und dank dem auf dem 103E-SK integrierten J-Link auch
einfach flashen kann. Alle Demos funktionieren 'Out of the Box'.
Das STM3210 Kit tut sich da deutlich schwerer. Weil sich STM nicht
entscheiden kann, welchen Toolchain-Lieferanten sie unterstützen wollen,
sind die Verzeichnisse recht überfrachtet. Aber nach einigem Hin und Her
kann man mit dem IAR auch diese Demos übersetzen. Aber das 3210E-EVAL
wird ohne JLINK ausgeliefert. Also entweder J-Link kaufen oder anders
behelfen.
Es gibt die Option das FlashLoaderDemo von ST herunter zu laden und Den
Controller per BOOT0=1 im FlashLoader Modus zu starten. Das ging bei mir
meistens, oft genug schoss sich die CPU aber nachher auch in deinen
Hangup, also BusError oder HardFault Exception.
Mein Ziel war es aber, eine komplette OpenSource Toolchain zu nutzen,
so, wie ich es von den AT91SAMx gewohnt bin. Also habe ich mir Eclipse
Helios C/C++ installiert und das ZylinCDT dazu. Einen auf AT91SAMx
prächtig funktionierendes Gespann aus OpenOCD 0.4.0 (ftdi) und
OpenOCD-USB habe ich ja schon hier liegen.
Das Importieren eines einfachen Projektes aus dem Internet ( ein
LED-Blinker) in Eclipse hat gut funktioniert. Aber das Kompilieren war
ein Albtraum. Die Libs und das Demo Programm konnten sich nie über
VFP/FP/FPA u.s.w. einigen. Alle Versuche die Compiler Flags nach
Hinweisen aus diesem und anderen Foren zu setzen nutzen nichts.
Die Lösung war, den aktuellen Yagarto 4.5.0 zu installieren!
Kompilieren, fertig.
Dann mit openocd flashen: Funktioniert!
LEDs: Blinken nicht...
Das Problem war, dass das Demo für einen anderen Typen des F103 gedacht
war, meine LEDs sind an Ports, die das Demo noch nicht einmal kannte.
Also habe ich das Demo noch um die fehlenden Ports erweitert und dann
blinkte auch die LED. Das Demo war aber ein CodeSourcery basiertes Demo,
nicht eines der den Kits beiliegendes und ich habe es genutzt, weil es
Makefile basiert ist.
Nun, Eclipse läuft, also ans ZylinCDT heran gemacht, OpenOCD gestartet
und, naja, es geht... meistens, nicht immer. Das Problem ist, dass man
im Netz tausende Ideen und Anleitungen für OpenOCD findet, aber man muss
sehr darauf achten, für welchen SVN Build sie gedacht ist.
Dazu später mehr.
Recht genial finde ich das Beispiel von STM, dass auf dem STM3210E-EVAL
ein uClinux booten kann. Ich habe mir das ganze mal zusammen geladen und
auch kompiliert. Der Weg zuerst über das FlashLoaderDemo einen
Bootloader in das CPU-Flash zu laden und dann per DFUSe per USB das
Linux-Image auf das NOR Flash zu speichern ist etwas kompliziert. Leider
scheint der F103ZET6 trotz Bootloader Version 2.2 nur Serial-Download
aber kein USB-Download zu unterstützen. Leider kommt der Bootloader
irgendwie nicht mehr zurpück in den DFU-Mode, wenn er ein Image im NOR
findet, das funktioniert. Ich habe keinen Hinweis gefunden, wie man den
Bootloader dazu überredet, noch mal den DFU Modus zu aktivieren, damit
man ein anderes Image aufspielen kann. Ich kann also das Linux-Image
nicht durch ein geändertes ersetzen, es verhungert jetzt im NOR.
Inzwischen habe ich jedoch Kontakt mit STM gehabt und der entscheidende
Hinweis war, dass es einzelne Fälle gibt in denen die Kombination Reset
und User-Key länger gedrückt werden muss, damit der Bootloader wieder in
den DFU-Modus geht. Das wars, so geht es auch bei mir, auch mein selbst
gebackener uClinux-Kernel funktioniert:
1
Linux version 2.6.26-uc0uprinz (uprinz@laptop) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-189) ) #1 Tue Jul 20 13:33:42 CEST 2010
Ok, zurück zur Toolchain...
Die ganze Installation ist nach den Yagarto Dokus gemacht, mit der
Ausnahme, dass ich eben statt Ganimede Classic die Helios C/C++ genommen
habe.
Leider sind die Meinungen sehr unterschiedlich, was das Script für den
openodc betrifft.
Unter Debug Configurations / Zylin Embedded debug (Native) / Mein
Projekt
im Reiter Debugger habe ich folgendes eingetragen:
GDB debugger: arm-none-eabi-gdb
GDB command file: ist leer.
GDB Command Set: Standard
Protocol: mi
Verbose console mode: NEIN
Use full file path to set breakpoints: NEIN
Im Reiter Commands:
'Initialize Commands'
1
target remote localhost:3333
2
monitor reset halt
3
monitor cortex_m3 maskisr on
4
#set mem inaccessible-by-default off
5
set remote hardware-breakpoint-limit 6
6
set remote hardware-watchpoint-limit 4
7
load
8
compare-sections
9
#monitor reset
10
#break main
Mit dieser Kombination gibt es Probleme. Sehr oft erhalte ich die
Meldung, dass zu viele breakpoints gesetzt seien. Aber ich habe keinen
oder nur einen gesetzt. Daran ändert sich auch nix, wenn ich die
CortexM3 spezifischen Set und monitor Commands heraus nehme.
Der Output sieht dann gerne so aus:
Section .isr_vector, range 0x8000000 -- 0x800010c: matched.
19
Section .text, range 0x800010c -- 0x8002150: matched.
20
Note: automatically using hardware breakpoints for read-only addresses.
Obwohl das dann erfolgreich aussieht, klemmt die CPU in einer
BusFaultException
Es sieht so aus, als würde das Flashen des STM32F103ZE nicht
funktionieren.
Also zur OpenOCD Console:
Es scheint ein Problem mit dem Flashen zu geben. Denn hier werden alle
Pages als protected angezeigt, wenn ich aber das STM eigene
FlashLoaderDemo verwende, dann sind dort alle Pages als Unprotected
deklariert.
Alle kommandos wie 'stm32x unprotect 0' oder 'flash write_image erase
main.bin 0x08000000' werden vom openocd positiv quittiert. Der Start
eines Codes endet aber dann meist in einer Exception nur jetzt, wo ich
es reproduzieren will, funktioniert das LED-Demo netürlich
einwandfrei...
Gibt es an dieser CPU irgendetwas, dass man noch ändern oder flashen
muss, damit sie wieder willig ist, mit dem openOCD zusammen zu arbeiten?
Denn ursprünglich hat das Flashen ja ein paar mal funktioniert, sowohl
auf dem IAR Kit als auch auf dem STM Kit.
Mich würde auch interessieren, ob man eclipse dazu verwenden kann, den
Code einfach nur zu flashen und zu starten, also ohne den Debugger
anzuwerfen.
So, das sind die ersten Erfahrungen und Frage mit dieser Kombination aus
Hardware und Toolchain.
Gruß, Ulrich
Noch ein Nachtrag:
Früher konnte man im IAR mal ein Projekt als Makefile Projekt
exportieren. Diese Option ist aber verschwunden, oder finde ich sie nur
nicht?
Gruß, Ulrich
Hallo Ulrich,
ich programmiere das erste mal einen µC und sehe momentan vor lauter
Bäumen den Wald nicht mehr.
Wo finde ich denn am besten ein Beispielprojekt, welches ich mir laden
kann, damit ich erstmal was habe, an dem ich mich ein bischen austoben
kann?
Die Demoprogramme von meine Keil-CD kann ich ja nicht nutzen, oder?
Danke schonmal für eine Info.
Mathias
> ich programmiere das erste mal einen µC und sehe momentan vor lauter> Bäumen den Wald nicht mehr.
Versuchs mal mit einem kleineren Mikrocontroller, z.B. dem Arduino Board
um einen Einstig zu finden.
Direkt mit dem STM32 einzusteigen ist vielleicht ein wenig zu viel auf
einmal und führt auf Dauer nur zu Frust!
Ich habe mich jetzt echt gewundert, warum Peter mir rät einen kleineren
Controller zu nehmen...
Machmal ist das Hijacking eines Threads echt problematisch, ich hatte
eine Zeit lang gehofft, dass ich zu meiner Frage auch meine Antwort
erhalte :)
CortexM ist echt schon eine gehobene Klasse. Das Problem dabei ist schon
der Anfang ganz unten. Für kleine Mikrocontroller finden sich viele
verschiedene Beispiele mit denen man Stück für Stück diese Welt kennen
lernen kann. Auch die Datenblätter und Application Notes der Hersteller
sind entsprechend.
Die 4000 Seiten, die man für einen STM32 insgesamt lesen muss, wenn man
neu ist und alles von Anfang an lernen will, die überfordern vielleicht
etwas...
Aber trotzdem würde ich nicht gleich hinwerfen. Die Beispiele zu dem
Demo-Kit kann man selbstverständlich mit der dem Kit beiliegenden
Compiler-Version kompilieren. Die Beispiele überschreiten die
Größenbeschränkung des Compilers nicht. Also einfach loslegen. Wenn Du
Dich dann ein wenig auskennst, kannst Du versuchen statt des mit
gelieferten Compilers einen anderen zu nehmen. Wie Der Thread erkennen
lässt, kann man den aktuellen Yagarto und auch Codesourcery installieren
und damit den gcc auf dem STM los lassen. Dann schau mal bei den
verschiedenen freien RTOS nach oder ich bin bis dahin mit einem STM32
Port für Nut/OS fertig.
Dann wirst Du sehen, dass es einfach sein kann auf einem schnelleren
Controller zu arbeiten als auf einem einfachen und kleinen. Und Du wirst
es angenehm finden, nicht jedes mal eine Reihe Code für die
Kleinigkeiten wie printf, scanf, timer, spi, i2c... schreiben zu müssen
sondern einfach mit ein paar fertigen Routinen seine Hardware zu
aktivieren.
Ist ein Weg und er ist machbar. Habe neben mir sehr viele in diesem
Forum hinter sich oder gehen ihn gerade.
Gruß, Ulrich
@Mathias
Für den Einstieg ist dies eine Überlegung Wert.
Beitrag "STM32 Einstieg mit Atollic TrueStudio und ST-LINK Jtag"
Geht aber nur mit dem ST-Link Debugger, oder über entsprechende
Bootloader flashen. Umgeht das mir völlig unverständliche Installations-
und Konfigurationschaos, was Eclipse/GCC/Openocd usw. anbetrifft.
Danke an euch,
ja, dass der für den Einstig nicht so gut geeignet ist ist mir
mittlerweile bewusst, allerdings haben wir den hier schon und ich soll
mal soeben schnell einsteigen und was programmieren.
Naja, ich werd dann mal mit den Beispielprogrammen für Keil beginnen und
dann so richtig loslegen!
Bis dann,
Mathias
Matthias K. schrieb:> Für den Einstieg ist dies eine Überlegung Wert.> Beitrag "STM32 Einstieg mit Atollic TrueStudio und ST-LINK Jtag">> Geht aber nur mit dem ST-Link Debugger, oder über entsprechende> Bootloader flashen.
Mal 'ne ganz doofe Frage: Erzeugt das Atollic TrueStudio eigentlich ein
ELF-File, auf das man Zugriff hat? GCC macht das ja, nur evtl.
"schluckt" Atollic das weg, um das Folgende zu verhindern: Man
entwickelt freudig und entspannt und flasht dann das fertige ELF-File
z.B. mit eine J-Link. Debuggen müßte dann über J-Link und zugehörigen
GDB-Server ja auch funktionieren.
Na toll :)
Jetzt kann ich eine weitere limitierte und nicht zu meiner Toolchain und
Aufgabenstellung passende Umgebungen zu meiner Liste hinzufügen, aber
eine Antwort auf meine ganz oben gestellten Fragen habe ich noch
nicht...
Gruß, Ulrich
Thread beobachten
Seitenaufteilung abschalten