Hallo Kollegen,
ich möchte von CooCox IDE auf Code Blocks umstellen um STM32 Controller
zu Programmieren. Hier habe ich das STM32-discovery (F100) und seit
kurzem das STM32F429I-DISCO. Aber im folgenden gehe ich vom
STM32-discovery aus. Ich verwende Windows XP. Firmware update mit
ST-LinkUpgrade.exe habe ich auch gemacht.
Code-Blocks mit GCC habe ich relativ schnell am Laufen gehabt und mit
der Programmiersoftware von ST konnte ich das HEX problemlos über das
onboard STLINK V1 einspielen (VID=0483, PID=3744).
Den Gnu-Debugger habe ich jedoch nicht zum Laufen gebracht. Es scheitert
immer daran, dass der GDB-Server eine Verbindung zum Board aufbauen
kann.
Probiert habe ich
- OPENOCD_0.7.0 mit der config stm32vldiscovery.cfg
- STLINK_gdbserver aus dem Atollic TrueSTUDIO
- ST-UTIL von texane
Da STLINK sich als USB Massenspeicher anmeldet habe ich zuerst den
LIBUSB-Filter installiert (ohne Verbesserung) und jetzt zum Schluss eine
LIBUSB inf mir erzeugen lassen und damit den Treiber vorgegeben.
Funktioniert auch nicht.
Deshalb stelle ich nun drei Fragen an euch:
- Hat jemand das STM32-Discovery mit einem gdb-server unter Windows
(XP) am laufen?
- Wenn ja, was mach ich falsch?
- Beobachtet ihr auch das Phänomen, dass es im Bereich der Toolchains
instabil und unzuverlässig wird sobald USB in der Kette ist.
Ich erinnere mich zurück an 2003 (oder 04). Mein erster MSP430 auf
Lochraster mit LPT JTAG aufgebaut, GDB angeworfen auf Win98,
eingespielt, und geht ohne vorher zu wissen ob der Controller einen
Fehler hat, LPT falsch angeschlossen ist oder eine Firewall den GDB
blockiert).
10 Jahre später 2013 bekommt man kein Binary rein obwohl es ein fertiges
Eval-Board ist, die Firewall abgedreht ist und man aus 3 GDB Quellen
auswehlen kann. Nebeneffekt: Man macht es Mitarbeitern schwer in Firmen
Open-Source-Software vorzuschlagen.
Korrektur: STLINK_gdbserver dürfte sich erfolgreich verbinden, schmiert
aber ab wenn GDB Verbindung eingeht.
Ausgabe:
Atollic TrueSTUDIO gdbserver for ST-Link. Version 1.8.0 Pro
Copyright 2010-2013, Atollic AB.
Starting server with the following options:
Persistant Mode : Enabled
LogFile Name : debug.log
Logging Level : 31
Listen Port Number : 61234
Status Refresh Delay : 15s
Verbose Mode : Disabled
SWD Debug : Enabled
Connecting to the ST-Link Debugger... OK
Waiting for debugger connection...Error while waiting for debugger
connection, error 37.
Shutting down...
Debugger connection lost.
Shutting down...
Hallo,
das Treiberproblem habe ich lösen können:
wie in openocd-0.7.0/drivers/libusb-1.0 drivers.txt beschrieben muss der
libusb Treiber mit der Zadig Software installiert werden.
Einspielen der Firmware über openocd klappt auch so halbwegs. Mit dem
GDB die Ausführung stoppen geht. Der Curser steht dann an der gestoppten
Stelle und man kann auch mit Einzelschritten weiterarbeiten.
Was jedoch nicht geht sind Breakpoints. Das Programm bleibt einfach
nicht dort stehen. Openocd macht aber auch keine Ausgaben, dass
Breakpoints eingegangen wurden.
Kennt jemand dieses Problem? Ich weiß auch gar nicht ob Code-Blocks
überhaupt die Breakpoints weitergibt. Wie kann ich das überprüfen?
PS: Wireshark funktioniert hier nicht und kann so die Kommunikation zw.
GDB und openocd nicht überprüfen :-)
Bei den GDB Befehlen habe ich nach dem Verbindungsaufbau folgende
Sequenz:
monitor reset halt
load
monitor reset run
Das sorgt dafür dass der uC gestoppt. Die Software eingespielt und der
µC wieder neu gestartet wird. Nur wie bereits geschildert gehen
Breakpoints nicht.
Kompilieren tu ich wie folgt:
arm-none-eabi-gcc.exe -mthumb -O -Wall -g -fno-common -mcpu=cortex-m3
-O -g -Isrc -Ih -c blinky.c -o default\blinky.o
arm-none-eabi-g++.exe -o default\stm32discovery.elf default\blinky.o
-Tstm32.ld -nostartfiles
Output size is 34.98 KB
Running project post-build steps
arm-none-eabi-objcopy -Obinary default/stm32discovery.elf
default/stm32discovery.bin
Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 0 warnings (0 minutes, 0 seconds)
Ich möchte lieber das Original verwenden.
Ein Kollege hat emBlocks probiert und hat das Debuggen nicht
hinbekommen.
Eigentlich ist die Konfiguration gar nicht so viel Aufwand. Stehen tut
sie nirgends. Wenn ich ein großes Projekt auf Code::Blocks erfolgreich
umgestellt habe werde ich mir die Mühe machen und einen Beitrag/Artikel
dazu machen.
Ich benutze emblocks mit dem Board und anderen St Boards ohne Probleme.
Keine Ahnung was dein Kollege hatte, vielleicht hatte er noch eine
ältere Version benutzt.
Weinga Unity schrieb:> - STLINK_gdbserver aus dem Atollic TrueSTUDIO
Hast du das standalone ohne Atollic TrueSTUDIO zum Laufen bekommen?
Anscheinend geht das nur bis V1.4.1., probiert habe ich es aber nicht.
Hallo Micha,
da es schonwieder eine Weile her ist kann ich mich nicht mehr erinnern
ob ich das mit STLINK_gdbserver zum Laufen gebracht habe oder nicht.
Ich habe jedenfalls eine Konfiguration mit openocd hinbekommen.
openocd-0.7.0.exe -f ..\scripts\board\stm32vldiscovery.cfg
GDB-after connection Einstellungen:
monitor reset halt
load
monitor reset run
Wichtige Compiler-Options:
-g3
Nicht vergessen: mit dem zadig tool den WinUSB Treiber installieren.
Weinga U. schrieb:> Ich habe jedenfalls eine Konfiguration mit openocd hinbekommen.>> openocd-0.7.0.exe -f ..\scripts\board\stm32vldiscovery.cfg
Falls Du hier noch mitliest... kannst Du mir diese Konfiguration mal
genau nennen? Jeden Eintrag? Und wenn es geht so dass er für alle
Projekte gilt, also die speziellen Makros enthält von EmBlocks / EmBitz.
Ich arbeite nicht mit emBitz sondern mit Code::Blocks direkt.
Ich habe folgende config für openocd zum Debuggen in Verwendung:
# This is an STM32F4 discovery board with a single STM32F407VGT6 chip.
# http://www.st.com/internet/evalboard/product/252419.jsp
source [find interface/stlink-v2.cfg]
source [find target/stm32f4x.cfg]
# use hardware reset, connect under reset
reset_config srst_only srst_nogate
Dem GDB werden folgende Befehle mitgegeben:
monitor reset halt
monitor reset init
symbol-file myfile.elf
load myfile.elf
tbreak main
monitor reset halt
continue
Ich finde, es müsste mal jemand eine ordentliche Code::Blocks Anleitung
mit Templates für die gängigen STMs machen.
Oder auch AVR oder sonst was.
Wenn man das Scripten könnte, dass so ein Projekt automatisch angelegt
wird, wäre das auch super. Nur habe ich mich damit überhaupt noch nicht
beschäftigt.
Code::Blocks ist in EmBitz aufgegangen. Da sieht da deutlich anders aus
aber die gdb Konfiguration ist erhalten geblieben. Bloss ist der Support
für EmBitz sowas von beschissen, dass es da gar nichts drüber gibt. Ich
will mich nicht mit dem äußerst komplexen und kryptischen Interface
eines Kommandozeilen Debuggers befassen müssen, das muss die IDE tun den
zu bedienen und das auch darzustellen.
Christian J. schrieb:> das muss die IDE tun den> zu bedienen und das auch darzustellen
Naja, ist etwas schwierig zu gestalten, denn Code::Blocks hat ja keine
Anhnung, mit welchen GDB der Benutzer das Programm bedienen will. Somit
ist die Kommandozeile der kleinste gemeinsame Nenner.
Lg.
Weinga U. schrieb:> monitor reset halt> monitor reset init> symbol-file myfile.elf> load myfile.elf> tbreak main> monitor reset halt> continue
Das hilft mir jetzt leider auch nicht weiter, da ich nicht weiss wo es
eingetragen werden muss und was "source [find interface/stlink-v2.cfg]
bedeutet." Und wo da was mitgegeben wird. Da sind zig Fenster wo was
eingestellt werden kann. Im Debug Mode aber auch beim Release Flashen.
Weinga U. schrieb:> Naja, ist etwas schwierig zu gestalten, denn Code::Blocks hat ja keine> Anhnung, mit welchen GDB der Benutzer das Programm bedienen will. Somit> ist die Kommandozeile der kleinste gemeinsame Nenner
Bei Embitz ist er mit drin, kann auch ausgewählt werden aber die openocd
Version von 2014 schmiert einfach mit einer Schutzverletzung ab unter
Win7, daher habe ich sei durch eine 2017er ersetzt. Aber mehr als ein
kurz aufblinkendes Dos Fenster sieht man nicht und auch nicht wo es
hakt. Für STLINKV2 sind diese Parameter dokumentiert, es sind ellenlange
Zeilen mit Platzhaltern, so dass das Projekt nicht einzeln angelegt
werden muss. Einmal eingestellt gilt es für alle projekte.
Sicher ist das Interface wichtig, aber die eigentliche Kommunikation,
die sehr komplex ist muss die IDE übernehmen. Openocd hat hunderte von
Befehlen, die nur Insider verstehen, kann ganze Skripte verarbeiten. Ich
sehe nur den gelben Balken und Watches etc.
EmBitz ist insgesamt aber sehr schlecht dokumentiert, da ist das keine
Ausnahme.
Weinga U. schrieb:> # This is an STM32F4 discovery board with a single STM32F407VGT6 chip.> # http://www.st.com/internet/evalboard/product/252419.jsp>> source [find interface/stlink-v2.cfg]>> source [find target/stm32f4x.cfg]>> # use hardware reset, connect under reset> reset_config srst_only srst_nogate
Diese Zeilen stehen in einer eigenen debug.cfg Datei in dein
Projektordner.
Diese Datei wird mit openocd geöffnet "openocd -f debug.cfg" und somit
verbindet sich openocd einmal mit dem µC. Der GDB von Code::Blocks
verbindet sich dann mit dem "openocd GDB-Server", schickt die Befehle
Weinga U. schrieb:> monitor reset halt> monitor reset init> symbol-file myfile.elf> load myfile.elf> tbreak main> monitor reset halt> continue
an den Server und schon kann man debuggen.
Wie gesagt: Code::Blocks
Weinga U. schrieb:> Wie gesagt: Code::Blocks
Ok, heute abend mal gucken.... EmBitz wird künftig eh kostenpflichtig
werden, da die Programmierer nicht mehr umsonst arbeiten wollen. Wurde
schon angekündigt auf der Webseite. Die svd Files für den Debugger gibts
nicht mehr umsonst. CodeBlocks ist ja viel universeller aber schwerer zu
konfigurieren.
Kannste mal die ganze .cfd Datei hier hochladen? Damit ich sie als
Vorlage nehmen kann? myfile.elf zB ist aber bei jedem Projekt anders.
Christian J. schrieb:> Code::Blocks ist in EmBitz aufgegangen.
Nein ist es nicht. EmBitz ist ein Fork von Code::Blocks. Code::Blocks
gibt es auch noch weiterhin, nur gibt es da eben keine
Konfigurations-Wizards für Mikrocontroller, wo dann im Hintergrund alles
vollautomagisch eingestellt wird.
Christian J. schrieb:> Kannste mal die ganze .cfd Datei hier hochladen? Damit ich sie als> Vorlage nehmen kann? myfile.elf zB ist aber bei jedem Projekt anders.
Das hat er doch schon:
Weinga U. schrieb:> # This is an STM32F4 discovery board with a single STM32F407VGT6 chip.> # http://www.st.com/internet/evalboard/product/252419.jsp>> source [find interface/stlink-v2.cfg]>> source [find target/stm32f4x.cfg]>> # use hardware reset, connect under reset> reset_config srst_only srst_nogateChristian J. schrieb:> Sicher ist das Interface wichtig, aber die eigentliche Kommunikation,> die sehr komplex ist muss die IDE übernehmen. Openocd hat hunderte von> Befehlen, die nur Insider verstehen, kann ganze Skripte verarbeiten. Ich> sehe nur den gelben Balken und Watches etc.
Dann wird es aber endgültig mal Zeit, dass du auch zu einem "Insider"
wirst. Mein Gott das ist wirklich kein Hexenwerk und wer im Stande ist
einen Mikrocontroller zu programmieren, der wird wohl auch noch mit den
drei OpenOCD-Befehlen zurechtkommen.
Bei OpenOCD gibt ein Verzeichnis "scripts" (welches sich unter Windows
im gleichen Verzeichnis wie die openocd.exe befindet). In diesem
Verzeichnis gibt es unter anderem drei Unterverzeichnisse:
"interface","target" und "board". Im Verzeichnis "interface" gibt es
.cfg-Dateien für die einzelnen Debugadapter, z.B. stlink-v2.cfg oder
stlink-v2-1.cfg und in "target" gibt es .cfg-Dateien für die
entsprechenden Controller, z.B. stm32f1x.cfg, stm32f4x.cfg, usw. Jetzt
gibt es noch die Möglichkeit aus so einem .cfg-Skript ein anderes Skript
auszuführen, was durch
1
source [find interface/stlink-v2.cfg]
2
source [find target/stm32f4x.cfg]
gemacht wird. Mal angenommen es stehen nur diese beiden Befehle in einer
custom_board.cfg, dann kann man (unter Linux) entweder per
sich die custom_board.cfg komplett sparen. "-f [datei]" heißt also
einfach nur führe das Skript aus.
Unter Windows sollte dann die Befehlszeile für einen ST-Link V2 mini mit
STM32F1xxx einfach nur folgendes sein
Die Zeile von Weinga mit der reset_config darfst du übrigens bei einem
ST-Link V2 mini so nicht übernehmen, weil da keine Reset-Leitung für SWD
vorhanden ist. Bei mir funktioniert es prima wenn ich das einfach weg
lasse.
Christian J. schrieb:> Damit ich sie als> Vorlage nehmen kann? myfile.elf zB ist aber bei jedem Projekt anders.Weinga U. schrieb:>> symbol-file myfile.elf>> load myfile.elf
Man muss dem GDB normalerweise nicht den Dateinamen mitgeben, weil GDB
von der IDE normalerweise mit dem Dateipfad als Argument gestartet wird.
Dann braucht es nur noch ein "load". Als GBD-Init wäre also das folgende
meiner Meinung nach ausreichend:
1
monitor reset halt
2
load
3
monitor reset halt
Die Zeilen die mit "monitor" beginnen schickt GDB (ohne "monitor")
direkt an den GDB-Server (also in dem Fall OpenOCD) weiter und "load"
bringt GDB (via OpenOCD und ST-Link) dazu die Datei ins Flash zu
befördern.
Aber weil man ja sowieso fehlerfrei programmiert, brauch ich die
Debug-Variante nicht und hab mir eine reine Flash Funktion geschrieben,
die wesentlich schneller geht.
Ich hab mir ein Code::Blocks einen Tooleintrag mit der Befehlszeile
openocd -f flashV2.cfg
gemacht, wobei in der flashV2.cfg folgendes steht:
# This is an STM32F4 discovery board with a single STM32F407VGT6 chip.
# http://www.st.com/internet/evalboard/product/252419.jsp
source [find interface/stlink-v2.cfg]
source [find target/stm32f4x.cfg]
init
reset halt
targets
flash write_image erase myfile.elf
verify_image myfile.elf
reset run
shutdown
Christopher J. schrieb:> Bei mir funktioniert es prima wenn ich das einfach weg> lasse.
Das korrekte OpenOCD Kommando wäre:
1
reset_config none
Damit kann man auch abweichene Reset Configs überschreiben.
Weinga U. schrieb:> brauch ich die> Debug-Variante nicht und hab mir eine reine Flash Funktion geschrieben,> die wesentlich schneller geht.
Komisch, bei mir ist GDB load fast völlig identisch im Flash Speed.
Kann es sein dass Du OpenOCD im "Pipe" Modus betreibst
(target remote|openocd ...)?
Das ist unter Windoof arschlahm, TCP/IP ist um Größenordnungen
schneller. Das ist kein OpenOCD Problem sondern die hirntote Pipe
Implementation in Windoof selbst.
Das Bespielen ist schon gleich schnell,
nur beim Flash wird openocd gestartet, geflasht und wieder beendet.
Beim Debuggen muss ich erst openocd starten. Dann anschließend den Debug
Pfeil drücken, warten bis die Main angesprungen wird und dann Continue
drücken.
So habe ich ein Single-Click flaschen.
Leider habe ich es nicht hinbekommen, dass bei Code::Blocks über den
"Run" Pfeil automatisch geflascht wird. Er versucht immer die elf-Datei
am PC zu starten :-)
Lg.
Meine ST Targets verstauben gerade etwas im Schrank, ich erinnere mich
aber das man zum flashen von 8- auf 32 Bit Übertragung umschalten
konnte. Das Flashen ging damit auch rund 4mal schneller, was gerade bei
den fetten F4/F7 angenehm ist.
Ok, ich muss mir das mal zu Hause in Ruhe durchlesen, da ich noch immer
nicht weiss, wie ich die vielen Felder ausfüllen muss. Vor allem weil
ich keinerlei Rückmeldung habe wenn was nicht klappt.
Ich vermute mal, dass man cmd aufrufen muss unter Windows und den Server
da ausdrücklich starten muss. Und nein, es soll nur funktionieren und
ohne Debuggen geht es gar nicht, nur flashen reicht nicht, das wäre ja
nur Trial & Error. Mit dem STLINKV2 geht das flashen der großen 4er sehr
schnell, das der kleinen dauert leider länger, knapp 6-10 Sekunden bei
mir.
In der sog. Toolbox von Embitz muss alles manuell eingestellt werden mit
vordefinierten Makros, die die Pfade, Dateinamen etc enthalten. So dass
draus eine komplette Kommandozeile wird, wie bei stlinkv2 auch. Der
Server wird automatisch gestartet mit der IDE, zumindest wenn der Pfad
stimmt.
ich bin auch neugierig geworden und habe EmBitz mal installiert (auf
Win7 64 Bit). Dazu das aktuelle STLinkUtility 4.1. Dann ein mbed Projekt
für Bluepill nach EmBitz exportiert und in EmBitz importiert. Einen
bekannten Compilierfehler musste ich beheben, dann lief das durch.
In Debug/Interfaces OpenOCD ausgewählt, in Settings kein board, den
STLink V2 (habe nur einen 5$ China Clone) und Target STM32F1_stlink
ausgewählt. F8, flashen und debugging laufen, LED blinkt. Hat keine 10
min gedauert, nicht schlecht.
Ich mag es aber lieber kompliziert und bleibe bei Eclipse IDEs :-)
Johannes S. schrieb:> In Debug/Interfaces OpenOCD ausgewählt, in Settings kein board, den> STLink V2 (habe nur einen 5$ China Clone) und Target STM32F1_stlink> ausgewählt. F8, flashen und debugging laufen, LED blinkt. Hat keine 10> min gedauert, nicht schlecht.
WAAAAAAAASSSSSSSSSSSS ????????? ..... herzklabaster....
Bei mir flashed da nur die DOS Box auf und wieder zu und irgendeine
Meldung, dass der Debugger mit Fehlercode 1 beendet wurde. EmBitz finde
ich nämlich echt genial, auch wenn der Editor nicht die features hat, zb
nicht immer die Ergänzung von structs etc zeigt, die möglich sind. Der
Parser hat da wohl ne Macke. CooCox bietet da mehr, zb ausgrauen von
nicht aktivierten Defines, dafür aber ist es schweinelangsam.
Kannste bitte mal Screenshots schicken? Ich habe auch diese
China-Stäbchen als STLINK V2 und diese BluePill Boards......
Bitte bis heute abend, ja? Und ob Openocd bei dir die neue Version ist
oder die bei EmBitz dabei war?
Und das flashen muss ja in zwei Boxen eingetragen werden, in die Debug
Boxen und in die Toolbox für den Release. Die Toolbox ist komplett
"manuell" und nicht ganz trivial.
Kann mir gar nicht vorstellen, dass das das OCD einfach so läuft...
Bin gerade unterwegs, Screenshots gehen erst später.
Openocd war die alte Version von 2014 die embitz mitbringt. Und
Einstellungen waren nur die zwei Beschriebenen. Target STM32f103_stlink
war wichtig, ohne das _stlink hat sich das Cmd Fenster auch sofort
beendet.
Was nicht ging war der 128 kB Patch, das probing kann der ältere OOCD
vlt. noch nicht.
so, habe noch ein bisschen probiert.
Was nicht geht:
eine neuere Version vom OOCD in die vorhandenen Verzeichnisse von EmBitz
zu packen, damit startet der Debugserver nicht, warum, keine Ahnung.
Was geht:
in Debug/Interfaces den Pfad auf eine neuere OOCD Version eintragen,
aber das ist nicht unbedingt nötig. Es gibt scheinbar nur eine neuere,
es hat sich 1,5 Jahre nichts geändert. EmBitz bringt eine V0.9.0 mit,
die ist aber anders als die von F. Chopin fertig kompilierte. Aber das
Feature das du haben möchtest ist in der EmBitz Version auch schon drin.
Um die 128 kB des F103C8 zu nutzen muss nur die config in
\openocd\scripts\target angepasst werden. Dazu am besten eine
zusätzliche config mit den fixen 128 kB anlegen damit man für andere F1
noch die Automatik hat (ist im Anhang).
Damit EmBitz diese Config auch im Dialog anzeigt muss noch diese xml
Datei angepasst werden:
Ich habe in meinem Testprogram eine Optimierung ausgeschaltet und so die
Codegrösse auf über 100 kB aufgeblasen. Das wird mit dieser Änderung
anstandlos geladen und im Debugger gestartet.
Alles so gemacht, bis auf die 128kb, das verdammte Fenster schliesst
sich sofort wieder. Muss man da noch was manuell starten in der Dos Box?
Das steht in dieser cfg drin:
echo "WARNING: target/stm32f2x_stlink.cfg is deprecated, please switch
to target/stm32f2x.cfg"
source [find target/stm32f2x.cfg]
nö. Aber der Server verarbschiedet sich auch sofort wieder wenn er den
STLink nicht findet. Also eventuell noch ein Treiber Problem oder
Firmwareproblem mit dem STLink? Ich habe wie geschrieben vorher noch das
STLinkUtility installieren müssen.
Naja, der STLINK funktioniert ja wenn ich ihn anwähle..... also mit
STLINKV2 Option. Sorry, aber ich habe von PC und Skripten absolut keine
Ahnung, Null sozusagen. Mich nie mit befasst, PC ist nur Werkzeug,
nichts weiter. Außer unter Linux natürlich :-)
Christian J. schrieb:> echo "WARNING: target/stm32f2x_stlink.cfg is deprecated, please switch> to target/stm32f2x.cfg"
das steht bei mir in den neueren OOCD files drin, nicht in den von Em
installierten. Hast du eventuell die originalen überschrieben? Ich habe
das EmBitz von der Homepage ohne irgendwelche Updates installiert.
Habe die Version 1.11.... und die neue OpenOCD, da die alte mit
Schmutzverletzung abschmierte. Und wie man sieht findet stlink seine
Hardware.
Ok, alle Treiber versucht nachzuinstallieren. Nüscht! ich gebs auf, mir
fehlt der Nerv mich damit jetzt noch ewig zu befassen, nur wegen der
128kb.
Mir fällt das Essen aus dem Gesicht..... nochmal die alte Version
probiert und
DAS SCHEISS DING GÄÄÄÄÄÄHT! 200 Puls hob isch :-)
Aber erheblich langsamer beim Steppen als der ST-Link, der war fast
verzögerungsfrei. Und ich habe schon einen Gamer PC mit Octacore....
Jetzt nur noch die 128kb Geschichte hinbasteln.... auch fertig mit
deinen Dateien. Jetzt bin ich aber mal gespannt ..... mal den Code etwsa
aufblasen.
blöd ist in der Tat das man keine Meldung bekommt. Es gibt aber eine log
Option die man in 'additional Arguments' setzen kann (forward slash ist
wichtig, sonst sieht man gar nix).
110kb erfolgreich gebrannt ! im Debug Mode. Jetzt muss ich nur noch
rauskriegen, wie man diese Toolbox konfiguriert für den Release Mode.
Denn das ist Handarbeit.
Bei mir läuft es noch nicht :-( Vermutlich das gleiche Problem, wie die
Ausgabe vermuten lässt. Habe den Pfad daher manuell eingetragen, anders
geht es wohl nicht. Und der reset klappt nicht, da swd keine Reset
leitung hat.
Die Debug Geschwindigkeit liegt leider deutlich unterhalb der von
STLINK, weswegen ich es erstmal nu nutze, wenn ich die 64kb wieder
sprenge. Nach xprinft Verwendung liege ich nämlich wieder drunter.
Launching tool 'OpenOCD': C:\Program Files
(x86)\EmBitz\1.11\share\contrib\openocd\bin\openocd.exe -f
interface/stlink-v2.cfg -f target/stm32f1x_128kB_stlink.cfg -c "program
K:\STM32F100\f103_LED_Display\bin\Release\f103.hex" (in
K:\STM32F100\f103_LED_Display\bin\Release)
stderr> Open On-Chip Debugger 0.9.0-dev-00092-g287d6e0-dirty
(2014-07-15-06:09)
stderr> Licensed under GNU GPL v2
stderr> For bug reports, read
stderr> http://openocd.sourceforge.net/doc/doxygen/bugs.html
stderr> Info : This adapter doesn't support configurable speed
stderr> Info : STLINK v2 JTAG v25 API v2 SWIM v4 VID 0x0483 PID 0x3748
stderr> Info : using stlink api v2
stderr> Info : Target voltage: 3.252485
stderr> Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
stderr> target state: halted
stderr> target halted due to debug-request, current mode: Thread
stderr> xPSR: 0x01000000 pc: 0x08002c60 msp: 0x20005000
stderr> ** Programming Started **
stderr> auto erase enabled
stderr> Error: Invalid command argument
stderr> image.base_address option value ('103_LED_DisplayinRelease') is
not valid
stderr> ** Programming Failed **
stderr> shutdown command invoked
Tool execution terminated with status 0