Hallo, ich entwickle auf einem SAMD21 mit Visual Studio Code und würde gerne Debuggen... durchsteppen, Breakpoints etc. Habe über die Black Magic Probe gelesen und finde sie sehr interesant, v.a. weil damit mehr geht als nur Atmel (gegenüber dem ATMEL ICE). Also, leider gibts die orig. BMP hierzulande nicht zu kaufen. Außerdem soll die Software-Variante mit GDB auf dem Host auch seine Vorteile haben. Ich hab aber einen ST Link V2 Clone aka "baite" hier. Der soll ja auch gehen. So, Binaries gibts hier: http://builds.blacksphere.co.nz/blackmagic/ Nur welche und wie drauf? wenn der orig. Bootloader drauf bleibt, dann muss man immer manuell starten? Weiterhin - angeblich ist der ST Link v2 (F103) Flash zu klein daher gehts nur mit DFU? Ich hab nun probiert erstmal mit Zadig erfolgreich WinUSB Treiber mit der baite registriert. Aber dfu-util v0.9 listet mir kein Gerät. Tipps?
Warum nicht das Original? https://github.com/blacksphere/blackmagic https://embdev.net/articles/STM_Discovery_and_Nucleo_as_Black_Magic_Probe#Using_cheap_STLink-clones Zur Installation unter Windows kann ich nichts dazu sagen. Unter Linux wie beschrieben kein Problem.
:
Bearbeitet durch User
Angehängte Dateien:
-
Baite-pins.jpg
88 KB
Der DFU Loader ist nicht im F103, den muss man einmalig über den seriellen Bootloader programmieren. Gelb - TxD FTDI Grün - RxD FTDI Orange - DTR FTDI Rot - +5V Grau - GND Für die serielle Schnittstelle auf SWIM stört noch ein 620R Pullup den man entfernen sollte. Ich bin mir auch nicht sicher ob die aktuelle BMP den Baite mit der seriellen konfiguriert, müsste da eventuell noch mal meine Konfig rauskramen.
Angehängte Dateien:
-
IMG_20201111_163800685.jpg
240 KB -
IMG_20201111_163806651.jpg
230 KB
meine baite schaut ganz anders aus. Ganze Rückseite ist bestückt... und Programmierheader nur zu erahnen? kann ich die mit einem CH340 / CP2102 programmieren? Welche Software (WIN) gibts dafür?
Sir S. schrieb: > Also, leider gibts die orig. BMP hierzulande nicht zu kaufen. ist das nicht das Original? https://1bitsquared.de/
Von dem Baite gibt es eine neuere Version, die habe ich nicht. Da ist ein SWD auf den Pads und man braucht einen anderen Adapter zum programmieren. Oder gucken ob man da auch an Boot0 und die seriellen Pins drankommt. https://wiki.cuvoodoo.info/doku.php?id=jtag Da sind einige Varianten gelistet.
Bauform B. schrieb: > Sir S. schrieb: >> Also, leider gibts die orig. BMP hierzulande nicht zu kaufen. > > ist das nicht das Original? > https://1bitsquared.de/ ahja, noch noch verfügbar. Danke für den Link. Aber ehrlich? Wenn es eine Möglichkeit gibt das hinzubekommen für 10€ statt 75€, dann will ich das so machen. Ich weiß ja noch nicht mal sicher ob das alles in meiner Toolchain dann auch läuft.
Johannes S. schrieb: > Von dem Baite gibt es eine neuere Version, die habe ich nicht. Da ist > ein SWD auf den Pads und man braucht einen anderen Adapter zum > programmieren. Oder gucken ob man da auch an Boot0 und die seriellen > Pins drankommt. > > https://wiki.cuvoodoo.info/doku.php?id=jtag > Da sind einige Varianten gelistet. ja das check ich gerade, ich brauch 2 Stück... wo ich nun die Auswahl habe, was wäre den zu bevorzugen bzgl. einer möglichst problemlosen Umwandlung zur BMP ?
Das Umprogrammieren geht sicher mit beiden, bei dem alten kann man auf jeden Fall die SWIM Pins für einen COM Port nutzen, ist praktisch und nutze ich häufig. Ob der Stecker das am neuen hergibt müsste man checken. Nur die F103 bekommt ja fast nur noch als Clones, ich weiß nicht wie die sich als BMP machen. Man kann auch ein Bluepill Board nehmen. Nachtrag: Auf deinen Bildern sieht man 6 Pins für Power, das ist zu wenig. Besser die alte Version wenn man die noch bekommt.
Angehängte Dateien:
-
IMG_20201111_204624967.jpg
240 KB
Johannes S. schrieb: > Nur die F103 bekommt ja fast nur noch als Clones, ich weiß nicht wie die > sich als BMP machen. Man kann auch ein Bluepill Board nehmen. Du meinst den F103 chip als clone? den CH32F103 ? Ich hab jetzt so oft BLuepill gelesen, und bin die ganze Zeit davon ausgegangen das wäre irgendein blauer Programmieradapter. Aber das man das "berühmte" F103 Board Bluepill nennt, war an mir vorbeigegangen. Vorteil wäre hier, dass alle Pins problemlos zugänglich sind, oder?? Dann nehme ich doch so eins. Oder... wühl Sowas hab ich noch hier. STM32L-Discovery...
Mit dem Discovery kannst du deinen Adapter programmieren. Die zwei Jumper in STLink Position und den SWD Port mit den Pads auf deinem Adapter verbinden. Belegung vom SWD ist in der Doku vom Disco. SW ist STM32CubeProgrammer, das kann mit allen Schnittstellen umgehen.
Angehängte Dateien:
-
STM32-disco_SWD.png
16 KB -
IMG_20201111_163800685.jpg
240 KB
Das Pinout, der Vollständigkeit halber. Welche Vorteile hat der Cube gegenüber dem STM 32 ST-Link Utility ? Die 4 Pins auf dem "Baite" hab ich durchgepiepst, siehe Anhang. Ich kenne mich mit dem STM32 0,0 aus - die PINS zum programmieren sind die selben wie die zum programmiert werden? Also 1:1 verbinden? und es geht ohne RST?
Ja,1:1 verbinden, SWDIO/SWCLK und natürlich GND braucht man minimal zum Programmieren. Der Cube Programmer ist neuer und kann alle möglichen Schnittstellen nutzen. Es geht idR ohne Reset. Nur wenn der Programmer keine Verbindung bekommt, dann beim Verbinden den Reset aktivieren. STLink/BMP können in dem Fall den Reset bedienen wenn verbunden, es geht aber auch manuell. Der STLink auf dem Disco braucht vielleicht ein Update, das ist häufig nötig. Geht auch einfach über den CubeProgrammer.
Johannes S. schrieb: > Nur die F103 bekommt ja fast nur noch als Clones, ich weiß nicht wie die > sich als BMP machen. Kein Problem, wenn man erst mal geflasht bekommen hat. So z.B. Johannes S. schrieb: > Mit dem Discovery kannst du deinen Adapter programmieren. Mit einem Clone einen anderen Klone programmieren hat es bei mir mit st-flash nicht funktioniert. Für openOCD habe ich ein anderes Target mit stm32f1x.cfg als Basis erstellt, indem ich einfach eine Kopie (cs32f103c8t6.cfg) erstellt und dort weiter oben (vor der Abfrage): set CPUTAPID 0x2ba01477 eingefügt hatte. Sir S. schrieb: > Also 1:1 verbinden? und es geht ohne RST? Ja Schau auch mal hier ein, da habe ich mich schon darüber ausgelassen: Beitrag "LPC debuggen mit Black magic probe auf STlinkV2 clone" Da findest Du evt. noch Tips von Mitforisten. (incl. Umbau für eine zusätzliche serielle Schnittstelle)
Danke für den Link, die Info warum hosted besser sein kann als firmware verstehe ich nun. So, ich hab es mittlerweile auch geschafft den clone über den orig. st link anzusprechen, über SWD. Nur - was flash ich da jetzt drauf? Da finde ich mich noch nicht so zurecht. Kann ich eines der fertigen bins von http://builds.blacksphere.co.nz/blackmagic benutzen? Zumindest das blackmagic-stlink.bin von da brachte erstmal keinen Erfolg. Schreiben ging schon, aber danach meldet sich das Teil nicht mehr am Rechner...
du kanst beide flashen, stlink und stlink-dfu. Da das binary files sind muss die Startadresse angegeben werden, 0x08000000 für stlink-dfu 0x8002000 für stlink ohne Gewähr, habe ich aber gerade im linker und makefile nachgesehen. Bzw. da stehts auch: https://github.com/blacksphere/blackmagic/wiki/Hacking Und nur die Anwendung reicht nicht, dann fehlt ja der Code der nach dem Reset gestartet wird. Also erstmal beide flashen, danach kann man über den DFU die Updates rüberschieben.
genau so hat es funktioniert. Die Probe wird nun von Windows als BMP erkannt, und bietet 2 COM Ports. Schaut ganz gut aus! Aber wie, da muss noch mehr drauf geladen werden? Welche Updates? Ich muss noch ne Menge lesen um das mit VSCode zum Laufen zu bringen, das wird noch ein steiniger Weg...
:
Bearbeitet durch User
Du hast doch aus Git Head kompiliert. Was willst Du da im Moment updaten?
Uwe B. schrieb: > Du hast doch aus Git Head kompiliert. Was willst Du da im Moment > updaten? ich sehe da auch keinen Bedarf aber ich weiß dass ich nichts weiß ;)
Mal ehrlich, warum tut man sich diesen Scheiß an? Es gibt doch die Segger-Entwicklungstools, da geht nichts drüber. Diese Tools werden von jeder Software aus dem Stand unterstützt. Für privat gibt's den J-Link-EDU-Mini* für 17,40€, der kann alle Cortexe. Der große Bruder J-Link-EDU** für 56,84€ kann noch mehr. *) https://www.antratek.de/j-link-edu-mini **) https://www.antratek.de/j-link-edu
Sir S. schrieb: > Aber wie, da muss noch mehr drauf geladen werden? Welche Updates? So ist das komplett, Updates natürlich nur wenn nötig. Dann ist es aber über den USB Anschluss möglich ohne den Aufwand mit einem zweitem Programmer. Der nächste Schritt ist das manuelle Testen wie hier beschrieben: https://github.com/blacksphere/blackmagic/wiki/Getting-Started Also gucken welche serielle Ports der bekommen hat, den gdb starten und testen ob ein angeschlossenes Target gefunden wird. Der zweite serielle Port ist nur nutzbar wenn die Pins rausgeführt sind, das ist eben bei der alten Baite Variante so. Die Nutztung in VSCode mit Cortex-Debug Plugin ist nicht so schwierig weil nur wenige Einstallungen nötig sind: - COM Port - Pfad zum .elf file du kannst dieses Muster in deine launch.json kopieren und anpassen:
1 | {
|
2 | "cwd": "${workspaceRoot}",
|
3 | "name": "debug COM8", |
4 | "BMPGDBSerialPort": "//./COM8", |
5 | "interface": "swd", |
6 | "type": "cortex-debug", |
7 | "request": "launch", |
8 | "servertype": "bmp", |
9 | "executable": "./BUILD/{workspaceFolderBasename}.elf"
|
10 | } |
Und was an diesem OSS Projekt 'Scheiß' sein soll erschließt sich mir nicht. Es funktioniert wunderbar, braucht wenig Konfiguration und auch SWO kann genutzt werden. Es gibt Portierungen auf ESP32 für einen Debugger der Wireless Remote arbeitet, Portierung auf Raspberries und ich habe auch eine Remote Version mit Ethernet daraus gebaut. Man kann ein ungenutztes Bluepill verwerten und die zusätzlichen Kosten sind 0,00 €. https://paramaggarwal.medium.com/converting-an-stm32f103-board-to-a-black-magic-probe-c013cf2cc38c https://jeelabs.org/docs/software/bmp/
Danke Johannes für die ausführliche Beschreibung! Das sieht ja so aus als könnte ich das heute noch zum Laufen bekommen... "Scheiß" finde ich jetzt auch etwas unfair gegenüber allen, die das BMP Projekt vorantreiben - Open Source ! Natürlich ist das rumgefrickel mit den China-Clones, SWD Interface finden und dranlöten, flashen etc... n Haufen Arbeit! (wenn man mit STM32 vertraut ist, sicher weniger). Ich kannte die "echte" BMP für 75€ und den Segger J-Link EDU für einen ähnlichen Kurs. Das wäre zwar OK, aber nicht günstig genug wenigstens etwas rumzuprobieren. Den Segger Mini für unter 20€ kannte ich nicht. Den hätte ich mir wohl geholt und mir das umflashen erspart. Andererseits - jetzt kann ich für unser OSS-Projekt allen Mitenwicklern eine Step-by-Step Anleitung geben wie sie für 3€ einen Debugger haben können. Das senkt nochmal die Eintrittshürde..
Sir S. schrieb: > Danke Johannes für die ausführliche Beschreibung! Gerne, you're welcome. Ich weiss ja das es um das BCU Projekt geht und das interessiert mich auch. Meine KNX Installation möchte ich auch noch erweitern und wollte mich um Weihnachten rum wieder mehr mit KNX beschäfftigen.
Mal eine Zwischenfrage: Werner schrieb: > Für privat gibt's den J-Link-EDU-Mini* für 17,40€, der kann alle > Cortexe. Aber doch nur die Typen, die schon eingebaut sind? Wenn nächstes Jahr ein neuer uC rauskommt, kann er den ja nicht kennen. Das betrifft die BMP ganz genauso, oder? Warum ist das so, warum reicht es nicht, das SWD-Protokoll zu sprechen? Das ist doch ARM und deshalb sollte man alle Cortex-M4 gleich ansprechen können. Klar, zum Flashen muss man den Chip ganz genau kennen, aber rein für den gdb sollte es doch reichen?
Sicher hat Segger da mehr (Wo)ManPower und schneller auf 'was Neues' reagieren und die Tools haben mehr Features, aber ich finde BMP kann da schon sehr viel. Für Hobbyanwendungen scheint es ja nur noch ST (neben ESP mit Tensilica) zu geben, und mit denen kann BMP gut umgehen. Für die komplexen H7 hat Uwe B. noch viel Arbeit reingesteckt und auch die kann man jetzt mit BMP verwenden. Kleinere LPC8xx hatte ich da auch schon mal dran. Und wenn mal etwas nicht geht: es ist eben ein OSS Projekt, da darf man gerne mithelfen. Bauform B. schrieb: > Klar, zum Flashen muss man den Chip ganz genau kennen, aber rein > für den gdb sollte es doch reichen? ja, so ist es z.B. auch bei pyOCD: wenn es den Chip nicht kennt ist debuggen möglich, flashen nicht. Wobei es da noch den ominösen ROM Table scan gibt, wenn der erfolgreich ist, dann kann BMP den flashen. So habe ich es jedenfalls verstanden. Das was ARM da mit dem Coresight eingebaut hat ist schon sehr umfangreich und hat auch mehrere hundert Seiten Doku.
Bauform B. schrieb: > Aber doch nur die Typen, die schon eingebaut sind? Wenn nächstes Jahr > ein neuer uC rauskommt, kann er den ja nicht kennen. Das betrifft die > BMP ganz genauso, oder? > > Warum ist das so, warum reicht es nicht, das SWD-Protokoll zu sprechen? > Das ist doch ARM und deshalb sollte man alle Cortex-M4 gleich ansprechen > können. Klar, zum Flashen muss man den Chip ganz genau kennen, aber rein > für den gdb sollte es doch reichen? Der kann durchaus alle (aktuellen) Cortex Kerne, für die bekannten Chips von ST (und anderen) gibt es dann nur vorkonfigurierte Zusatzinfos. Sofern du jetzt einen neuen Chip mit nem M4 findest, kannst du den problemlos als generischen M4 Kern ansprechen. Nur für einige Funktionen (z.B. zum Flashen) braucht es dann noch Zusatzinfos zur konkreten Implementierung (z.B. Speicherlayout). Das lässt sich aber problemlos von Segger nachliefern oder auch selber von Hand einstellen. Wenn ARM hingegen einen neuen Kern mit inkompatibler Debugschnittstelle veröffentlicht, braucht es dann natürlich mindestens ein Firmwareupdate, um die neue Schnittstelle anzusprechen. Wenn es ganz schlecht läuft sogar ein Hardwareupdate (z.B. wenn 12V Programmierspannung benötigt wird).
:
Bearbeitet durch User
Johannes S. schrieb: ... > Wobei es da noch den ominösen ROM Table scan gibt, wenn der erfolgreich > ist, dann kann BMP den flashen. Fuer alle Ein-Kern Cortex braeuchte man den Scan gar nicht (mehr). Der Scan ist aber z.B. noetig, um weitere Kerne zu finden und hilft das Device besser zu verstehen. Fuers Flashen hilft der Scan ersteinmal nichts. Wenn BMP einen CortexM von einem Hersteller nicht kennt, dann kann man ihn zumindestens schon mal mit GDB ansprechen. Zum Flashen muss jemand aber den Algorithmus schreiben. BMP versucht, im Gegensatz zu Segger und Openocd, soviel wie moeglich selbst herauszufinden ohne unzaehlige Konfig Files oder Argumente zu brauchen. Pyocd ist da aehnlich. M.e.a. schafft BMP das Hot-Plugging auch in mehr Situationen als Open-OCD. Mit BMP Hosted ist der Aufruf gleich, ob man mit BMP native, mit einen umgebauten STlink, einem Stlink mit Originalfirmware oder einem MPSSE, CMSIS-DAP oder Jlink Adapter arbeitet. Und die meisten Flash Algorithmen programmieren mittels direkter Registerzugriffe schneller und sind m.e.a.leichter zu warten als die sonst verwendeten Flash-Stubs. Etwa wie das differentielle (Re)Flashen wie bei Segger gibt es (noch) nicht. Beitrage sind willkommen.
yeah, es funktioniert! die launch.json etwas anpassen und es lief... Dank an Uwe, Johannes und alle die geholfen haben
Ich hab jetzt ein merkwürdiges Verhalten beim Step-Through Debugging in VSCode mit Cortex-debug festgestellt. Debugged wird ein Arduino Programm. Jetzt springt mit der Zeiger auf die aktuelle Anweisung aber auch immer mal wieder zurück, dann wieder 2 nach vorne.. total strange. Kennt das jemand?
Zum Hardware-Debugger gehört auch eine gute Software-Anbindung, für die Segger Debugger gibt es die. Nein, ich bekomme kein Geld von Segger und bin auch nicht anderweitig verbandelt. Meine Frage bleibt aber bestehen. Werner schrieb: > Mal ehrlich, warum tut man sich diesen Scheiß an? Mit Scheiß ist auch ausdrücklich dieses Gefrickel und diese halbgaren Lösungen gemeint.
Sir S. schrieb: > Kennt das jemand? ja, das ist ein normales Verhalten wenn man optimierten Code debuggt. Da ist es besser die Optimierung auszuschalten, beim gcc kompilieren mit -O0. Da kann auch Segger nicht zaubern und das hat nichts mit Gefrickel zu tun.
Werner schrieb: > Zum Hardware-Debugger gehört auch eine gute Software-Anbindung, Die gibt es bereits: gdb Werner schrieb: > Mit Scheiß ist auch ausdrücklich dieses Gefrickel und diese halbgaren > Lösungen gemeint. Hmm, bei mir funktioniert das wunderbar. Wo da jetzt Gefrickel sein soll, kann ich nicht nachvollziehen.
:
Bearbeitet durch User
die ganze GCC, Eclipse, VSCode, OOCD, pyocd, alles natürlich Gefrickel. Da kauft man doch lieber gleich ein ARM MDK für 8k€. Und die Segger Tools obendrauf. Oder die IAR Workbench. Aber da kenne ich hier jemanden der gleich einen Lachkrampf kriegt. BMP ist übrigends schon rund 10 Jahre alt (oder älter?). Da haben die haben die meisten hier noch versucht mit einem AVR eine LED zum Blinken zu bringen.
Johannes S. schrieb: > Sir S. schrieb: >> Kennt das jemand? > > ja, das ist ein normales Verhalten wenn man optimierten Code debuggt. Da > ist es besser die Optimierung auszuschalten, beim gcc kompilieren mit > -O0. Danke, klar, macht absolut Sinn. Mal sehen wie ich dem Arduino zusätzliche Parameter mitgeben kann. Ich komme beruflich zwar aus der SW-Ecke, habe aber bisher professionell nur PC-Software entwickelt. Was da z.B. im VS mit .Net möglich ist... Embedded mache ich zwar seit Jahren als Hobby, aber noch nie so ernstaft, dass dafür mehr wie printf debugging nötig gewesen wäre. Soviel zur Rechtfertigung weil ich so viele dumme Fragen stelle.
Ntldr -. schrieb: > Wenn es ganz schlecht läuft sogar ein Hardwareupdate > (z.B. wenn 12V Programmierspannung benötigt wird). In ein paar Jahren wird 5V bereits als High-Voltage gelten.
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.