Guten Morgen,
ich wollte mal den J-Link für ein kleines STM32F103 Board probieren.
Mit der JLink Debugger Software von Segger funktioniert das auch, aber
wenn ich aus SW4STM32 debugge, ist das ein Glücksspiel wie lange es
dauert bis zum:
No source available for "0x0"
Ich nenne das mal Todessprung. Habe verschiedene Geschwindigkeiten wie
auch "Auto" probiert, aber ich lande immer wieder dort.
Manchmal kann ich Einzelschritt ausführen, so schnell ich klicken kann
und es läuft eine Weile, manchmal ist schon nach ein paar Schritten
Schluß.
Welche Einstellung kann das sein?
Soviel ich weiss, ist der Treiber für JLink-Debugger und das eclipse
Segger Plugin der Gleiche.
Das Ganze läuft unter Linux.
Danke schon mal
Danke für die Antwort.
Nach der Anleitung habe ich es eingerichtet.
Hast Recht, ich meine den GDB Server.
Ich habe mich an System Workbench gewöhnt und möchte auch dabei bleiben.
Mit ST-Link und SWD funktioniert auch alles Einwand frei.
Das war ein Versuch es mit einem JTAG zu probieren, schon weil ich
inzwischen ein paar Boards mit der JTAG Buchenleiste habe.
Irgend wie hatte ich gehofft, dass es wie beim ST-Link einfach läuft.
Mittlerweile habe ich alle Vorschläge die ich im Netz finden konnte
probiert.
Die 2,4MB grosse LOG Datei habe ich jetzt untersucht und es scheint
alles im Einzelschritt gut zu laufen bis das Erste:
JLINK_IsHalted() returns FALSE
auftaucht. Danach werden alle Register nur mit Null gelesen
JLINK_ReadReg(Rxx) returns 0x00000000
Am besten das gleiche nochmal bei uns im Forum posten bzw. eine Support
Email schreiben. Die J-Link Kollegen helfen dann gerne weiter.
https://forum.segger.com/
Hast Du irgendwo ein Discovery- oder Nucleo-Board von ST rumfliegen? Die
dürftest Du ganz offiziell auf Jlink umflashen. An den SWD-Pins von
denen kannst Du auch andere Targets anschließen. Damit bekämst Du dann
vermutlich eher Support von Segger als mit Deiner dreisten Raubkopie.
Könnte es vielleicht ein elektrisches Problem sein? Wie sieht es mit der
Masseverbindung zwischen Target und Jlink aus? Läuft das SWD über
längere Einzeldrähte oder gar ein Breadboard?
SWD ist halt ein recht fixes serielles Protokoll. Wenn da die Leitungen
nicht für geeignet sind kann es schnell mal zu Problemen kommen.
Daß die Probleme mit dem ST-Link nicht auftreten muss an der Stelle
nicht unbedingt etwas heißen: das JLink ist deutlich mehr auf
Geschwindigkeit optimiert und holt da mehr raus als das ST-Link.
Gerd E. schrieb:> Hast Du irgendwo ein Discovery- oder Nucleo-Board von ST rumfliegen? Die> dürftest Du ganz offiziell auf Jlink umflashen. An den SWD-Pins von> denen kannst Du auch andere Targets anschließen. Damit bekämst Du dann> vermutlich eher Support von Segger als mit Deiner dreisten Raubkopie.
Vermutlich bekommt er noch eher Support aber offiziell ist das auch
nicht erlaubt. Aus den "Terms of use"
https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/> The firmware is for use with evaluation boards only.> It is not for use with custom hardware.
Ich verstehe das jedenfalls so, dass man mit dem umgewandelten J-Link
nur noch das Target auf dem Dev-Board beglücken darf und allenfalls noch
ein anderes Dev-Board anschließen darf aber definitiv keine "custom
hardware" wo ich das Bluepill dazuzählen würde.
@robberknight
Das SWD funktioniert ohne Probleme mit dem ST-Link.
Das J-Link habe ich mit "mal so mit bestellt" zum probieren.
Ich wollte sehen, welche anderen Möglichkeiten das bietet.
Sollte eben JTAG und nicht SWD sein.
Die Verbindung ist direkt das 20pol Flachkabel zwischen J-Link und
Board.
Weiter nichts dazwischen. Verschiedene Geschwindigkeiten habe ich
eingestellt, runter bis zum Fußgänger Betrieb ;)
Mit der Segger Debugger Software läuft es auch, deshalb bin ich der
Meinung das es nur eine Einstellung ist.
@christopher_j23
Das sehe ich auch so. Für ein EFM32 habe ich so ein J-Link Ableger an
Board, dort ist das auch so.
Leider hat auch das offizielle Edu Mini keinen Support, wäre also das
gleiche Glücksspiel, nur teurer.
Im Hinterkopf habe ich da immer noch so etwas wie das zu entfernende:
srst_only aus der Konfiguration beim ST-Link SWD.
Es wäre eben nur Schade und gegen die "Bastler Ehre" wenn es nicht
läuft.
Christopher J. schrieb:> Ich verstehe das jedenfalls so, dass man mit dem umgewandelten J-Link> nur noch das Target auf dem Dev-Board beglücken darf und allenfalls noch> ein anderes Dev-Board anschließen darf aber definitiv keine "custom> hardware" wo ich das Bluepill dazuzählen würde.
Korrekt, ein anderes ST Evalboard anschließen wäre noch ok aber Custom
Hardware oder so geht leider nicht.
pegel schrieb:> Leider hat auch das offizielle Edu Mini keinen Support, wäre also das> gleiche Glücksspiel, nur teurer.
Du würdest definitiv mehr Support bekommen als mit deinem J-Link Clone.
Einfach bei uns im Forum melden, die J-Link Entwickler helfen da weiter.
pegel schrieb:> Irgend wie hatte ich gehofft, dass es wie beim ST-Link einfach läuft.
Das ist genau der Grund, weshalb ich immer wieder beim ST-Link lande.
Nach diversen Versuchen mit J-Links bin ich des Experimentierens leid.
Ich kann absolut nicht nachvollziehen was die Leute immer am J-Link so
toll finden.
Oldie schrieb:> pegel schrieb:>> Irgend wie hatte ich gehofft, dass es wie beim ST-Link einfach läuft.>> Das ist genau der Grund, weshalb ich immer wieder beim ST-Link lande.> Nach diversen Versuchen mit J-Links bin ich des Experimentierens leid.> Ich kann absolut nicht nachvollziehen was die Leute immer am J-Link so> toll finden.
Er benutzt ja keinen J-Link sondern einen J-Link Clone. Die Probleme
haben damit also nichts mit dem J-Link zu tun. Es ist wie immer, es gibt
nicht das perfekte Werkzeug, sondern nur das perfekte Werkzeug für eine
bestimmte Aufgabe. Wenn dir also eine ST-Link ausreicht, ist das doch
super.
Die Leute finden am J-Link z.B. toll, dass er einfach funktioniert und
von allen IDEs unterstützt wird.
Welche Probleme hattest du denn mit dem J-Link?
Til S. schrieb:> Er benutzt ja keinen J-Link sondern einen J-Link Clone. Die Probleme> haben damit also nichts mit dem J-Link zu tun.
Wir haben es verstanden! ;)
Abschliessend:
bei der Suche nach der Fehlermeldung habe ich festgestellt, dass der
Fehler auch bei anderen ARMs und anderen IDEs auftritt.
ich habe extra ein neues Windows installiert, die aktuellen Win
Programme geladen, alles funktioniert mit dem CLONE
Firmware Update sagt es ist die neueste Version.
Bleibt also nur das (Linux?) eclipse Plugin bzw. dessen Einstellungen.
eclipse unter Win habe ich keine Lust mehr zu installieren.
Konsequenz:
ich habe ein teures (7,80€) 20 pol Flachkabel, an das ich den 10 pol
Stecker zum ST-Link anflanschen werde. Na gut, zusammen mit dem Gehäuse
und USB Kabel rechnet es sich sogar. ;)
Alles was Segger ist, wird deinstalliert.
Damit ist dann auch den Lizenzen genüge getan und mein Ausflug in die
Welt von J-Link beendet.
pegel schrieb:> ich wollte mal den J-Link für ein kleines STM32F103 Board probieren.
Nachdem du mir bei meinem BMP/eclipse Problem Tipps gegeben hattest
könntest du das ja auch ausprobieren :)
Ich habe SW4STM32 auch gerade nochmal installiert, es ist ja das gleiche
eclipse das ich verwende, nur mit anderen/weiteren Plugins die zB die
Debugconfig mit dem STLink vereinfacht integriert hat.
Die 'GDB Hardware Debugging' Launch Config ist da auch vorhanden, die
gehört wohl zum Standard CDT PlugIn. Da sind genau die Einstellungen die
ich in meinem Thread Beitrag "Eclipse mit Black Magic Probe"
beschrieben habe.
Wenn dein 'kleines STM32F103 Board' das BluePill ist kann man das als
Debug Hardware nehmen, dafür gibt es auch fertige Binaries. Dann ist
natürlich noch ein zweites Board als Target nötig. Ansonsten lassen sich
auch die China Clones umprogrammieren. Ein originales STLink würde ich
aber nur umprogrammieren wenn du das im Griff hast, die haben einen
verschlüsselten Bootloader und wenn der kaputt ist muss man etwas suchen
um den wiederherzustellen.
Auch wenn ich da noch ein bisschen mit der Konfig kämpfe, ich finde die
BMP ist eine gute Lösung. Die ist einfacher zu konfigurieren weil OOCD
wegfällt und damit ist einfacher zu automatisieren. Vielleicht kann man
ILG noch dazu überreden ein PlugIn dafür zu schreiben :) Aber die
Einstellungen die ich gepostet habe funktionieren schon, ich schreibe da
später noch was dazu.
pegel schrieb:> Abschliessend:>> bei der Suche nach der Fehlermeldung habe ich festgestellt, dass der> Fehler auch bei anderen ARMs und anderen IDEs auftritt.
kann das nicht auch ein Fehler im Code sein? Die Meldung kenne ich als
Nullpointer Zugriff bei Fehler in meinen Quellen. Einmal weil ich C++11
Features benutzt habe aber der Compiler auf C++98 stand, einmal weil
eine HAL Struktur für den FSMC nicht komplett gefüllt war und je nach
Stackinhalt böse Nebeneffekte auftraten.
@jojos
Vielen Dank für den Hinweis.
Ein BMP aus einem BluePill Board habe ich mir auch schon mal erfolgreich
gebaut. Aber nie wirklich benutzt.
Da ich aber mehrere verschiedene STM32 Boards habe die schon selbst
einen ST-Link mit bringen, hat sich bei mir zum Schluss alles auf die
problemlose Funktion und den passenden Stecker reduziert.
So wie bei "Oldie" vermutlich auch.
Wenn es einen funktionierenden China PingPong Adapter mit passendem
Stecker gegeben hätte, hätte ich auch den genommen.
Wie gesagt, reiner Bastler ohne finanzielle Vorteile.
Johannes S. schrieb:> kann das nicht auch ein Fehler im Code sein?
eher nicht.
Mein letzter Versuch war so einfach, dass es praktisch nicht sein kann.
1
while(1)
2
{
3
/* USER CODE END WHILE */
4
5
/* USER CODE BEGIN 3 */
6
HAL_GPIO_TogglePin(LED_GPIO_Port,LED_Pin);
7
HAL_Delay(500);
8
a++;
9
10
}
Manchmal kann ich den Einzelschritt so schnell ich klicken kann
ausführen und es funktioniert bis zum Zeitpunkt X, manchmal komme ich
gar nicht erst bis zu der Stelle.
