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...
Ist der Treiber ok? St-link_v2_usbdriver.exe und läuft stm32 st-link utility v3.1.0.exe ?
Wie erwähnt: mit STM32 Software (d.h. genau STM32 ST-LINK Util.exe v3.2.0) habe ich programmieren können.
Bei mir hat es manchmal geholfen, zu Beginn der Verbindungsaufnahme die RESET Taste zu drücken. arbeite aber mit COOCox.
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)
So, Problem gefunden: Der GDB mag keine Leerzeichen im Verzeichnispfad. Lösung: keine Leerzeichen Jetzt gehen auch Breakpoints.
> monitor reset halt Das sollte man besser "monitor reset init" nehmen. > load > monitor reset run Versuche mal:
1 | monitor reset init |
2 | load |
3 | monitor reset halt |
4 | thbreak main |
5 | continue |
Ansosnten hat OpenOCD umfangreiche Debug-Ausgaben, die eventuell weiter helfen könnten.
Ein Tipp: Für den STM32 gibt es ein fertig konfiguriertes Code Blocks namens EM::Blocks. http://www.emblocks.org
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_nogate Christian 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
1 | openocd -f custom_board.cfg |
seine custom_board.cfg ausführen, oder per
1 | openocd -f interface/stlink-v2.cfg -f target/stm32f4x.cfg |
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
1 | openocd.exe -f ..\scripts\interface\stlink-v2.cfg -f ..\scripts\target\stm32f1x.cfg |
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.
Angehängte Dateien:
-
2017-08-22_20-26-20.png
170 KB
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:
1 | c:\Program Files (x86)\EmBitz\1.11\share\EmBitz\debuggers\Interfaces\openOCD\settings.xml |
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.
Angehängte Dateien:
-
Unbenannt.JPG
90 KB
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.
Angehängte Dateien:
-
2017-08-22_22-13-57.png
70 KB
Also auch wenn ich einen externen OpenOCD 0.10.0 benutze geht es. Dann muss ich aber eine cfg anwählen die es da auch gibt.
Angehängte Dateien:
-
Unbenannt.JPG
98 KB
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.
Angehängte Dateien:
-
2017-08-22_22-35-48.png
37 KB
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).
Angehängte Dateien:
-
Unbenannt.JPG
77 KB
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.
Angehängte Dateien:
-
2017-08-22_23-12-24.png
49 KB
funktioniert. Blöd ist nur das die Makros "\" in den Namen liefern und OpenOCD "/" haben möchte.
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
Openocd mag die backslashes im Dateinamen nicht, schrieb ich doch.
Johannes S. schrieb: > Openocd mag die backslashes im Dateinamen nicht, schrieb ich doch. Klappt aber alles, wenn man händisch einträgt :-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.