Ich habe zwei BMP probes, mit denen ich derzeit in STM32CubeIDE 13
GDB-Hardware Debugging eingestellt habe.
Die entsprechende Zeile in der Konfiguration des Debuglaunchers sieht so
aus:
1
set mem inaccessible-by-default off
2
target extended-remote /dev/cu.usbmodem86764DA91
3
shell sleep 5
4
monitor swdp_scan
Jetzt will ich zum blackmagic server (BMDA) verbinden. Der läuft auf
port 2000 (default).
Wie sehen da die Initialisierungskommados aus?
Ich habe angefangen mit
1
set mem inaccessible-by-default off
2
tar extended-remote :2000
3
4
Bekomme aber nach timeout:
5
6
Error in final launch sequence:
7
8
Failed to execute MI command:
9
-target-select remote localhost:1234
10
11
Error message from debugger back end:
12
localhost:1234: Operation timed out.
13
Failed to execute MI command:
14
-target-select remote localhost:1234
Das sieht so aus, als funkt eine andere Voreinstellung dazwischen.
(hab schon gesehen, da ist Remote Target konfiguriert und da steht die
1234). Aber ohne die Konfiguration von remote target klappt's auch
nicht.
Weiß jemand Rat?
Christoph K. schrieb:> Ich habe zwei BMP probes, mit denen ich derzeit in STM32CubeIDE 13> GDB-Hardware Debugging eingestellt habe.> [...]> Jetzt will ich zum blackmagic server (BMDA) verbinden. Der läuft auf> port 2000 (default).> [...]>
1
> Failed to execute MI command:
2
> -target-select remote localhost:1234
3
>
Leider habe ich nicht die geringste Ahnung, wovon Du sprichst, daher ist
meine Antwort das berühmte Stochern im Nebel. Aber wenn ich die Meldung
korrekt interpretiere, versucht Deine Software, etwas auf Port 1234 auf
Deinem Localhost zu erreichen. Da Du aber weiter oben schreibst, daß Du
Deinen Server auf Port 2000 laufen läßt...
Du hättest jetzt zwei Möglichkeiten: entweder sorgst Du dafür, daß Deine
Software auf Port 2000 zugreift, und wenn ich Deine Frage hier richtig
verstanden habe, zielst Du genau darauf ab. Leider kann ich Dir nicht
sagen, wie Du das mit Deiner Software umsetzen kannst, tut mir leid.
Zwei andere Lösungen für Dein Problem könnten aber sein, daß Du entweder
den Server umkonfigurierst, so daß er auf Port 1234 lauscht, oder -- das
ist eher unelegant, fürchte ich -- Du verwendest einen Reverse Proxy,
der auf Port 1234 lauscht und zwischen den Ports 1234 und 2000
vermittelt.
HTH, YMMV, viel Glück und Erfolg!
Danke. Dein Versuch in allen Ehren. Aber es war etwas zu allgemein
gefaßt und hilft nicht wirklich weiter. Ich hatte die Ursache des
"Nichtverbindens" ja bereits ausgemacht (remote Target war eingeschaltet
und da standen die Parameter): DIe habe ich mittlerweile so angepaßt,
daß da auch 2000 steht. Aber es müßte schon jemand hier antworten, der
die Konfiguration von STM32CubeIDE kennt. Beim Remote Target gibt es ja
eine ganze Menge "Gegenstellen", die man konfigurieren kann. Ich sehe
jetzt auch schon, daß STM32CubeIDE zum blackmagic server (BMDA)
verbindet. Kann den mit blackmagic -v 3 starten und da erscheinen auch
schon die Pakete, die hin- und hergesendet werden. Es sind aber einige
dabei, die BMDA nicht kennt. STM ist in den Foren immer ganz zugeknöpft,
wenn man mit BMP ankommt, insbesondere mit Dongles. Aber hier handelt es
sich ja primär nicht um einen Dongle (der ist zwar hinter dem Server),
sondern um ein Stück Serversoftware, die von GDB aus STM32CubeIDE
angesprochen werden muß.
Ich bin zwar auf Discord mit den BMP Entwicklern im Gespräch, aber die
weisen alles von sich, wenn es um STM32CubeIDE-Konfiguration geht.
Ich glaube aber, ich bin schon ein STück weiter. Mein GDB ist zu alt
(2018).
Uwe B. schrieb:> M.e.a. kann blackmagic nicht die MI GDB Kommandos, "nur" die gdb server> Kommandos.
Punkt ist: ich habe zwei BMP, eine (ältere Version) läuft unter
STM32CubeIDE 13, die neuere nicht. Unter STM32CubeIDE 11 lief die alte
Version problemlos. Die neuere hatte ich unter 11 noch nicht getestet.
Jetzt sagen mir die Entwickler (und Uwe, Du bist ja, glaube ich, da auch
"federführend" beteiligt), ich es könne am IDE liegen, es könne aber
auch an BMP iegen. Um das zu debuggen, sollte ich am besten zu der BMDA
verbinden. Dann könne man die verbose laufen lassen und sähe, was
passiert.
Mittlerweile sieht man auch etwas und ich wurde nach der Version meines
GDB gefragt. Den wollte ich auch gerade auf den neuesten Stand bringen.
Hier habe ich mal den log mit dem BMP server (BMDA):
1
$ ./blackmagic -v 3
2
Black Magic Debug App v1.9.0-997-g0e792331
3
for Black Magic Probe, ST-Link v2 and v3, CMSIS-DAP, J-Link and FTDI (MPSSE)
4
Using 1d50:6018 86764DA9 Black Magic Probe (ST-Link/v2) (Black Magic Debug)
Man kann in der CubeIDE weitere Toolchains installieren.
Mit der 11.2/11.3 hatte ich auch nur Probleme, disconnect beim debuggen
hatte ich ja auch schon geschrieben.
In der 10.x ist ein Speicherleck im malloc für CM0, in Mbed wurde ein
Workaround dafür eingebaut und die newlib Version abgefragt. In der 11er
Toolchain war dann eine neuere newlib drin, aber mit kaputter
Versionsnummer und der Workaround ließ sich damit nicht kompilieren.
Weiteres Highlight: der gdb in der 11er Toolchain hat eine Abhängigkeit
zu Python 3.6, diese Version wurde aber vom OS deinstalliert.
Mit der 12er toolchain sieht das besser aus, ich weiß nicht warum ST
diese fehlhafte toolchain in Cube 1.13.0 verwendet. Tests wurden wohl
wegen Urlaub ausgelassen.
Andere Toolchain aber nicht in Cube 1.10.0 (oder war es 1.11?)
installieren, das schreddert die IDE Installation.
J. S. schrieb:> Man kann in der CubeIDE weitere Toolchains installieren.> Mit der 11.2/11.3 hatte ich auch nur Probleme, disconnect beim debuggen> hatte ich ja auch schon geschrieben.> ...
Ich bin ja froh, daß ich eine Toolchain installiert habe, mit der build
usw. funktioniert. Es ging jetzt zuletzt nur um den GDB (zuvor
8.2.50.20181213-git), den ich jetzt auf GDB 13.1.90.20230307-git
aktualisiert habe, um da alle Eventualitäten im Zusammenhang mit der BMP
auszuschließen. Aber das hat letztlich nichts gebracht. Ich muß warten,
was sich bei den Entwicklern tut.
Wollte mich noch mal kurz melden. Das Entwicklerteam hat das Problem
gefixt und ich arbeite im Moment mit einer gepatchten Version von BMP
(v1.9.0-1005-gf61b937b). Das wird dann in 1.10 drin sein.
Und noch der Vollständigkeit halber (weil das ja eigentlich meine
Ursprungsfrage war): Die Verbindung im GDB-Hardware-Debug-Launcher
(Startup) geht so:
1
set mem inaccessible-by-default off
2
tar extended-remote :2000
3
monitor swdp_scan
4
attach 1
Eigentlich verbindet man ja direkt über das Serial Device, das der
BMP-Dongle anlegt. Aber in dem Falle wurde ein Logging gebraucht, um den
Fehler einzukreisen. Blackmagic kann ja auch mit PROBE_HOST=hosted
HOSTED_BMP_ONLY=0 übersetzt werden und fungiert dann als GDB-Server vor
dem BMP-Dongle. Ähnlich OpenOCD. Aber das brauche ich Euch ja nicht zu
sagen :-)
Uwe B. schrieb:> blackmagic xxx.bin programmiert unterstuetzte Devices auch direkt.
Stimmt. Danke für den zusätzlichen Hinweis. Dazu ist es auch zu
gebrauchen.
Daneben auch noch bmputil und dfu-util.
Thread beobachten
Seitenaufteilung abschalten