Hallo,
ich wollte mir einen original STLINK kaufen und musste leider
feststellen, dass die Dinger zur Zeit ausverkauft sind. Also habe ich
mir einen Clone besorgt.
Das Problem: Er funktioniert offenbar nicht richtig. An den Breakpoints,
die ich vor dem Start des Debuggens festlege hält er nicht an. Aber an
denen, die ich während des Debuggens hinzufüge schon! Echt 'strange'.
So bringt mir das wenig, da das Programm durchgelaufen ist, bevor ich
den Breakpoint 'im Betrieb' setzen kann.
Kennt dieses Verhalten jemand ? Gibt es hierfür eine Lösung ?
Setup: STLINK Clone, ST-UTIL, VS CODE.
Gruß Peter
Peter schrieb:> dass die Dinger zur Zeit ausverkauft sind.
Kauf dir ein beliebiges NUCLEO 64 oder 144.
Da hast du einen STLink + Controller, bei den neueren sogar einen
STLinkV3
Mit cortex-debug Extension? Das sollte schon ordentlich funktionieren.
Da gibt es ein ‚runToMain‘ oder ähnlich (wurde kürzlich geändert), damit
soll schon im Main angehalten werden.
Werden die BP rot dargestellt? Sonst kann die Adresse evtl nicht
ermittelt werden.
Und in das Debug Terminal gucken ob da Fehler angezeigt werden.
Kevin M. schrieb:> Kauf dir ein beliebiges NUCLEO 64 oder 144.
Ich habe hier Nucleo- und Discovery-Boards, aber ich wollte eine selbst
entwickelte Schaltung debuggen.
J. S. schrieb:> Mit cortex-debug Extension? Das sollte schon ordentlich funktionieren.> Da gibt es ein ‚runToMain‘ oder ähnlich (wurde kürzlich geändert), damit> soll schon im Main angehalten werden.
Genau: Cortex-Debug und "RunToMain" - läuft durch :) !!
Peter schrieb:> Ich habe hier Nucleo- und Discovery-Boards, aber ich wollte eine selbst> entwickelte Schaltung debuggen.
Die kannst du da auch anschließen...
Peter schrieb:> Kennt dieses Verhalten jemand ?
Dieses konkrete Problem kenne ich nicht. Aber die Dinger funktionieren
generell nur eingeschränkt, wenn du nicht stets die aktuelle Firmware
drauf hast, die von der STM32 Cube IDE ggf. vorgeschlagen wird.
Die Clones haben meist nicht die aktuelle STLink Firmware, funktionieren
aber auch. Zur Not mit BMP Firmware, aber die wird auch immer größer und
die Frage ist welcher Controller im Clone drin ist.
Kevin M. schrieb:> Die kannst du da auch anschließen...
Das werde ich morgen mal versuchen.
Stefan ⛄ F. schrieb:> Aber die Dinger funktionieren> generell nur eingeschränkt, wenn du nicht stets die aktuelle Firmware> drauf hast, die von der STM32 Cube IDE ggf. vorgeschlagen wird.
Der STM32Programmer erkennt die Clones und weigert sich das Update
aufzuspielen.
Kevin M. schrieb:> Die wird sich vermutlich genau so weigern, die nutzen nämlich das> gleiche Tool.
Ja kann sein. Ich hatte die Cube IDE empfohlen, weil ich meine ST-Link
Stick bisher immer damit aktualisierte.
Ich habe gerade mal den Cube Programmer 2.10.0 unter Linux versucht, hat
auch ohne Probleme geklappt.
Oder VisualGDB benutzen. Oder Clion. Oder die MCUEclipse oder wie die
heissen. Oder oder oder.
VSC bietet auch zig Möglichkeiten, mal ohne STM proprietäre SW. HAL ist
böse, aber die IDE wird gepriesen?
stutil, openocd, pyocd, bmp: die Transportschicht ist in cortex-debug
sehr austauschbar. Warum deshalb gleich alles über Board werfen und sich
das elende Eclipse ans Bein binden?
Naja, jeder wie er es mag.
Stefan ⛄ F. schrieb:> Ich habe gerade mal den Cube Programmer 2.10.0 unter Linux versucht, hat> auch ohne Probleme geklappt.
Ich habe das Upgrade noch einmal ausprobiert, und zumindest dieses hat
jetzt auch geklappt. Es war etwas 'tricky', da alles in der VirtualBox
läuft, und da musste ich das Gerät 'per Hand' an- und abmelden.
Allerdings wird bei den Breakpoints immer noch nicht angehalten.
Kevin M. schrieb:> Kauf dir ein beliebiges NUCLEO 64 oder 144.>> Da hast du einen STLink + Controller, bei den neueren sogar einen> STLinkV3
Ich habe jetzt ein Discovery-Board verwendet und dort die Reset-Bridge
ausgelötet. Damit funktioniert es nun.
Danke an alle für die Hilfe. Ich werde das nun erstmal so lassen.
Gruß Peter
Peter schrieb:> Ich habe jetzt ein Discovery-Board verwendet und dort die Reset-Bridge> ausgelötet.
Die hättest du ruhig drin lassen können. Oder fällt ein Flugzeug vom
Himmel, wenn der Mikrocontroller deines Discovery Boardes als
Seiteneffekt mit resetted wird?
Boy schrieb im Beitrag #7179243:
> Das kommt davon wenn man china-clones kauft.>> Wer billig kauft kauft zwei mal!> Wer chinaschrott kauft kauft drei mal!
Nun ja, das ist sicher was dran, nur in diesem speziellen Fall ... Wenn
in dem Klon ein echter STM32F10x drin ist, muss der sich mit der
Original-ST-Firmware gleich verhalten wie ein "echter". Selbst wenn da
ein STM32-Klon drin ist, ist so ein exotisches Problem wenig plausibel.
Wird vielleicht die Reset-Leitung des STLink verwendet? Da liegt eine
böse Falle, weil die herausgeführte RST-Leitung die fürs SWIM-, nicht
die fürs SWD-Interface ist ...
