Eine sehr interessante Alternative zu den bekannten kommerziellen (z.B. von Segger) und offenen (OpenOCD) JTAG Adaptern ist die Black Magic Probe.
Eine der Besonderheiten ist, dass der GDB Server direkt auf dem eingebauten STM32 Mikrocontroller läuft und man sich daher die nicht immer ganz unproblematische Einrichtung eines lokalen GDB Servers auf dem PC sparen kann. Es ergeben sich zudem Vorteile bei der Geschwindigkeit und Stabilität der Verbindung zum zu debuggenden Mikrocontroller.
Aktuell werden diverse Cortex-M0, M3 und M4 von Atmel, Nordic, NXP / Freescale, Silicon Labs, Texas Instruments und ST unterstützt, die Entwickler versprechen jedoch die Unterstützung weiterer Typen und auch von "größeren" Controllerserien wie z.B. den Broadcom-Chip auf den Raspberrys.
Hardwareseitig verfügt der Adapter über Levelshifter (1,71 bis 5V Zielspannung), kann dem Ziel aber leider nur fixe 3,3V zur Verfügung stellen.
Hardwarefiles und die Firmware sind Open Source.
Nähere Informationen und Bezugsquellen gibt es auf der Projektseite.
Man kann den BMP auch auf verschiedene Hardware aufspielen:
https://embdev.net/articles/STM_Discovery_as_Black_Magic_Probe
Bei den STLinks geht es allerdings nur mit V2.1 problemlos.
Bei STlink v1 und v2 ist nur ein STM32F1038B verwendet. Da die Firmware
+ Bootloader inzwischen grosser 64 kiB ist, muss man sich auf
ungetestetes Flash oberhalb von 64 kiB verlassen und zum Aufspielen der
Firmware mittels DFU Werkzeug verwenden, was oberhalb des annonzierten
Flash schreiben kann (dfu-util sourcefore head).
Baldrian schrieb:> Eine einfacher und preiswerter Weg, um..
Der Beitrag in deinem Link ist ein ziemlicher Bockmist. Da referiert der
Autor in der Art "drücken Sie den linken Knopf und schreiben Sie die
folgende Kommandozeile hin.."
Ich hatte mal versucht, die Quellen zu diesem Projekt mit dem Keil zu
übersetzen und bin von selbigem geradezu erschlagen worden mit
Fehlermeldungen.
Soweit ich mich erinnere, war in diesen Quellen sogar ne void Funktion,
die ein Ergebnis liefern wollte (return xyz;) - kurzum, dieses Projekt
ist ein Pfusch, daß es einen graust. Die lapidare Bemerkung in dem Link
"Ignore any errors that might occur." spricht Bände.
Wenn diese Eierköpfe es fertiggebracht hätten, ihr Zeug ordentlich zu
schreiben und vielleicht sogar eine lesbare Dokumentation zu verfassen,
dann könnte daraus was werden, so aber nicht.
W.S.
Das ist ganz nett für "ältere" Chips. Ansonsten hat man ständig das
Problem, den Firmware-Updates hinterher zu laufen. Mal schnell die
Unterstützung der neuesten Varianten (z. B. 32h7) einzubauen, geht auf
dem Host doch etwas bequemer.
Und grundsätzlich hat mehr "Intelligenz" im Adapter natürlich das
Problem, dass jede Chip-Variante die Firmware aufbläht und aufbläht und
... bis ... na ja, halt kein Platz mehr da ist. Siehe J-Link V8 -> V9.
Das gleiche Spielchen gabs auch schon bei EPROM-, GAL- ... Programmern.
Wenn sich viele Bausteine durch mehr oder minder generische Algorithmen
erledigen lassen, geht's lange gut. Aber wenn jeder Chip seine
Extrawürste haben will, wird's schnell ärgerlich.
Oder man verzichtet zunächst mal auf die ganz "exotischen" Sachen wie
sector protection, pcrop, secure mode, otp und wie sie alle heißen.
Solange man die nicht braucht, ist das Entwickeln mit dem BMP sicher
ganz ok.
Sehe ich auch so, vor allem die Hardware kostet mehr als ein J-Link EDU:
https://1bitsquared.de/products/black-magic-probe
J-Link EDU:
https://www.segger.com/purchase/pricing/jlink-related/
Fairerweise muss man natürlich sagen das der Black Magic Probe
wahrscheinlich auch kommerziell eingesetzt werden darf...aber das
wiederum macht wahrscheinlich auch keiner weil dann lieber
professionelle Tools wie der normale J-Link benutzt werden.
Chris F. schrieb:> Der echte Preis von dem Teil ist dann auch genau 60€:
Das ist dann aber der alte normale, nicht der neue (vermutlich noch
nicht verfügbare) MINI.
Der Steckverbinder am Segger Mini ist aber im 0.05 inch Raster. Adapter
auf "normales" 0.1 mm Raster kosten deutlich.
Wie bringt man den den Segger auf der Kommandozeile unter Linux zum
Laufen, um dann mit dem gdb zu arbeiten? Die Anzahl an noetigen Optionen
erscheint mir fast unendlich.
Beim BMP, z.B. auf einem Nucleo ist das nur
- anstecken am USB
- arm-non-eabi-gdb xxx.elf
und im gdb
-- tar ext /dev/ttyACM0
-- mon s
-- att 1
Und bei den aelteren STM Disco Boards hatte man durch das Umflashen auf
BMP auch einen seriellen Kanal, den die aelteren STLinks nicht hatten
Guest schrieb:> https://www.segger.com/news/segger-introduces-j-link-edu-mini-a-low-cost-j-link-for-education/>> 18$ (~16 Euro) für einen originalen J-Link von SEGGER.
Hey, bis jetzt kannte ich nur den normalen EDU (~50€), der Mini muss
ziemlich neu sein. Danke für den Hinweis! Damit stößt der J-Link ja nun
endgültig auch in die Preisregionen selbst des geizigsten denkbaren
Bastlers (GDB) vor.
Auch wenn alles closed ist kann ich einen J-Link aufgrund überragender
Nützlichkeit und Qualität nur wärmstens empfehlen. Und alles läuft
übrigens auch problemlos unter Linux.
Gehen die billigen STLink clones aus China wirklich dafür?
Wenn Ja dann kaufe ich mir mal davon 2 Stück.
Denn Billiger geht es dann nicht mehr.
Grüsse, Peter
Uwe B. schrieb:> Wie bringt man den den Segger auf der Kommandozeile unter Linux zum> Laufen, um dann mit dem gdb zu arbeiten?
Du musst erst den gdb server starten (anders als bei der BMP ist das bei
Segger ein Stück Software auf dem PC). Es laufen also 2 Prozesse auf dem
PC: Der J-Link gdb-Server und der eigentliche gdb.
Also nochmals genauer gefragt:
Wie startet man dem J-Link gdb-Server? Mit derHilfestellung, die der gdb
server gegeben hat, habe ich nach einigen Versuchen aufgegeben...
Peter schrieb:> Gehen die billigen STLink clones aus China wirklich dafür?>> Wenn Ja dann kaufe ich mir mal davon 2 Stück.> Denn Billiger geht es dann nicht mehr.>
Die billigen Clone haben einen STM32F103C8. Aktueller BMP Bootloader +
Firmware ist > 64 kB. Zwar habe ich noch von keinem STM32F103C8 gesehen,
der nicht Flash bis 128 k hat, aber das macht zwei Probleme:
- Geht der Flash ueber 64 k wirklich?
- Wie laedt man den Flash ueber 64 k?
Sowohl fuer dfu-utils als auch fuer bmp/src/tools/stm32_mem.py haben da
Probleme. Allerdings haengen in den Projekten Patches von mir, die das
Problem bei mir behoben haben. Ruecklesen des Flashes um Fehler zu
finden waere zwar schoen, gibt es aber noch nicht.
Man kann aber auch die Liste der unterstuetzten Devices in makefile und
Quellen kuerzen, und so unter der 64 k Grenze bleiben oder aeltere
Versionen verwenden...
Uwe B. schrieb:> Also nochmals genauer gefragt:> Wie startet man dem J-Link gdb-Server?
So wie es im Manual steht?
UM08001_JLink.pdf, Kapitel 3.3 "J-Link GDB Server"
Gut, also bestelle ich mir diese Clones.
In der Liste der unterstützten devices ist für mich sowieso vieles drin
was ich nicht brauche. Wird somit gekürzt.
Speicher zu nutzen den es ofiziell nicht gibt, halte ich für gewargt.
Auch wenn es nur ein weiterer Debugger wird halte ich nichts davon.
Grüsse, Peter
So eine Adapterplatine für den Atmel-Ice von 0,05 auf diverse andere
Größen hatte ich mal gebaut. ( http://aug3.de/swd/ )Ist der kleine
Stecker vom Ice kompatibel zum "mini"?
Gestern habe ich versucht aus einem low cost STLink Clone (Weltmarke
'Baite') eine Black Magic Probe zu machen. Bisher erfolglos wollte ich
schreiben und habe die Prozedur nochmal protokolliert. Ich hatte ein BMP
USB device, aber beim Schreiben auf den COM-port für den GDB hat sich
das Br@y Terminal aufgehängt. Bis ich jetzt auf die Idee kam das DTR zu
setzen, und schon meldete sich BMP im Terminal. Nur in Eclipse klappt es
noch nicht, die Verbindung mit gdb wird kurz gemacht aber kein Program
geladen und gdb wird wieder beendet.
Aber da ich die Prozedur jetzt schon aufgeschrieben hatte:
Dazu gibt es verschiedene Anleitungen, ich habe letzendlich das Tool
stm32flash und die binaries von Uwe aus dem hier verlinkten Artikel
benutzt. Das stm32flash war nötig weil der Baite die SWD Pins nicht
beschaltet hat, für den seriellen Bootloader sind Pads vorhanden und
über einen seriellen USB Adapter lässt sich der STM32F103C8 auf der
probe flashen.
Das 64 k Problem ist mir bekannt, stm32flash meldet aber auch das ich
ein device mit 128 kB habe und kann >64 kB brennen. Die übersetzten
Binärfiles in dem Artikel sind allerdings noch releases von 2016 und mit
Bootloader knapp unter 64k.
Mit dem stm32flash putze ich also zunächst den Speicher und brenne dann
die beiden Binärdateien.
Hallo
Ich habe mich vor Jahren(so um 2010 herum) mit OpenOCD und GDB
beschäftigt und bin damals zum Schluss gekommen, dass GDB einfach
furchtbar und unstabil ist. Liegt evtl auch an Eclipse das man damals
noch selbst für die ARM Cortex mit CDT-Plugin usw. fit machen musste.
Seit jener Zeit setzte ich Keil und ST-Link ein und hatte nie
irgendwelche Probleme mit Verbindungen oder Instabilitäten.
Wie schaut das Heute aus? Kann mir jemand GDB schmackhaft machen? Oder
soll ich einfach weiter bei Keil bleiben. Die Litzenzkosten sind halt
schon ein Argument dagegen ...
hier in diesem Thread geht es ja um die BMP, also auch eine Alternative
zu OpenOCD, mit einer schlauen Debug Probe + gdb anstelle von OOCD+dumme
debug probe+gdb. Ich habe es gerade zum Laufen bekommen und es tut was
es soll, download ist schnell und stepping reagiert auch sehr zügig.
Die Launch Configuration hat mich einiges an rumprobieren gekostet, aber
da BMP ja weniger Konfiguration braucht ist es letzendlich einfacher.
Bis jetzt gefällt es mir, der 3$ ST-Link ist jetzt ein universeller
Debugger.
hier ist noch eine Anleitung für den Baite:
https://wiki.cuvoodoo.info/doku.php?id=jtag
Da gibt es einen PR für eine angepasste Belegung der UART Signale. Den
Fork von 'tsaitgaist' bekomme ich kompiliert und geladen, aber damit
bekomme ich keine Verbindung mehr zum Target ('monitor target' listet
keine Verfügbaren auf) und der UART als Nullmodem tut auch nix.
Hat hier jemand zufällig diese Version laufen?
Uwe B. schrieb:> https://github.com/blacksphere/blackmagic/pull/318 macht SWD mit der BMP> schneller.
das habe ich jetzt mal in meine Kopie reinkompiliert und wollte es per
DFU Update laden. Das stm32_mem.py hatte zunächst gemeckert weil ich
kein 'usb' Modul hatte, mit 'pip install pyusb' habe ich hoffentlich das
richtige installiert.
Das Update bricht aber mit einem nicht abgefangenen Fehler ab, die
Meldung sagt mir erstmal nix, was läuft da schief?
USB Device Firmware Upgrade - Host Utility -- version 1.2
4
Copyright (C) 2011 Black Sphere Technologies
5
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
6
7
Device ID: 1d50:6018
8
Manufacturer: Black Sphere Technologies
9
Product: Black Magic Firmware Upgrade (Baite)
10
Serial: E1E7D0DA
11
Failed to read device state! Assuming APP_IDLE
12
Traceback (most recent call last):
13
File "..\scripts\stm32_mem.py", line 155, in <module>
14
dfudev.detach()
15
File "D:\Projects\Sn\ARM\STM32\BlackMagicProbe\blackmagic\scripts\dfu.py", line 92, in detach
16
None, value=wTimeout, index=self.index)
17
File "c:\Python27\lib\site-packages\usb\legacy.py", line 211, in controlMsg
18
timeout = timeout)
19
File "c:\Python27\lib\site-packages\usb\core.py", line 1043, in ctrl_transfer
20
self.__get_timeout(timeout))
21
File "c:\Python27\lib\site-packages\usb\backend\libusb0.py", line 593, in ctrl_transfer
22
timeout
23
File "c:\Python27\lib\site-packages\usb\backend\libusb0.py", line 431, in _check
24
raise USBError(errmsg, ret)
25
usb.core.USBError: [Errno None] libusb0-dll:err [control_msg] sending control message failed, win error: Ein an das System angeschlossenes Gerõt funktioniert nicht.
Johannes,
mehr Kontext!
Ging es vorher?
Ist das normales Windows oder Windows in einer VM? BMP/ STlink als BMP/
Bluepill/Baite?
Nach dem Crash sollte der BMP im Bootlaoder sein. Geht der naechste
Versuch?
Kannst Du das mal unter Linux probieren?
Danke,
das war der erste Versuch mit dem DFU Bootloader. HW ist wie in Posts
zuvor ein Baite ST-Link Clone, platform SW ist dieser PR:
https://github.com/blacksphere/blackmagic/pull/274/files
Das Protokoll war schon vom zweiten Versuch, der erste sah ähnlich aus:
1
USB Device Firmware Upgrade - Host Utility -- version 1.2
2
Copyright (C) 2011 Black Sphere Technologies
3
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
4
5
Device ID: 1d50:6018
6
Manufacturer: Black Sphere Technologies
7
Product: Black Magic Firmware Upgrade (Baite)
8
Serial: E1E7D0DA
9
Failed to read device state! Assuming APP_IDLE
10
Invoking DFU Device
11
Device ID: 1d50:6018
12
Manufacturer: Black Sphere Technologies
13
Product: Black Magic Firmware Upgrade (Baite)
14
Serial: E1E7D0DA
15
Traceback (most recent call last):
16
File "..\scripts\stm32_mem.py", line 171, in <module>
17
dfudev.make_idle()
Getestet im native Win7, ich habe eine Ubuntu VM, da ist aber nicht
alles installiert. Kompiliert hatte ich das in einer MinGW Umgebung
unter Windows.
Initial habe ich BMP per stm32flash übertragen, aber dazu müssen Kabel
an den Adapter gelötet werden, DFU Update ist natürlich bequemer.
Nach installationsorgie unter Virtualbox Win10 (python3, pyusb, zadig)
und Anpassungen von dfu.py/stm32_mem an python 3
(https://github.com/UweBonnes/blackmagic/tree/python3) konnte ich einen
BMP/STLINK unter win10 flashen.
Vermutlich hat der "baite branch" (Url?) die Aenderungen am Bootloader
nicht nachgezogen. Da ich keinen " Baite" habe, kann ich hier nicht
testen.
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten