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?
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.
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).
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.
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 :-)
