www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Diskussionsrunde: Opensource Entwicklungstools für STM32


Autor: Michael B. (bubi)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

Wie in vielen Foren und auch hier wird nach Lösungen gesucht um mit dem 
STM32 nur mit frei verfügbaren Tools zu arbeiten. Dieser Thread hier 
soll als Basis dienen um einen Artikel aufzubauen der einen Lösungsweg 
beschreibt.

Vorweg: Debuggen funktioniert hier bei mir größtenteils.

Hier mal ein paar Schritte für euch zum testen und als Ausgangsbasis:

Man benötigt:

-> Eclipse
-> Eclipse CDT
-> Eclipse Zylin
-> Codesourcery Toolchain
-> openOCD 0.1.0
-> angehängte RAR-Datei

In der RAR Datei, findet ihr ein Grundsetup für das STM32-H103 von 
Olimex + Olimex USB-Tiny Debugger.
Die KOMPLETTEN Makefiles und Einstellung sind alle aufbauend auf das 
Grundsetup von lanchon aus dem ST Forum( 
http://www.st.com/mcu/forums-cat-6445-23.html&start=0 ). VIELEN DANK!

An dem Packet habe ich nur das jtag Script angepasst um mit 0.1.0 
Version von oOCD zusammen zu arbeiten. Und seine kompletten Änderungen 
an der FW-Lib wieder rückgängig gemacht, um das Ganze aktualisierbar zu 
machen und um mögliche Fehlerquellen zu bereinigen.
Leider steige ich bei den Linkerscripts nicht durch was der Herr da 
gemacht hat, aber für sowas ist der Thread ja da :).


So alles installiert? Dann gehts los.

1) Eclipse starten, neues Projekt -> C-Projekt, kompletten Ordner vom 
RAR-File importieren -> Project Properties -> C/C++ Build -> 
Buildcommand "cs-make" und als Builddirectory das Projektverzeichnis -> 
das wars :) Mit einem klick auf Build sollte eigentlich alles 
durchlaufen und mit Erfolg gekrönt sein.

