Hallo ich möchte mich jetzt mal langsam mit den 32-Bit ARMs auseinandersetzen. Dazu habe ich mir ein AE LPC11U35-MB Board (Baugleich mit dem Eva Board von Embedded Artist) geholt und konnte es via make & copy auch wunderbar bespielen. (https://github.com/olikraus/lpc11u3x-gps-logger) Läuft auch. Das ist übrigens ein schönes Bsp. weil es sauber programmiert wurde und auch einiges der LPC Peripherie verwendet. Jetzt wollte ich mich auch mal ans debuggen machen und bin dazu nach folgender Anleitung vorgegangen: https://embdev.net/articles/STM_Discovery_and_Nucleo_as_Black_Magic_Probe#Using_cheap_STLink-clones Zwei STlink V2 clones hatte ich hier in der Bastelkiste, somit hat sich das angeboten. Abgesehen davon, daß die Anschlußbelegung des internen Programmierports völlig anders war (5V, IO, CLK, GND), hatte es mit dieser Anleitung unter Debian prima funktioniert. Das Teil meldet sich nun brav mit Bus 001 Device 012: ID 1d50:6018 OpenMoko, Inc. Black Magic Debug Probe (Application) und erstellt auch 2 serielle Schnittstellen /dev/ttyACM0 und /dev/ttyACM1. Dann flugs mit dem LPC Board verbunden (SWCLCK, SWDIO, RESET, GND und VCC). gdb-multiarch aufgerufen und mit Server verbunden: Reading symbols from gps_logger.elf... (gdb) target extended-remote /dev/ttyACM0 Remote debugging using /dev/ttyACM0 Soweit noch alles gut. Jetzt aber: (gdb) monitor swdp_scan Target voltage: unknown SW-DP scan failed! Was läuft hier schief? Ich habe die Verbindungen schon x mal überprüft. Kann es sein, daß der Klone andere Anschlußbelegungen in der Black magic FW hat? Den STM konnte man ja mit der original FW programmieren. Hat jemand mal erfolgreich ein Black Magic probe FW auf seinen China STLink-V2 clone geflasht und konnte erfolgreich mit einem LPC verbinden? Irgendwie komme ich hier nicht weiter.
:
Bearbeitet durch User
Die BMP sollte mit den LPC11x klar kommen. Für welche Hardware hast du die gebaut? Standard ist doch erstmal die org. BMP HW, für andere muss man mit SET_PROBE= (aus Gedächtnis) builden.
Ich habe es mit SET_PROBE=stlink gebaut (aus neustem GIT repo). Noch etwas: In blackmagic/src/platforms/stlink/platform.h fiel mir auf, daß der Reset Pin anders definiert war als im ST-Link clone. Im Clone (laut Platinenaufdruck: MX-Link V2, 2016-06-18 mit STM32F101) sind u.a. folgende Anschlüsse nach außen geführt: Reset PB6 SWCLK PA5 SWDIO PB14 Der Reset war in platform.h auf PB0 bzw. PB1. Ich habe das dann angepasst (beide auf PB14 editiert), nochmals compiliert und geladen: Ohne Effekt. Das hatte ich fast vermutet, weil der SWD eigentlich auch ohne Reset funktionieren sollte.
Andreas B. schrieb: > Der Reset war in platform.h auf PB0 bzw. PB1. Ich habe das dann > angepasst (beide auf PB14 editiert) auf PB6 nach deiner Beschreibung, nicht auf PB14? https://github.com/blacksphere/blackmagic/blob/2065c70888a2fda6be845e999550611b59874593/src/target/lpc11xx.c#L168-L179 Also auch 11U35 sollen erkannt werden. Das EA 11U35 QSB habe ich auch noch, kann ich heute Abend ausprobieren. Passt das BMP denn in den F101 rein? mit allen Targets ist das doch schon >64 kB. Das geht ja mit den originalen F103, mit F101 auch? Aber gut, wenn sich das Device schon ordentlich meldet könnte es passen.
Johannes S. schrieb: > auf PB6 nach deiner Beschreibung, nicht auf PB14? Es ist PB14, habe es ausgemessen. Es geht um den STM auf den STLink Adapter, nicht um das Zielsystem. Aber ich habe auch gesehen, daß bei den LPC /Reset auf 1 sein muß, um SWP zu aktivieren. Man braucht also nur SWCLK und SWDIO. Johannes S. schrieb: > Passt das BMP denn in den F101 rein? Scheinbar hat es von der Größe her gepasst. Er hat nicht gemeckert. Oder es gibt irgendwo ein Flag für das Zielsystem, in dem die LPC dann nicht dabei sind. Das muß ich mir dann mal näher anschauen. Johannes S. schrieb: > , kann ich heute Abend ausprobieren. Wäre super. Pass aber mit der Anschlußbelegung des STLink Clones auf. Da gibt es scheinbar unzählige Varianten. Bei mir hatte er z.B. keine 3.3V an diesen 4-er Anschluß, sondern nur die 5V vom USB.
hier ist noch eine gute Seite zu den ganzen Versionen: https://wiki.cuvoodoo.info/doku.php?id=jtag ich habe den 'Original' Baite, aber noch eine Firmwareversion von 2018/02. Da war der Baite noch nicht in der Version enthalten die U. Bonnes danach gebaut hat. Ich habe noch einen Baite nachbestellt und auch gestern noch das aktuelle BMP geholt und kompiliert, aber noch nicht geflasht. Ich wollte meine Änderungen erst nochmal mit dem aktuellen Stand abgleichen. Ansonsten ist BMP auch meine Lieblingsprobe weil man da nix konfiguieren muss. Ich benutze VSCode und ein paar Zeilen in der launch.json reichen um damit alle Möglichen Targets anzusprechen.
Super Link, Danke. Der verwendete STM32F1CBT8 sollte übrigens 128MB Flash haben, wenn ich das DB richtig interpretiere. Das ist mir aber relativ unklar.
Andreas B. schrieb: > Der verwendete STM32F1CBT8 sollte übrigens 128MB Flash haben Es sind 128KB > wenn ich das DB richtig interpretiere. Das ist mir aber > relativ unklar. Daran ist nichts unklar. Außerdem ist die originale ST-Link Firmware auch schon größer als 64KB. Deswegen hat der STM32 auf dem ST-Link auch immer mindestens 128KB Flash.
Axel S. schrieb: > Andreas B. schrieb: >> Der verwendete STM32F1CBT8 sollte übrigens 128MB Flash haben > > Es sind 128KB Gut zu wissen. > >> wenn ich das DB richtig interpretiere. Das ist mir aber >> relativ unklar. > > Daran ist nichts unklar. Mal interessehalber: Wo steht das klipp und klar im DB?
Das B in der Bezeichnung steht für die 128 k, die 64 k haben da eine 8.
Johannes S. schrieb: > Das B in der Bezeichnung steht für die 128 k, die 64 k haben da eine > 8. Ja, genau das dachte ich mir, aber wo steht das?
Ok, Danke! Ich hatte immer weiter oben gesucht.
War jetzt für den 103er, beim 101 aber genau so: https://www.st.com/resource/en/datasheet/stm32f101r8.pdf#page92 ST unterscheidet da zwischen Datasheet und User Manual, da braucht man beide Dokumente.
Johannes S. schrieb: > Das B in der Bezeichnung steht für die 128 k, > die 64 k haben da eine 8. Leider ist das an sich schon eine Falle. Der Font, mit dem ST seine µC lasert, ist nicht sonderlich leserlich. Da passiert es schnell, daß man "8" und "B" verwechselt. Sie hätten besser zwei Zeichen genommen, die sich deutlich unterscheiden. Andreas B. schrieb: > Ich hatte immer weiter oben gesucht. Bei anderen Typen steht das auch weiter vorne, bei "Device overview". Für den F103 stehen dort nur die Varianten verschiedener Pin-Anzahl. Allerdings findet man es immer unter "Ordering information"
Axel S. schrieb: > Allerdings findet man es immer unter "Ordering information" Wenn es um Gehäuse geht, dann suche ich auch dort. Bei sonstigen Features eher weniger.
Also, das Problem ist jetzt gelöst. Auf Verdacht habe ich mal ein simples Blink Programm (vom gleichen GIT repo) auf den LPC geladen und siehe da: Es funktioniert. Dann habe ich mal den o.a. Code des GPS loggers näher angeschaut und entdeckt, daß in der Graphics library Steuertasten definiert sind, u.a. auch für den Pin 15, der für SWCLK vorgesehen ist. Lustigerweise hatte ich diesen PIN vorher schon umgelegt, weil er vorher für die SD Karte verwendet wurde. Er war so also 2x definiert. Was die Aussage über die saubere Programmierung dieser SW betrifft, nehme ich das ganz entschieden zurück. Die wurde vermutlich irgendwo zusammen kopiert.
Hätte mich auch ehrlich gewundert wenn es nicht ginge. Wenn SWD umprogrammiert wurde kann man in den Bootloader starten und kommt dann wieder per Debugger dran. Ich muss noch einen Adapter bauen, dazu konnte ich mich gestern nicht mehr aufraffen.
Der Vollständigkeit halber wollte ich noch erwähnen daß der Reset Pin, wie schon gedacht, nicht benötigt wird. Die Änderung in der platform.h ist, zumindest für SWD, nicht notwendig.
Wenn Ihr eine aktuelle ST Stlink Firmware habt, dann benutzt doch die BMP Variante blackmagic_stlinkv2, die auf dem PC laeuft. Die bekommt Ihr mit "make PROBE_HOSt= pc-stlinkv2" kompiliert. In GDB verbindet Ihr euch mit "tar(get) ext(ended) :2000". Die BMP Varianten, die auf dem PC laufen (libftdi/stlink/BMP(firmware, cmsis_dap(extra branch))" kann man dann auch auf der Kommandozeile benutzen: "blackmagic_xxxx bla.bin" flascht bla.bin nach 0x08000000, "blackmagic_xxxx -V bla.bin" vergleicht bla.bin mit dem Flashinhalt ab 0x0800000. Hilfe mit -h.
Der Vorteil bei Black magic probe ist ja eigentlich gerade der, daß der Server da schon eingebaut ist. Welche Vorteil hätte es jetzt, den Server auf dem PC laufen zu lassen? Der Black magic, so wie er ist, läuft auch prima mit mcuXpresso zusammen. Ich bin gerade so am eruieren, ob ich es mit dieser GUI statt make + Editor versuchen sollte.
BMP/firmware hat den Nachteil, dass man Debugausgabe nur mit Neuflashen und umstaendlichen aktivieren der zweiten Konsole bekommt, dafuer aber den Server nicht extra starten muss. BMP/PC-hosted braucht kein umflaschen des Stlink und ist einfach mit Nucleos, Discos und STlinks zu verwenden. Im Gegensatz zu OpenOCD braucht man auch keine Unzahl von Konfigurationsoptionen. Dafuer kennt BMP weniger Devices. Und man kann auch noch andere Programme verwenden, z.B. pyOcd, Stm32CubeProgrammer, OpenOCD u.s.w. Kann jeder selbst entscheiden. Bevor man umflasht, kann man auch ersteinmal eine PC version verwenden. Und beim STLInkV2 kann man auch den original ST Bootloader drauflassen. Mit ""make PROBE_HOST=stlink ST_BOOTLOADER=1" erhaelt man ein executable, dass ab 0x08004000 laeuft. Das kann man mit stlink-tool dann flaschen. Allerdings muss man nach jeden Kaltstart des Debuggers nochmals stlink-tool aufrufen, um den Bottloader zu verlassen. Mit dem Setup kann man dann auch wieder die ST Firmware flashen.
OpenOCD braucht man hier ja gerade nicht. Ein einfacher Aufruf von >gdb-multiarch -ex "target extended-remote /dev/ttyACM1" genügt. Wie man den zum BMP umgeflashten ST-Link clone in mcuXpresso integriert, steht hier: http://kinetis3.rssing.com/chan-12390620/latest.php#item11 Ich finde, einfacher geht es wirklich nicht mehr. Und das umflashen braucht ca.15 min. Die meiste Zeit kostet dabei, die Anschlußbelegung des internen SWP herauszufinden und die Kabel da anzulöten. Wenn ich wirklich die original FW wieder bräuchte, nehme ich einen 2.Stick. Die kosten ja nichts. (den 2.Stick habe ich zum umflashen sowieso gebraucht ;-) )
Fuer die Clones mag das Stimmen, fuer die Stlinks auf den St Boards ist da eine ganz andere Sache.
Angehängte Dateien:
-
DSC07756.JPG
150 KB
Uwe B. schrieb: > Fuer die Clones mag das Stimmen, fuer die Stlinks auf den St Boards ist > da eine ganz andere Sache. Das ist eben der Vorteil bei dem China Billigkram. Da hat man keine Hemmungen ;-). Siehe auch: Ein schönes Gimmik kann man den Clones noch beibringen: Der zweite serielle Port läßt sich schön verwenden, wenn man PA2 von Pin12 (Tx) und PA3 (Rx) von Pin13 nach draußen bringt. Die stlink Platform hat das SW seitig bereits vorgesehen. Das ist zwar etwas Fummelei, wird aber mit einem zusätzlichen Com Port belohnt. Ich habe dazu die beiden 5V Anschlüsse 9+10 des Connectors verwendet (rot-Leiterbahnunterbrechung. Grün-neue Verbindung). Ich habe das so gemacht, damit man den Draht nicht auf die andere Platinenseite bringen muß. Wer die 5V haben will, muß halt den 2. GND unterbrechen (geht hier auch von oben). Gerade mal getestet: Bis 2 MBaud geht der Port auf jeden Fall.
:
Bearbeitet durch User
Den ersten Port verwendest Du aber bitte fuer SWO :-)
Angehängte Dateien:
-
BMP-LPC824.jpg
170 KB
Wegen der seriellen Schnittstelle gefällt mir der Baite besser, der hat schon zwei Leitungen (ursprünglich für SWIM) die man für die serielle benutzen kann. Da muss man nur einen R rausoperieren.
Uwe B. schrieb: > Den ersten Port verwendest Du aber bitte fuer SWO :-) Aber klar. ;-) Ist ja schon erfolgreich gelaufen. Johannes S. schrieb: > Wegen der seriellen Schnittstelle gefällt mir der Baite besser, der hat > schon zwei Leitungen (ursprünglich für SWIM) die man für die serielle > benutzen kann. Da muss man nur einen R rausoperieren. Den SWIM hat der Clone auch, wobei ich nicht weiß wofür der gut ist. Den Baite habe ich auch noch nie gesehen. Wo gibt es den denn?
Habe ich auch von Ali, die sind tatsächlich seltener als die bunten, metallicfarbenen. https://m.de.aliexpress.com/item/32322884886.html ‚Schwimmen JTAG‘ ist für die STM8 Serie.
Angehängte Dateien:
-
Gede_general.png
49 KB -
Gerde_commands.png
19 KB -
Gede_running.png
170 KB
Da wir gerade am debuggen sind, noch ein Tip: Gede (gibt es gerade brandneu hier: http://acidron.com/gede/pmwiki.php?n=Main.HomePage) funktioniert ganz hervorragend mit dem BMP und den LPC. Wer also Editor und Make bevorzugt, ist mit gede bestens bedient. Einstellungen siehe Bilder. Ansonsten habe ich mich jetzt für mcuXpresso entschieden. Das läuft zwar als Basis mit Eclipse, startet aber erheblich schneller als alles was ich bisher mit Eclipse gesehen habe. Beim testen mit dem Uart ist dieser 2.serielle Port übrigens schon sehr praktisch.
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.