STLINK Clone stoppt nicht an Breakpoints

[Peter (Gast)]

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

[Kevin M. (arduinolover)]

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

[J. S. (jojos)]

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.

[Peter (Gast)]

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 :) !!

[J. S. (jojos)]

Wie geschrieben, da wurde was geändert, man muss main oder ein anderes 
Symbol als ersten BP angeben.

[Kevin M. (arduinolover)]

Peter schrieb:
> Ich habe hier Nucleo- und Discovery-Boards, aber ich wollte eine selbst
> entwickelte Schaltung debuggen.

Die kannst du da auch anschließen...

[Stefan F. (Gast)]

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.

[J. S. (jojos)]

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.

[Stefan F. (Gast)]

Hast du denn den Optimierungslevel des Compilers passend eingestellt?
-O0 -O1 oder -Og ?

[J. S. (jojos)]

Wenn main wegoptimiert wird ist was anderes faul.

[Peter (Gast)]

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.

[Stefan F. (Gast)]

Peter schrieb:
> Der STM32Programmer erkennt die Clones und weigert sich das Update
> aufzuspielen.

Du sollst die STM32Cube IDE benutzen.

[Kevin M. (arduinolover)]

Stefan ⛄ F. schrieb:
> Du sollst die STM32Cube IDE benutzen.

Die wird sich vermutlich genau so weigern, die nutzen nämlich das 
gleiche Tool.

[Stefan F. (Gast)]

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.

[Stefan F. (Gast)]

Du könntest versuchen, den OpenOCD Debugger anstatt den ST-Link GDB 
Server zu benutzen. zumindest die Cube IDE enthält beide.

[J. S. (jojos)]

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.

[Peter (Gast)]

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

[Monk (roehrmond)]

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?

[Peter (Gast)]

Steve schrieb:
> 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?

Das nicht, es hat aber ohne auslöten bei mir nicht funktioniert, und 
dann soll man das wohl so machen (siehe Manual 6.1.2):

https://www.st.com/resource/en/user_manual/um1842-discovery-kit-with-stm32f411ve-mcu-stmicroelectronics.pdf

[A. B. (Gast)]

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 ...