www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik STM32F103 auf STM3210E-EVAL + Eclipse + Yagarto +openocd +dbg


Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
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'
target remote localhost:3333
monitor reset halt
monitor cortex_m3 maskisr on
#set mem inaccessible-by-default off
set remote hardware-breakpoint-limit 6
set remote hardware-watchpoint-limit 4
load
compare-sections
#monitor reset
#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:
target remote localhost:3333
0x00000000 in ?? ()
monitor reset halt
JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
JTAG tap: stm32.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x080020b4 msp: 0x20005000
monitor cortex_m3 maskisr on
cortex_m3 interrupt mask on
set remote hardware-breakpoint-limit 6
set remote hardware-watchpoint-limit 4
load
Loading section .isr_vector, size 0x10c lma 0x8000000
Load failed
compare-sections
Section .isr_vector, range 0x8000000 -- 0x800010c: matched.
Section .text, range 0x800010c -- 0x8002150: matched.

Oder nach einem manuellen 'reset init' auf der openocd console flasht er 
aber dann:
target remote localhost:3333
Reset_Handler () at lib/src/stm32f10x_vector.c:188
188  {
monitor reset halt
JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
JTAG tap: stm32.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x080020b4 msp: 0x20005000
set remote hardware-breakpoint-limit 6
set remote hardware-watchpoint-limit 4
load
Loading section .isr_vector, size 0x10c lma 0x8000000
Loading section .text, size 0x2044 lma 0x800010c
Start address 0x0, load size 8528
Transfer rate: 10 KB/sec, 4264 bytes/write.
compare-sections
Section .isr_vector, range 0x8000000 -- 0x800010c: matched.
Section .text, range 0x800010c -- 0x8002150: matched.
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:
> reset init
JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver:                                                    0x3)
JTAG tap: stm32.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver:                                                    0x0)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080020b4 msp: 0x20005000
dropped 'gdb' connection - error -400
accepting 'gdb' connection from 0
acknowledgment received, but no packet pending
device id = 0x10016414
flash size = 512kbytes
JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver:                                                    0x3)
JTAG tap: stm32.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver:                                                    0x0)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080020b4 msp: 0x20005000
address + size wrapped(0xfffffffe, 0x00000004)
cortex_m3 interrupt mask on
not enough working area available(requested 16384, free 16336)
dropped 'gdb' connection - error -400
> reset init
JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver:                                                    0x3)
JTAG tap: stm32.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver:                                                    0x0)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080020b4 msp: 0x20005000
> halt
> poll
background polling: on
TAP: stm32.cpu (enabled)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080020b4 msp: 0x20005000
> flash banks
#0: stm32x at 0x08000000, size 0x00080000, buswidth 0, chipwidth 0
> flash info 0
#0 : stm32x at 0x08000000, size 0x00080000, buswidth 0, chipwidth 0
        #  0: 0x00000000 (0x800 2kB) protected
        #  1: 0x00000800 (0x800 2kB) protected
   ....
        #255: 0x0007f800 (0x800 2kB) protected
stm32x (High Density) - Rev: Z
>

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

: Verschoben durch Moderator
Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mathias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Weber (peterguy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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!

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Matthias K. (matthiask)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Mathias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Lutz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias K. (matthiask)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Atollic TrueStudio Lite macht ein ELF-File standardmäßig. Nur falls man 
daraus ein .hex braucht, muss man das im Anschluß selber machen.

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.