2) Downloaden geht wie folgt:
-> External Tool Configuration -> cs-make suchen (C:\Program 
Files\CodeSourcery\Sourcery G++ Lite\bin\cs-make.exe) als Argument 
"flash" (ohne ") angeben. Als working dir, muss das Projektverzeichniss 
angegeben werden (muss bei jedem Projekt umgestellt werden dazu habe ich 
noch keine Lösung :( ) Rest nach belieben einstellen, also build before 
launch usw. Wie man es halt möchte.

cs-make flash führt das Script jtag/flash-bin.cfg aus
 # Open On-Chip Debugger
# (c) 2005 by Dominic Rath
# (snapshot r247 from SVN tree + giveio, no official release, compiled my mifi)
#
# --help       | -h       display this help
# --file       | -f       use configuration file <name>
# --debug      | -d       set debug level <0-3>
# --log_output | -l       redirect log output to file <name>


# daemon configuration

# logging
#debug 3

# default ports
telnet_port 4444
gdb_port 3333

#daemon_startup reset

#gdb_flash_program enable


# interface configuration

interface ft2232
#ft2232_device_desc "Olimex OpenOCD JTAG A"
ft2232_device_desc "Olimex OpenOCD JTAG TINY A"
ft2232_layout olimex-jtag
jtag_speed 10

jtag_nsrst_delay 100
jtag_ntrst_delay 100


# scan chain configuration

# jtag_device L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
#jtag_device 4 0x1 0xf 0xe
#jtag_device 5 0x1 0x1 0x1e


# target configuration

# script for stm32


#use combined on interfaces or targets that can't set TRST/SRST separately
reset_config trst_and_srst
jtag newtap stm32 cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0x3ba00477
jtag newtap stm32 bs  -irlen 5 -ircapture 0x1 -irmask 0x1 -expected-id 0x16410041
target create stm32.cpu cortex_m3 -endian little -chain-position stm32.cpu
stm32.cpu configure -work-area-virt 0 -work-area-phys 0x20000000 -work-area-size 16384 -work-area-backup 0
flash bank stm32x 0x08000000 0x20000 0 0 0

script flash-elf.script 

Das muss je nach eurem Debugger angepasst werden.
 # interface configuration
interface ft2232
#ft2232_device_desc "Olimex OpenOCD JTAG A"
ft2232_device_desc "Olimex OpenOCD JTAG TINY A"
ft2232_layout olimex-jtag
jtag_speed 10

Sollte soweit klappen. Einfach mal testen.
Als Ergebnis liegt sollte in der Console (nach haufenweiße 
Zwischenmeldungen)
 Info : device id = 0x20036410
Info : flash size = 128kbytes
stm32x mass erase complete
Info : Padding image section 0 with 0 bytes
wrote 2760 byte from file flash.elf in 0.588000s (4.583865 kb/s)

target state: halted
target halted due to breakpoint, current mode: Thread 
xPSR: 0x81000000 pc: 0x080001ee

Das Programm ist nun drüben :)

Debuggen:

Debugconfiguration -> unter Zylin embedded Debug (nativ) eine neue 
Configuration anlegen. C/C++ Application -> main.elf
-> Im Debugreiter als Debugger arm-none-eabi-gdb.exe aus dem 
Codesourcery Verzeichnis nehmen. Das GDB Commandfile entfernen
-> Im Commandsreiter unter "init"
target extended-remote localhost:3333
monitor debug_level 2
monitor halt
load
monitor cortex_m3 maskisr off
thbreak main
monitor debug_level 0 
eingeben

Jetzt unter Windows eine Console öffnen und oOCD starten. (So schauts 
bei mir aus: C:\Program Files\OpenOCD\0.1.0\interface>openocd -f 
olimex-jtag-tiny-a.cfg -f ..\target\stm32.cfg)

Und nun solltet ihr mittels der neuen Debugconfiguration Debuggen 
können.

Wichtige Hinweiße:

Im Makefile ist gaaaanz oben
DEBUG_COMP = 1  # or include DEBUG=1 in the command line
gesetzt werden, Code wird damit zwar schlechter, aber debugbar

Im lanchon-stm32.ld muss je nach CPU Typ Flashgröße und Ramgröße 
angegeben werden.

So, mehr weiß ich dazu noch nicht. Ich hab hier das Eclipse weder sauber 
noch praktisch eingerichtet. Aber soweit funktioniert es.

Was mich stört:
oOCD muss vor jedem Debuggen gestartet, und vorm flashen wieder beendet 
werden.
Linkerscripte unddurchschaubar für ich
Und teilweise noch zu Projektspezifisch :( hätte die Einstellungen 
lieber globaler

Testet es bitte mal und postet hier eure Ergebnisse.
Falls 2-3 Leute ein OK geben, werde ich das entsprechend formatiert ins 
Wiki einfügen.

Autor: Michael B. (bubi)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Mir ist leider ein Fehler passiert beim erstellen des ZIP Files.
Da gabs noch ein paar Warnings beim compilieren.
Jetzt sollte es passen.

Zudem habe ich jetzt mein Eclipse Project Einstellungen angepasst. Kann 
man das irgendwie exportieren um euch meine Perspektiven und 
Einstellungen zur Verfügung zu stellen?

Autor: Thomas Kindler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey, die JTAG-Skripte sind vieel zu kompliziert. Bei OpenOCD 0.1.0 ist 
das meiste schon dabei.

openocd.cfg
============
source [find board/stm32f10x_128k_eval.cfg]
source [find interface/jtagkey-tiny.cfg]

proc  flash_image { filename } {
  # Halt CPU and flash image
  #
  reset halt
  flash write_image erase $filename

  # "reset run" doesn't work in 0.1.0..
  #
  resume

  shutdown
}

init



und im makefile reicht dann:
=============================

# flash
#
.PHONY: flash
flash: all
  @openocd -f openocd.cfg -c "flash_image $(MAIN_OUT)"

Autor: Michael B. (bubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank dafür,

Konnte es noch einmal testen, aber jetzt scheint mein Adapter den Geist 
komplett aufgegeben zu haben. Werde es in dem nächsten Paket so 
einbinden.
Ich schau mir jetzt mal das Plugingeschreibe an... Maybe kann man das 
ARM Plugin anpassen um mit dem codesourcery zusammen zu werkeln

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ist da die newlib dabei? Kann ich printf benutzen?

Danke & Grüße
Markus

Autor: Michael B. (bubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
The current release is the 2008q3 release.

New features in this release include:

    *

      Improved optimizations for Thumb-2 and NEON.
    *

      Upgrades to GCC 4.3.2, GDB 6.8.50, and GLIBC 2.8.

New releases of Sourcery G++ Lite are made semiannually.


Direkt von der Codesourcery Seite (warum hab ich dann in meinem include 
eigentlich ne newlib.h ?!) ...
printf kannst du entsprechend angepasst natürlich verwenden.
Muss auch ins Makefile eingetragen werden soweit bin ich ncoh nicht...
Warte noch auf Rückmeldungen :)

Autor: Florian Finsterbusch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

bei YAGARTO ist nun auch ein aktualisierter GNU-Compiler dabei (Version 
4.3.3), der den Cortex-M3 des STM32 unterstützt.

Gruss, Florian

Autor: Stef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du das YAGARTO zum laufen gebracht?

Autor: Michael B. (bubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yagarto = GCC
Codesourcerys Toolchain ist ja im Prinzip GCC nur mit Modifikationen, 
Codesourcery pflegt den Cortex-M3 Teil im GCC und jede Änderung in ihrer 
Toolchain kommt über kurz oder lang sowieso in den offiziellen GCC.
Es gibt eigentlich keinen Grund Yagarto zu verwenden. Oder übersehe ich 
was

Autor: Florian F. (florianton)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe YAGARTO genommen, da es nicht nur aus dem Compiler besteht 
sondern auch die benötigten Utilities (make, ...) dabei sind und die 
Installation ausführlich beschrieben wird.
Der Compiler läuft bei mir.

Für die Kommunikation über JTAG habe ich das neue OpenOCD 0.1.0 geht.
Das Laden des Controllers geht damit.

Nur das Debuggen über Eclipse + GDB habe ich noch nicht hinbekommen 
(hatte aber auch noch keine Zeit für weitere Tests).

Gruss, Florian

Autor: Michael Maier (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe mit gcc eine .elf Datei erstellt (wie Michael B. es beschrieben 
hat) und diese anschließend (wie Thomas Kindler beschrieben) mit openocd 
geflasht. Allerdings wird das Programm nicht ausgeführt. Ich habe in 
simples LED an/aus Programm geschrieben.
Muss ich noch einen Befehl eingeben, damit das Programm ausgeführt wird?

Danke
Michael

Autor: Uwe Hermann (uwehermann) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Normalerweise "resume 0" in der telnet-session von OpenOCD.

Autor: DJ (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich versuche gerade das STM3210C-Eval Board mit den OpenOCD-USB Adaptor 
(http://www.embedded-projects.net/index.php?page_id=256) zu 
programmieren und zu debuggen. Hierfür habe ich die in diesem Forum 
beschriebenen Einstellungen übernommen und angepasst:
-> Eclipse
-> Eclipse CDT
-> Eclipse Zylin
-> Codesourcery Toolchain
-> Yargato Tools
-> openOCD 0.2.0

Das angepasste Makefile befindet sich im  Dateianhang. Weiterhin habe 
ich die datei flash-elf.cfg an den OpenOCD-Usb angepasst (siehe 
ebenfalls Anhang) und enstprechend dem ersten Foreneintrag von  Michael 
B. als external Tool-Configuration eingerichet. Das flashen funktioniert 
wunderbar. Den Debugger habe ich wie folgt eingerichtet:
->Run->Debug Configurations->Zylin Embedded Debug 
(native)->rechtsklick->new:
-Project:Projektverzeichnis wählen
-C/C++-Application die Datei flash.elf im Verzeichnis "jtag" auswählen
-im Reiter "Debugger" GDB-Debugger: C:\Program 
Files\CodeSourcery\Sourcery G++ Lite\bin\arm-none-eabi-gdb.exe , GDB 
Command File: Die Datei debug.cfg auswählen, die ebenfalls im Ordner 
"jtag" gespeichert ist. Auch das Debuggen funktioniert, wenn man aus der 
flash-elf.cfg die letzten beiden Zeilen
"shutdown
exit"
entfernt. Dann über die "external tools" die flash-elf.cfg ausführen und 
anschließend über Zylin die Datei debug.cfg starten. Dabei hat man 
jedoch folgendes Problem:
Nach Beenden des Debuggens bleibt OpenOCD geöffnet. Es ist kein erneutes 
Flashen möglich ohne zuerst über den Task-Manager "openocd.exe" 
abzuschießen. Dies ist sehr unkomfortabel. Weiß jemand wie man OpenOCD 
nach dem Debuggen aus Eclipse heraus beenden kann ohne den Task-Manager 
zu benutzen? Normalerweiße wird openocd über den Befehl "shutdown" 
beendet. Dies müsste jedoch zuerst nach dem Debuggen ausgeführt werden. 
Wie kann man dies realisieren? Hat jemand einen besseren Vorschlag?

Vielen Dank im voraus!

Autor: Martin Thomas (mthomas) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe das hier so gelöst, dass OpenOCD per external tool einfach nur 
gestartet wird und es zum flashen ein eigenes "debug target" gibt, in 
dem per gdb "load" das Programm übertragen wird. Dann kann OpenOCD im 
Hintergrund einfach dauernd laufen. Ich nutze per STM32 keine 
selbstgebastelten Config-files mehr. Alles Notwenige war in der 
Target-Library und man kann die Dateinamen per -f beim Start übergeben.

Einstellungen sind hierin enthalten:
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm...
Möglicherweise brauchbar als Vorlage. In der Einstellung für den OpenOCD 
Start (external tools) muss noch der Name der Config-Datei für das 
verwendete Interface angepasst werden (Einstellung im Packet ist für 
Amontec JTAGkey(2))

Autor: DJ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Martin,

könntest du eventuell mal die Files hochladen, welcher du per -f beim 
Start übergibst?

Autor: Martin Thomas (mthomas) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dateien sind im Archiv zum genannten Link enthalten 
(project/openocd/lib/openocd/target bzw .../interface. Ansonsten: 
http://openocd.git.sourceforge.net/git/gitweb.cgi?... 
--> tcl/interface bzw. tcl/target

Autor: Olli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für die Linux-Fraktion:
http://wiki.rcos.eu/index.php/RCOS-LiveCD (inkl. ARM-Cortex-M3 Compiler 
/ bootloader)

Autor: DJ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

kann mir jemand sagen wofür Yargato Tools genau ist? Ich habe die 
bereits beschriebene Toolchain eingerichtet. Es funktioniert soweit auch 
alles. Allerdings brauche ich Yargato Tools und weiß nicht wofür. Kann 
mir jemand helfen?

Autor: Uwe Hermann (uwehermann) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, bissl spät, aber da der Artikel nunmal "Opensource Entwicklungstools 
für STM32" heisst: libopenstm32 
(https://sourceforge.net/projects/libopenstm32) ist eine Open-Source 
(GPLv3+) Library (als Alternative zur proprietären ST Firmwarelib) die 
sich derzeit in Entwicklung befindet.

Das sollte Open-Source/Open-Hardware Projekten eine saubere Möglichkeit 
geben mit STM32 zu arbeiten ohne von der proprietär lizensierten ST Lib 
abhängig zu sein.

HTH, Uwe.

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uwe Hermann schrieb:
> Das sollte Open-Source/Open-Hardware Projekten eine saubere Möglichkeit
> geben mit STM32 zu arbeiten ohne von der proprietär lizensierten ST Lib
> abhängig zu sein.

Ähm, wozu soll das gut sein?

Die bezeichnng "proprietär" im zusammenhang mit einer Lib die nur für 
die Prozessorfamilie eines Herstellers gedacht ist ist wohl ein bisschen 
fehl am Platz.

Die ST Standard Peripheral Lib kommt direkt on den Leuten die den 
Prozessor wohl besser kennen als irgendwer sonst. Sie wird ständig an 
neue Proezzoren angepasst.

ST stellt sie kostenfrei zur Verfügung.

Also wozu die Anstrengung für ne open source lib.

Open source als selbstzweck bringt keinem was

Tom

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.