Hallo Community. Man stolpert ja nun immer oefter ueber die ARM-Controller und das Interface wie Code auf diese programmiert/debuggt wird: Single Wire Debug. Kennt jemand von euch ein (gutes) Open Source Projekt fuer einen SWD Programmer - moeglichst Selbstbau geeignet. (Am schoensten waere, wenn ich mir hier schnell was mit einem AVR zusammen zimmern koennte.) Fuer die AVRs (ISP) gab es ja seiner Zeit den USBasp - ggf. gibt es sowas auch fuer SWD? MfG Stephan
Lohnt sich das? Für < 10 EUR gibt es das STM32F0Discovery. Wenn du nu nicht Debuggen willst: die meisten ARM-Controller haben einen BSL über UART.
Hallo Antimedial schrieb: > OpenOCD? Danke dir, das werde ich mir einmal ansehen. greg schrieb: > Lohnt sich das? Für < 10 EUR gibt es das STM32F0Discovery. Ich habe hier ein paar Samplechips die ich gern testen wuerde. Gibt es ggf. noch mehr Optionen? MfG
Stephan B. schrieb: > Hallo > > Antimedial schrieb: >> OpenOCD? > > Danke dir, das werde ich mir einmal ansehen. > > greg schrieb: >> Lohnt sich das? Für < 10 EUR gibt es das STM32F0Discovery. > > Ich habe hier ein paar Samplechips die ich gern testen wuerde. > > > Gibt es ggf. noch mehr Optionen? Für 20 Euro einen reinen ST-Link kaufen. Der kann auch SWD. Aber es stimmt schon, kauf lieber ein Eval Board, ist günstiger und hat auch einen ST-Link drauf.
Ist zwar kein SWD aber was solls: google -> wiggler jtag
holger schrieb: > wiggler jtag Das ist der steinalte Frickelport-Adapter. Wir haben mittlerweile 2014, da sollte man sich so etwas nicht mehr antun müssen.
@Stephan Was für einen µC hast Du überhaupt? der ST-LINK geht nur mit den STM32 / STM8 µC von ST! Ansonsten bei OpenOCD in der Doku nachlesen welche JTAG Adapter der unterstützt. Ich meine da sind auch OpenSource-Adapter dabei. Empfehlen würde ich dazu allerdings nicht, besser einen Segger J-LINK EDU für 50€ kaufen. Der hat auch ordentliche Software dabei und der funktioniert mit so gut wie allen IDE's und arbeitet sehr zuverlässig.
:
Bearbeitet durch User
OpenOCD hat sehr gute Unterstützung für ST-Link (v2). Damit sollte auch SWD gehen, auf allen Controllern.
Gerd E. schrieb: > https://github.com/gsmcmullin/blackmagic Da gibt es auch mehrere Layouts.. Und fŭr den Umbau von Discovery Boards: http://embdev.net/articles/STM_Discovery_as_Black_Magic_Probe
Markus Müller schrieb: > der ST-LINK geht nur mit den STM32 / STM8 µC von ST! Nach Umbau http://embdev.net/articles/STM_Discovery_as_Black_Magic_Probe auch fŭr weitere Chips (ausser STM8)...
Wieder was dazu gelernt ;-) Das sollte man beachten: "Warning Until now there is no way to go back to the original firmware!"
Markus M. schrieb: > Das sollte man beachten: > "Warning > Until now there is no way to go back to the original firmware!" Ist zwar Leichenfledderei, aber man kommt aktuell doch wieder zurück. WARNUNG : Theoretisch geht noch mehr, aber damit bewegt man sich definitiv über die sehr dunkle Grauzone hinweg in die Illegalität, weil man was flasht, was einem definitiv nicht zusteht. Wahrscheinlich ist auch das wiederherstellen schon illegal: Hier steht wie man an die Firmware-imgaes über das Java-Update-Tool kommt: https://lujji.github.io/blog/reverse-engineering-stlink-firmware/ So kommt man an den ursprünglichen Bootloader: https://lujji.github.io/blog/reverse-engineering-stlink-firmware-part2/ Hier sind schon gedumpte Bootloader: https://github.com/Krakenw/Stlink-Bootloaders Was muss man machen? - Ein passendes FirmwareImage an 0x8004000 flashen - Den Bootloader an 0x8000000 flashen Der St-Link funktioniert so aber noch nicht wieder. Man muss noch das ST-Link-Update-Utility nutzen, um sich eine Firmware für den ST-Link auszusuchen (ja man darf aussuchen - hier bitte die Firmware auswählen, die für euch in Frage kommt): - normaler Stlink V2 von Dicovery boards: Version STM32 (ohne STM8) (getestet) - Stlink V21 von Nucleo-Boards: Version mit STM32 mit MSD (ungetestet mangels Hardware) Jetzt sollte wieder ein funktionierender ST-Link da sein. P.S. Segger bietet eine J-Link-Firmware für die Discoveries/Nucleos (ST-Link V2/V21 für STM32) an: https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/ Damit hat man einen Debugger, der sehr performant ist, einen sehr guten gdbserver(jlinkgdbserver für windows/linux) mitbringt und auch fähig ist beliebig viele Flash-Breakpoinst zu erstellen. Der geht dann aber nur mit STM32-µC. Ich würde diese Lösung wenn es möglich ist stets der Openocd-Frickeladapter-Lösung vorziehen, da es einfach funktioniert und man nicht ewig herum konfigurieren muss, bis man debuggen kann.
1 | JLinkGDBServerCL -singlerun -halt -device stm32f103r8 -if swd -speed 4000 -port 4242 |
Grüße Oliver
Im Netz findet man Firmwareimages für den Stlink. Die Emdev Seite hat Hinweise darauf. Das Image spielt man auf, und dann macht man einen Update und hat wieder die ST Firmware und alles ist wieder "gut" Ueber Kontakt bei ST kommt man evt auch "Boot-Image"
Philipp_K59 schrieb: > Ich habe einen 3€ STLINK Chinaklon für meine STM32. Geht prinzipiell auch, aber mit JLink macht es erfahrungsgemäß mehr Spaß. Man kann deinen ST-Link theoretisch auch zum JLink umflashen (ILLEGAL) - ein paar russische Bastler haben das STLinkReflash gehackt (siehe adelectronics.ru), dass sich normale ST-Links umflashen lassen. Wobei die Chinesen auch JLink-OB für n 5er bei Aliexpress anbieten. Ist wahrscheinlich auch nix anderes. Ich habe mir im Studium mal einen original JLink EDU (kostet um die 50 und kann alle möglichen ARM) gegönnt und bin sehr zufrieden damit bis heute. Kann ich nur jedem empfehlen, das ist eigentlich geschenkt. Mittlerweile gibts den auch im USB-Stick-Format für einen 20er, wobei darauf ein sehr kompakter und unpraktischer Pinheader verwendet wird. Grüße Oliver
:
Bearbeitet durch User
> Geht prinzipiell auch, aber mit JLink macht es erfahrungsgemäß > mehr Spaß. Warum?
>> Geht prinzipiell auch, aber mit JLink macht es erfahrungsgemäß >> mehr Spaß. > >Warum? Der J-Link ist erheblich schneller und stabiler als der ST-Link.
Witzig - unabhängig von diesem Thread habe ich vor einer halben Stunde genau das gemacht was Oliver beschrieben hat (auch per Google findet man die genannten Seiten). Aus dem billig Baite mit 2.0 wurde jetzt ein 2.1. Aber auch nur die Version Stm32 + Audio wie in dem Link beschrieben, was auch immer das Audio da bedeuten soll, es läuft jedenfalls als debugprobe mit VCP. Der ST Updater weigert sich aber die MSD Variante zu flashen weil der C8 zu klein sein soll, der hat aber 128kB. Das wird auch vom stmflash tool gemeldet über das ich den Stick seriell flashen kann. Aber auch das dekodierte bin zu flashen bringt es nicht, der Bootloader schreibt wohl noch eine Konfig für die USB PID/VID. Alternativ könnte man noch einen CMSIS-DAP auf den Stick flashen, DAPLink Projekt, das wird mittlerweile auch gut unterstützt.
> Der J-Link ist erheblich schneller und stabiler als der ST-Link.
Der ST-Link 2.1 arbeite völlig stabil. Mit seiner Geschwindigkeit bin
ich zufrieden. Sowohl das Programmieren als auch das Debuggen geht damit
sehr viel schneller, als bei Atmel Produkten über ISP und Debug Wire.
Stefan U. schrieb: > Der ST-Link 2.1 arbeite völlig stabil. Mit seiner Geschwindigkeit bin > ich zufrieden. Sowohl das Programmieren als auch das Debuggen geht damit > sehr viel schneller, als bei Atmel Produkten über ISP und Debug Wire. Verglichen mit dem Dragon z.B. ist der STLink natürlich performanter, aber das ist hier denke ich kein zweckmäßiger Vergleich, da sich beide nicht untereinander tauschen lassen. BTW: So ziemlich jeder Emulator würde gegen den alten Atmelkram besser abschneiden :D. Hast du JLink schon probiert? Wie ist dein Entwicklungs-setup (OS, IDE, Debugger-SW)? Ich bin mit dem STLink nicht ganz so zufrieden. Man kann damit debuggen - keine Frage, aber gerade wenn man den gdb nutzen möchte, dann muss man sich mit den tools von texane [1] oder openocd rumschlagen (viel Konfiguration notwendig). Es gibt nicht mal einen von ST bereitgestellten gdbserver. Segger hat halt recht gut bedienbares Profiwerkzeug entwickelt und stellt seinen GDB-Server auch für Linux bereit. Eines der Features die ich am meisten mag ist die Möglichkeit der Flashbreakpoints. Das können glaube ich Openocd oder die Software von texane[1] nicht. Was ich am beeindruckensden finde ist, dass man wenn man neueres STM32Discovery-Board (oder Nucleo) hat, legal und kostenlos den stlink auf jlink ob (stm32) umflashen kann. [1] https://github.com/texane/stlink: Hier ist es mit schon oft passiert, dass ich den STLink am USB reconnecten musste, dass ich eine neue gdb-session starten oder wieder flashen konnte. Den JLink musste ich noch nicht einmal abziehen. Aktuelle Entwicklungsumgebeung: - windows 7 - Eclipse Mars.2 mit gdb-hardware-debugging-plugin (hier muss natürlich man auch einiges konfigurieren, aber die launcher lasse ich von nen python-tool gererieren) Grüße Oliver
Oliver J. schrieb: > Eclipse Mars.2 mit gdb-hardware-debugging-plugin Benutz doch das "GNU MCU Eclipse" Plug-in, damit ist das viel einfacher. Damit kann man sich auch Peripherie Register und SWO Ausgabe ansehen. Und Mars.2 ist ja uralt ;-)
> Hast du JLink schon probiert? Nein habe ich nicht. Ich bin beim ST-Link hängen geblieben, der als "kostenlose" Beigabe an einem Entwicklungsboard hing. Mit diesem Teil bin ich wie gesagt absolut zufrieden. Aber klar, wenn man erst einmal etwas viel besseres in der Hand hatte, mag man sicher nicht mehr zurück. Nur habe ich kein Geld zu verschwenden und kaufe mir daher vorläufig keinen J-Link. Das mache ich erst, wenn ich ihn brauche. Geschwindigkeit spielt bei Hobby Projekten ohnehin nur eine untergeordnete Rolle. > openocd rumschlagen (viel Konfiguration notwendig) In der System Workbench ist openocd enthalten und läuft "out of the box". Da muss man gar nichts konfigurieren. > Hier ist es mit schon oft passiert, dass ich den STLink am > USB reconnecten musste Ich habe das Gefühl, dass hier alte Probleme immer wieder kopiert/zitiert werden, um den J-Link zu Promoten. Mit persönlich ist dieses Problem jedenfalls noch gar nicht passiert. Kann es sein, dass du nach dem Wechsel auf J-Link nie wieder aktuelle Versionen des ST-Link+Software ausprobiert hast?
Stefan U. schrieb: > Ich habe das Gefühl, dass hier alte Probleme immer wieder > kopiert/zitiert werden, um den J-Link zu Promoten. Mit persönlich ist > dieses Problem jedenfalls noch gar nicht passiert. > > Kann es sein, dass du nach dem Wechsel auf J-Link nie wieder aktuelle > Versionen des ST-Link+Software ausprobiert hast? Meine Erfahrungen mit den texane-tools basieren auf Firmware und Toolständen von vor ca. 2 Monaten. Openocd habe ich nicht probiert, da ich keine Lust hatte ewig mit der Config runzuspielen ;). Stefan U. schrieb: > Aber klar, wenn man erst einmal etwas viel besseres in der Hand hatte, > mag man sicher nicht mehr zurück. Nur habe ich kein Geld zu verschwenden > und kaufe mir daher vorläufig keinen J-Link. Das mache ich erst, wenn > ich ihn brauche. Das ist ja das schöne für deinen Beigabe-Debugger verschenkt ihn Segger [1]. ;) Und nein ich mache keine Werbung für Segger - Bin einfach nur rundum zufieden mit deren Debuggern. Lassen sich aktuell mit openocd und stlink Breakpoints im Flash erstellen? [1] https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/ Grüße Oliver
Dr. Sommer schrieb: > Und Mars.2 ist ja uralt ;-) Stimmt, aber irgendwie haben die bei Eclipse in neueren Versionen die Möglichkeit entfernt die laufenden Buildprozesse über die IDE zu killen. Zumindest ist es bei mir so unter Windows 7 mit 32-Bit und 64-Bit Eclipse. Das ist unschön, wenn der Prozess aus irgend einem Grund blockiert. Deshalb setze ich auf diesen Dinosaurier. Grüße Oliver
Oliver J. schrieb: > Eines der Features die ich am meisten mag ist die Möglichkeit der > Flashbreakpoints. Auch Segger kocht nur mit Wasser. Das geht mit
1 | asm("bkpt"); |
Oliver J. schrieb: > ein sehr kompakter und unpraktischer Pinheader verwendet wird Der Pin-Header des JLink Edu Mini ist standardisiert, d.h. Pinabstand und Layout. Selbst bei sehr kompakten Platinenlayouts bekommt man den noch irgendwie mit drauf. Für 0.1" Pin benötigt man dann eben einen Adapter.
Christopher J. schrieb: > Auch Segger kocht nur mit Wasser. Das geht mitasm("bkpt"); Klar, aber der Witz ist ja dass der JLink die automatisch auch im laufenden Betrieb setzen kann. Hin und wieder ist __BKPT() aber auch hilfreich ;-)
Angehängte Dateien:
-
Eclipse_Cancel_Build.png
15 KB
Oliver J. schrieb: > Stimmt, aber irgendwie haben die bei Eclipse in neueren Versionen die > Möglichkeit entfernt die laufenden Buildprozesse über die IDE zu killen. Also, bei mir geht das indem ich ganz unten rechts auf das "Show Background operations" Symbol oder auf den "Progress" tab klicke, und dann auf das rote Viereck. Auch in der aktuellen Oxygen.2 Version. Bei mir hat aber auch noch nie der Compiler blockiert...
DIY bei einem Programmer ist schlichtweg Unsinn. Wo steckt der Fehler? Programmer? Code? Schaltung? Interface? Bug? Es ist nicht sinnvoll sich hier Steine in den Weg zu legen indem Fehlerquellen hinzugefügt werden. Zudem kostet ein Programmer wie der Segger J-Link EDU keine 50€...
Egon N. schrieb: > DIY bei einem Programmer ist schlichtweg Unsinn. Nö, warum? Wenn man einen Debugger in seine eigene Schaltung integrieren möchte, dann kann man das z.B. mit der Black Magic Probe machen und das Ding funktioniert auch wunderbar. Einen ST-Link oder J-Link kann man eben nicht ohne erheblichen bürokratischen Aufwand integrieren, es sei denn man kopiert einfach deren Firmware ohne die Erlaubnis zu haben aber dann ist es eben definitiv illegal.
Christopher J. schrieb: > Egon N. schrieb: >> DIY bei einem Programmer ist schlichtweg Unsinn. > > Nö, warum? Wenn man einen Debugger in seine eigene Schaltung integrieren > möchte, dann kann man das z.B. mit der Black Magic Probe machen und das > Ding funktioniert auch wunderbar. Einen ST-Link oder J-Link kann man > eben nicht ohne erheblichen bürokratischen Aufwand integrieren, es sei > denn man kopiert einfach deren Firmware ohne die Erlaubnis zu haben aber > dann ist es eben definitiv illegal. Wozu sollte ich einen Debugger in Hardware in mein finales Produkt verbauen? Dann doch lieber einen Port auf der Platine (ggf. mit Pogopins) für das Debugging vorsehen, fertig aus. Einen weiteren Controller auf der Platine nur für die Entwicklung bezahlt dir kein Kunde.
:
Bearbeitet durch User
Dr. Sommer schrieb: > Also, bei mir geht das indem ich ganz unten rechts auf das "Show > Background operations" Symbol oder auf den "Progress" tab klicke, und > dann auf das rote Viereck. Auch in der aktuellen Oxygen.2 Version. Bei > mir hat aber auch noch nie der Compiler blockiert... Genau das meinte ich. Das geht bei mir nicht. Ich kann zwar draufklicken, aber es wird nicht mehr alles rigoros gekillt. B.t.w.: Ich nutze einen externen Buildprozess und nicht den Managed Build von Eclipse. Aber Mars funktioniert für mich, also habe keinen Bedarf ein neueres hernehmen zu müssen. Grüße Oliver
Dr. Sommer schrieb: > Christopher J. schrieb: >> Auch Segger kocht nur mit Wasser. Das geht mitasm("bkpt"); > > Klar, aber der Witz ist ja dass der JLink die automatisch auch im > laufenden Betrieb setzen kann. Das habe ich gemeint. Ist echt praktisch. Grüße Oliver
Christopher J. schrieb: > Oliver J. schrieb: >> ein sehr kompakter und unpraktischer Pinheader verwendet wird > > Der Pin-Header des JLink Edu Mini ist standardisiert, d.h. Pinabstand > und Layout. Selbst bei sehr kompakten Platinenlayouts bekommt man den > noch irgendwie mit drauf. Für 0.1" Pin benötigt man dann eben einen > Adapter. Stimmt. Aber für den Ottonormal-Bastler ist dieses Rastermaß meines Erachtens ziemlich unhandlich und die benötigten Adapter auf das übliche Rastermaß (glaube 2.56mm) kosten leider einige Euro. Grüße Oliver
Egon N. schrieb: > Wozu sollte ich einen Debugger in Hardware in mein finales Produkt > verbauen? > > Dann doch lieber einen Port auf der Platine (ggf. mit Pogopins) für das > Debugging vorsehen, fertig aus. Weil Du einen Debugger mit einer für Endkunden einfach nutzbaren Schnittstelle (=USB) versehen kannst. > Einen weiteren Controller auf der Platine nur für die Entwicklung > bezahlt dir kein Kunde. Das hängt doch sehr vom Preisverhältnis Platine zu Gesamtkosten der Lösung ab. Wenn es um quasi Einzelstücke geht, die in einer sehr speziellen und nicht so leicht nachzustellenden Gesamtlösung stecken, macht das u.U. schon Sinn. Wenn es Probleme gibt, kann der Entwickler kurz per Fernwartung auf den PC des Kunden und darüber das Programm mit dem Debugger analysieren. Den GDB der Black Magic Probe kann man dabei ganz einfach per SSH weiterleiten.
Oliver J. schrieb: > Aber für den Ottonormal-Bastler ist dieses Rastermaß meines > Erachtens ziemlich unhandlich und die benötigten Adapter auf das übliche > Rastermaß (glaube 2.56mm) kosten leider einige Euro. Adapter auf die standard ARM 20-Pin JTAG Pinouts mit 0.1" Pin-Pitch gibt's bei Olimex für 5€ zzgl. Versand: https://www.olimex.com/Products/ARM/JTAG/ARM-JTAG-20-10/ oder Aliexpress für ~6,50€ inkl Versand: https://www.aliexpress.com/item/Emulator-transfer-board-line-20pin-2-54mm-turn-10pin-1-27mm-JTAG-20p-to-10p/32803739154.html Wie gesagt: Wenn die Platine sehr kompakt ist, ist das mMn die beste Lösung. Der Footprint ist nicht größer als die 4x0.1" Pin-Header welche man typischerweise bei irgendwelchen China-Boards a la BluePill findet, bringt aber neben VCC, GND, SWDIO und SWCLK auch noch einen Reset- und einen SWO-Pin mit. btw: 0,1 Zoll sind 2.54mm (2.56 ist 2^8/100), verwechsel ich auch ständig ;)
Christopher J. schrieb: > Wie gesagt: > Wenn die Platine sehr kompakt ist, ist das mMn die beste Lösung. Leider ist dieser Mini-Stecker nicht verpolungssicher, und beim Olimex-Adapter ist das kleine Flachbandkabel auch abnehmbar, sodass man nachher nicht mehr weiß wie rum es richtig war... Man kann sich höchstens merken dass man die Nase immer auf der Seite mit dem fehlenden Pin einsteckt o.ä. Gerd E. schrieb: > Wenn es um quasi Einzelstücke geht, die in einer sehr speziellen und > nicht so leicht nachzustellenden Gesamtlösung stecken, Dann braucht man auch keinen Bastel-DIY-Adapter, und es empfiehlt sich zumindest mal ein Original-ST-Link... Oliver J. schrieb: > B.t.w.: Ich nutze einen externen Buildprozess und nicht den Managed > Build von Eclipse. Hm, daran könnte es liegen. Vielleicht lässt sich dein Build-Prozess ja nicht auf normale Art abbrechen. Ein normales externes "make" ist jedenfalls auch kein Problem bei mir. Oliver J. schrieb: > Aber Mars funktioniert für mich, also habe keinen > Bedarf ein neueres hernehmen zu müssen. Es funktioniert vermutlich nicht mit der aktuellen "GNU-MCU-Eclipse"-Version, welches das Erstellen von Launch Configurations vereinfachen würde...
Dr. Sommer schrieb: > Christopher J. schrieb: >> Wie gesagt: >> Wenn die Platine sehr kompakt ist, ist das mMn die beste Lösung. > Leider ist dieser Mini-Stecker nicht verpolungssicher, und beim > Olimex-Adapter ist das kleine Flachbandkabel auch abnehmbar, sodass man > nachher nicht mehr weiß wie rum es richtig war... > Man kann sich höchstens merken dass man die Nase immer auf der Seite mit > dem fehlenden Pin einsteckt o.ä. Ja, das stimmt leider für die beiden Adapter. Als quick-and-dirty Lösung kann man den einen Pin welcher nicht benötigt wird abzwicken und diesen beim Kabel jeweils mit Sekundenkleber o.Ä. zuschmieren. Es gibt die Stiftleiste allerdings auch in einer Verpolungssicheren Variante. TI macht das bei deren Adapter so, der übrigens mit 10$ auch nicht sonderlich teuer ist: http://www.ti.com/tool/MSP-FET-432ADPTR Der Verpolungssichere Stecker ist ein FTSH-105-01-F-DV-K von Samtec: https://www.digikey.de/product-detail/de/samtec-inc/FTSH-105-01-F-DV-K/SAM8796-ND/2649974 Für verschiedene Varianten (PnP, TR) siehe https://www.samtec.com/products/ftsh Leider nicht ganz billig das Teil.
> Lassen sich aktuell mit openocd und stlink Breakpoints > im Flash erstellen? Ich weiss nicht was du mit "im Flash" meinst. Jedenfalls kann ich programme, die aus dem Flash heraus ausgeführt werden debuggen indem ich Haltepunkte setze. Meinst du das, oder was anderes? Das Einzige, was ich vermisse, ist die Möglichkeit, beim Debugging ITM (SWO) Meldungen anzuzeigen. Keil kann das angeblich, die System Workbench leider nicht. Das ST-Link Utility zeigt sie an, aber das kann ich schlecht während des Debuggens mit laufen lassen. Kann die J-Link Firmware für ST-Link ITM Meldungen beim Debuggen in der System Workbench anzeigen?
Oliver J. schrieb: > Das ist ja das schöne für deinen Beigabe-Debugger verschenkt ihn Segger > [1]. ;) Und nein ich mache keine Werbung für Segger - Bin einfach nur > rundum zufieden mit deren Debuggern. Indirekt schon. Aber ich kann bestätigen, wir bezahlen dich nicht dafür ;-). Das schöne ist doch heutzutage, dass man aus vielen verschieden JTAG Debug Probes wählen und jeder das für sich beste Werkzeug nutzen kann. Man muss aber schon sagen, dass viele Firmen (wie auch SEGGER) heutzutage seine professionellen Tools Hobbyisten sehr günstig oder kostenlos anbieten. Das schließt JTAG Debug Probes, IDE, RTOS und Middleware mit ein. Oft macht es aus meiner persönlichen Sicht keinen Sinn nicht solche Lösungen zu nutzen.
Stefan U. schrieb: > Das Einzige, was ich vermisse, ist die Möglichkeit, beim Debugging ITM > (SWO) Meldungen anzuzeigen. Keil kann das angeblich, die System > Workbench leider nicht. Das ST-Link Utility zeigt sie an, aber das kann > ich schlecht während des Debuggens mit laufen lassen. Wenn der SWO-Pin mit dem Debugger, also in deinem Fall ST-Link verbunden ist, dann kann man sich ein ITM-printf in der GDB-Konsole anzeigen lassen, also demnach auch in SW4STM32. Die genaue Beschreibung von der TPIU-Config mit OpenOCD findest du hier: http://openocd.org/doc/html/Architecture-and-Core-Commands.html#ARMv7_002dM-specific-commands Ein paar Beispiele hatte ich hier schon mal geschrieben: Beitrag "Re: ARM ETM mit openocd auslesen?" Du musst halt, wie im OpenOCD Manual beschrieben, den Dateinamen weglassen, damit der Output in der OpenOCD-Konsole landet. Meine primäre Quelle dafür war http://blog.japaric.io/itm/ . Da geht es zwar um Rust und nicht um C aber die Debug- und Traceeinstellungen, sowie der GDB sind ja gleich.
Stefan U. schrieb: > Ich weiss nicht was du mit "im Flash" meinst. Jedenfalls > kann ich programme, die aus dem Flash heraus ausgeführt werden > debuggen indem ich Haltepunkte setze. > > Meinst du das, oder was anderes? Ich meine etwas anderes. Wenn man die Hardware-Breakpoints (Anzahl ist vom jeweiligen Core limitiert) aufgebraucht hat, dann kann der J-link live den Flash Patchen und "Software-Breakpoints" einfügen. Ist ein echt tolles Feature. >Quelle: Segger-Homepage: >The J-Link software comes with an additional feature, called Unlimited Flash >Breakpoints. Unlimited Flash Breakpoints allow the user to set an unlimited >number of breakpoints when debugging in flash memory. >Without this feature, the number of breakpoints which can be set in flash is >limited to the number of hardware breakpoints supported by the debug unit of >the CPU (2 on ARM 7/9, 4-6 on Cortex-M). Grüße Oliver
Til S. schrieb: > Indirekt schon. Aber ich kann bestätigen, wir bezahlen dich nicht dafür > ;-). Vielleicht kann ich ja bei euch noch was aushandeln :D
Das geht neuerdings bei SW4STM32 in Verbindung mit Oliver J. schrieb: > Ich meine etwas anderes. Wenn man die Hardware-Breakpoints (Anzahl ist > vom jeweiligen Core limitiert) aufgebraucht hat, dann kann der J-link > live den Flash Patchen und "Software-Breakpoints" einfügen. Ist ein echt > tolles Feature. Das geht, neuerdings, mit SW4STM32 und ST-Link ebenso. Bin ich letztens durch Zufall drüber gestolpert.
Als ich das Anzeigen von ITM einigen Monaten versuchte (auch mit diversen Varianten von Config Files) klappte es noch nicht. Kannst du mir kurz einen Tip geben, wie man diese Meldungen in der aktuellen Version der System Workbench anzeigt? Wenn ich in der Debugger Konfiguration ganz am Ende "monitor itm port 0 on" einfüge, erhalte ich diese fehlermeldung:
1 | itm_test Debug.cfg:30: Error: invalid command name "monitor" |
2 | in procedure 'script' |
3 | at file "embedded:startup.tcl", line 60 |
4 | at file "itm_test Debug.cfg", line 30 |
Den Ansatz, die Ausgabe in eine Datei umzuleiten finde ich ziemlich unkomfortabel. Das kann ich dann doch besser ein herkömmliche USB-UART Verbindung benutzen, anstatt SWO.
Stefan U. schrieb: > Wenn ich in der Debugger Konfiguration ganz am Ende "monitor itm port 0 > on" einfüge, erhalte ich diese fehlermeldung: > itm_test Debug.cfg:30: Error: invalid command name "monitor" > in procedure 'script' > at file "embedded:startup.tcl", line 60 > at file "itm_test Debug.cfg", line 30 "monitor" ist für den GDB die Anweisung, alles was in dieser Zeile steht an den GDB-Server weiterzuleiten. Wenn du die Config direkt in OpenOCD vornimmst, dann musst du das "monitor" weglassen. D.h. .gdbinit: "monitor itm port 0" openocd.cfg: "itm port 0"
:
Bearbeitet durch User
Angehängte Dateien:
-
Unbenannt.png
15 KB
Mit "itm port 0 on" komme ich weiter (keine Fehlermeldung mehr) aber die Meldungen sehe ich trotzdem nicht. Mit dem ST-Link Utility kann ich sie aber sehen. Mein aktueller Versuch hat diese Einträge im Debugger Config File:
1 | tpiu config internal - uart off 8000000 |
2 | itm port 0 on |
Mit "manchester" anstelle von "uart" sehe ich auch nichts. Wenn ich den Dateinamen weglasse, bekomme ich eine Fehlermeldung:
1 | tpiu config internal uart off 8000000 |
2 | itm port 0 on |
1 | STM32F103RBTx.cpu tpiu config (disable | ((external | internal <filename>) (sync <port width> | |
2 | ((manchester | uart) <formatter enable>)) <TRACECLKIN freq> |
3 | [<trace freq>])) |
4 | tpiu config (disable | ((external | internal <filename>) (sync <port width> | |
5 | ((manchester | uart) <formatter enable>)) <TRACECLKIN freq> |
6 | [<trace freq>])) |
Mit einem Dateinamen klappt es. Die Anzeige sieht in Eclipse scheußlich aus, aber ein tail -f in der CygWin Shell klappt prima.
Sorry Stefan, vergiss das was ich oben geschrieben habe. Das war falsche Information meinerseits. Ich war mir eigentlich relativ sicher das mal so am laufen gehabt zu haben, also innerhalb von OpenOCD im Terminal aber wahrscheinlich hab ich das gedanklich entweder mit dem UART-Output oder mit Semihosting verwechselt. Man kann anstelle einer Datei auch eine named pipe angeben und dann aus dieser lesen oder was auch immer aber direkt in SW4STM32 scheint es mit OpenOCD jedenfalls nicht zu gehen.
Auch mit dem BMP geht SWO/ITM. Beim Original BMP nur mit relativ niedriger Rate, bei umgeflaschten STLinks oder Bluepills deutlich schneller. Fuer Stlink/Bluepill muss man noch Patchen: https://github.com/blacksphere/blackmagic/pull/305 Zum Auslesen gibt es eine Kristallkugel: https://github.com/mubes/orbuculum
mit dem BMP habe ich mich noch nicht beschäftigt, aber da mein umprogrammierter China-STLink nicht mit OpenOCD laufen wollte (mit dem STLink Utility funktioniert er) ist das vielleicht eine Alternative. Ich habe noch nicht ganz verstanden was beim BMP so anders sein soll bzw. wie der integrierte GDB Server zu verstehen ist. OpenOCD braucht man trotzdem noch oder wie wird der eingebunden? Ich benutze den mit Eclipse und dem gnuarmeclipse plugin.
Ist die BMP denn mittlerweile einigermaßen benutzerfreundlich oder muss man Fehlermeldungen immer noch per Morse Code von einer LED ablesen?
Nein, beim BMP braucht man kein OpenOCD. Man startet den GDB "arme-none-eabi-gdb", im GDB verbindet sich mit der ersten ACM Schnittstelle des BMP "tar extended /dev/ttyACM0", dann schaut man ob die angeschlossene CPU erkannt wird: "mon swd" fuer SWD bzw "mon jtag" ggf fuer Jtag und verbindet sich mit der CPU "att 1" oder bei JTAG ggf eine hoehere Nummmer. Der BMP kennt bei weiten nicht so viele CPUs wie OpenOCD, dafuer braucht man aber auch bei weiten nicht so viele Optionen wie bei OpenOCD. M.e.a. kommt BMP auch besser mit schlafenden CPUs zurecht.
ok, danke. D.h. in der Eclipse Debug Config kann das Häkchen bei 'Start OpenOCD locally' weg. Braucht der gdb noch Kommanozeilenoptionen um sich mit dem USB ACM device zu verbinden oder probiert der die möglichen Schnittstellen selber durch? Ich kann das erst heute abend probieren, darum frage ich mal.
Die zu verwendende Schnittstelle musst Du im Gdb angeben, z.B. "target extended /dev/ttyACM0"
:
Bearbeitet durch User
ok. Habe gerade noch das hier gefunden: https://github.com/gnu-mcu-eclipse/eclipse-plugins/issues/241 das sollte also mit wenig Aufwand gehen.
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.