Forum: Mikrocontroller und Digitale Elektronik BluePill, ST-LINK und CubeIDE


von Detlef _. (detlef_a)


Lesenswert?

Hi,

ich möchte gerne nen BluePill an einem ST-LINK mit CubeIDE 1.7.0 
bespaßen.
Ich habe vom Bluepill 3V3/GND/SWCLK/SWIO zum ST-LINK verbunden. Den 
ST-LINK habe ich von einem evalboard von ST abgebrochen und für 
3V3/GND/SWCLK/SWIO die Brücken entsprechend umgelötet.

Jetzt findet er BluePill nicht: No device found.

Bei 'Edit launch configuration properties' habe ich als Interface 'SWD' 
gewählt und als Debug Probe 'ST-LINK GDB Server'

In Beitrag "STM32 CubeIDE und STLink V2 Debugger instabil" lese ich
>>>>>
>> Hast du in Cube MX das SWD Debugging aktiviert?
Gefunden, das wars, besten Dank.
<<<<<<

Liegt es daran, wo stellt man denn 'SWD Debugging' bei CubeIDE ein?
Wie kriege ich den BluePill unter ST-LINK und aktuellem CubeIDE zum 
Fliegen?

THX
Cheers
Detlef

von NichtWichtig (Gast)


Lesenswert?

Pinout & configuration - Categories - System Core - Sys - Mode - Debug : 
Serial Wire

von Detlef _. (detlef_a)


Lesenswert?

Immer noch 'Target no device found'

Hast du nen funktionierendes Projekt für dieses setup?

THX
Cheers
Detlef

von NichtWichtig (Gast)


Lesenswert?

Möglicherweise ein Fake BluePill.

Hab da auch 5 Stück von die nur seriell programmiert werden können.

Die Einstellung in CubeMX würde ja auch erste greifen wenn das Projekt 
damit geflasht wurde.

Womöglich hilft einmal seriell löschen.

von pegel (Gast)


Lesenswert?

Connect under reset

Reset drücken
Verbinden klicken
Reset los lassen

von Hermann S. (diphtong)


Lesenswert?

Hmm...ich hatte mal mehrere Blue Pills (gefälscht?) mit anderer HW ID, 
als originale.
Das führte bei mir zu dem Problem, dass der nicht gefunden wurde.
Ich hatte dann in irgendeinem Textdokument die HW ID geändert, schon 
funktionierte es.

Post #9:
https://www.eevblog.com/forum/microcontrollers/stm32f103t8u6-not-recognized-by-cubeide-as-genuine/

: Bearbeitet durch User
von Stefan F. (Gast)


Lesenswert?

Verbinde auch den Reset Pin, dann ist es egal ob die Software auf dem 
Mikrocontroller die SWD Schnittstelle deaktiviert.

Ich glaube es wäre nicht nötig gewesen, irgendwelche Brücken zu ändern.

Manchmal hilft es, das Bluepill Board separat mit Strom zu versorgen, 
z.B. über ein zweites USB Kabel.

von Detlef_A (Gast)


Lesenswert?

Klappt immer noch nicht. Wann muss ich diesen Resetknopf denn loslassen, 
ist glaube ich ein timingproblem. Oder wie geht das sonst mit dem 
händischen reset? Swd debugging ist eingeschaltet im Code des Projekts. 
An der Stromversorgung liegt es nicht, an Fakes oder Hardware id auch 
nicht, soweit kommt er gar nicht, das vorprogrammiert blinkyblinky geht.

Thx
Detlef

von Detlef_A (Gast)


Lesenswert?

Achso. Vergessen. Wie müssen denn die beiden bootjumper stehen, kann es 
daran liegen?

von Stefan F. (Gast)


Lesenswert?

Detlef_A schrieb:
> Wann muss ich diesen Resetknopf denn loslassen

Das richtige Timing ist schwierig. Deswegen kontrolliere das Board erst 
mal mit einer Reset-Leitung. Wenn es damit klappt, kannst du den 
manuellen Vorgang ohne Reset immer noch trainieren. Dazu gibt es 
hilfreiche Youtube Videos die es vorführen.

>  Swd debugging ist eingeschaltet im Code des Projekts.

In dem Projekt dass du hochladen willst, oder in dem Projekt das gerade 
installiert ist? Oft werden die Boards mit einem Bootloader und 
LED-Blinker Programm ausgeliefert, da ist dann SWD und JTAG in der Regel 
deaktiviert.

Du kannst den Start des Programms verhindern, indem du den Boot0 Jumper 
auf HIGH setzt. Also gleiche Prozedur, also ob du über den seriellen 
Port hochladen willst. SWD geht dabei ebenfalls - es sei denn du hast 
einen Fake Mikrocontroller der kein SWD kann.

von Stefan F. (Gast)


Lesenswert?

Detlef_A schrieb:
> Wie müssen denn die beiden bootjumper stehen, kann es
> daran liegen?

Normalerweise beide auf LOW. Mit Boot0=HIGH aktivierst du (beim nächsten 
Reset) den seriellen Bootloader.

http://stefanfrings.de/stm32/stm32f1.html#boot

Lies auch
http://stefanfrings.de/stm32/stm32f1.html#proginterfaces
http://stefanfrings.de/stm32/cube_ide.html#flash
http://stefanfrings.de/stm32/stm32f1.html#bluepill

> die Brücken entsprechend umgelötet.

Was genau hast du verändert?

von Hermann S. (diphtong)


Lesenswert?

Stefan ⛄ F. schrieb:
> Detlef_A schrieb:
>> Wann muss ich diesen Resetknopf denn loslassen
>
> Das richtige Timing ist schwierig.

Eigentlich gar nicht. Wenn kein SW-Reset eingestellt ist:
Jumper auf boot, USB abstecken, USB anstecken, fertig. Da brauchts gar 
keinen Reset-Knopf (bei meinen Blue Pills zumindest).

Wenn SW-reset eingestellt, braucht man gar nix machen.

Nutzt Du irgend einen USB-Hub oder USB Verlängerung? Da hatte ich auch 
schon Probleme.

von J. S. (jojos)


Lesenswert?

Mit dem aktivierten Bootloader kann man auch flashen, das ist auch eine 
sichere Methode wenn die Software die SWD Pins deaktiviert hat oder in 
einem Sleep mit WFI (wait for interrupt) hängt.
Ich würde auch auf ein Problem mit SDIO/SCLK tippen. Wenn der Programmer 
sich an einer falschen CPU stört, dann sieht die Fehlermeldung anders 
aus, es wird die falsche/unbekannte ID angezeigt.
Der STM32CubeProgrammer ist da etwas geschwätziger, zum Testen der 
Verbindung würde ich erstmal damit anfangen.
Bei den 'richtigen' STLink ist VTarget ein Eingang, da möchte der 
Programmer die Spannung des Target rückgemeldet bekommen, ist also keine 
Versorgung des Targets. Hast du die Spannung am BluePill gemessen wenn 
das angeschlossen ist?

von Detlef_A (Gast)


Lesenswert?

Oh. Vielen Dank. Sehr viel input.

Der bluepill hängt gar nicht am USB,  nur an 3v3/gnd/swclk/swio. Alle 
Strippen kommen vom ST-Link. Den hab ich von einem evalboard stm32f303 
abgebrochen. Die Brücken am ST-link hab ich entsprechend schematic so 
umgelötet dass die 4 pinheads richtig auf den bluepill passen. Das passt 
schon sind ja nur zwei plus supply.

Den cubeprogrammer probier ich mal aus, kenn ich noch nicht. Spannung 
passt schon, der uC läuft ja und blinkert wie verrückt.

Ich verbinde noch reset und vtarget, vllt. hilft das ja.

Stefan, das Ding kann man auch ohne ST-link direkt über  USB flashen?!

SWD debugging ist eingestellt in dem Projekt das ich hochladen will. 
Kann das laufende blinkyblinky verhindern dass ich über SWD rankomme?

Wie kann ich denn rauskriegen ob ein bootloader an board ist?

Thx
Detlef

von Stefan F. (Gast)


Lesenswert?

Detlef_A schrieb:
> Stefan, das Ding kann man auch ohne ST-link direkt über  USB flashen?!

Nein, nur per SWD, JTAG und seriell.

Es gibt andere STM32 Modelle die man auch über USB flashen kann, aber 
nicht den STM32F103. Wobei ... Es gibt da den STM32duino Bootloader 
(basierend auf dem ehemaligen Maple Bootloader). Damit kann man über USB 
Flashen, aber man muss den erst mal installieren und die Programme dazu 
anpassen. Ich bin damit nicht glücklich geworden.

Steht alles auf meiner Homepage.

von Stefan F. (Gast)


Lesenswert?

Detlef_A schrieb:
> Die Brücken am ST-link hab ich entsprechend schematic so
> umgelötet dass die 4 pinheads richtig auf den bluepill passen. Das passt
> schon sind ja nur zwei plus supply.

Ich habe mir jetzt nochmal extra die Dokus der beiden Boards angeschaut. 
Meiner Meinung nach lässt sich das durch die Jumper nicht passend 
konfigurieren, dass die vier Pins in identischer Reihenfolge 
nebeneinander liegen.

Mit falscher Pinbelegung kann es nicht funktionieren. Insofern denke 
ich, dass du das nochmal ganz genau überprüfen solltest.

Und probiere wie gesagt, dass Bluepill Board separat mit Strom zu 
versorgen. Bei mir hat das schon öfters geholfen.

von W.S. (Gast)


Lesenswert?

Detlef_A schrieb:
> Wie kann ich denn rauskriegen ob ein bootloader an board ist?

Durch einen (gewagten) Blick ins zugehörige Manual.

Soweit ich weiß haben eientlich alle STM32 einen Bootlader. Und der 
steht in einem separaten ROM und nicht in dem Adreßbereich, den man für 
seine eigene Firmware benutzen kann. Du kannst ihn also nicht löschen. 
Weder versehentlich noch mutwillig.

Lies einfach mal das zu deinem Chip gehörige Manual, damit du nicht 
derart ahnungslos bleibst.

W.S.

von Detlef_A (Gast)


Lesenswert?

>>>>
Ich habe mir jetzt nochmal extra die Dokus der beiden Boards angeschaut. 
Meiner Meinung nach lässt sich das durch die Jumper nicht passend 
konfigurieren, dass die vier Pins in identischer Reihenfolge 
nebeneinander liegen.
<<<<<<
Nein, die kreuzen sich :).

>>>>
Steht alles auf meiner Homepage

Da geht's heute Abend weiter.

>>>>>>>
Lies einfach mal das zu deinem Chip gehörige Manual, damit du nicht 
derart ahnungslos bleibst.
<<<<<<<

Achso. Gute Idee, wär ich nie drauf gekommen.

Thx
Detlef

von erklehr behr (Gast)


Lesenswert?

Detlef_A schrieb:
> Achso. Gute Idee, wär ich nie drauf gekommen.

Du bist auch auf andere Dinge nicht gekommen. So erkennt
man dass du nicht recht den Überblick hast.

Es gibt hier im Forum eine "Markierten Text zitieren" - Funktion.

von Stefan F. (Gast)


Lesenswert?

Hermann S. schrieb:
>> Das richtige Timing ist schwierig.
> Eigentlich gar nicht.

Ich habe gerade nochmal den manuellen Druck auf den Reset-Button 
ausprobiert. Das Timing ist tatsächlich nicht mehr kritisch. Man hält 
den Knopf zunächst gedrückt, und sobald im Console Fenster der Cube IDE 
die ersten Meldungen des Debuggers erscheinen, kann man loslassen. Der 
GDB wartet ziemlich geduldig, auf ein paar Sekunden mehr oder weniger 
kommt es nicht an.

Alternativ kann man die IDE auf Software Reset umstellen, aber das 
funktioniert nur, wenn der Mikrocontroller weder schläft, noch die SWD 
Schnittstelle deaktiviert hat (was mit Arduino und Cube MX erstellte 
Programme standardmäßig tun).

Das wiederum kann man aber wie gesagt verhindern, indem man den Boot0 
Jumper auf HIGH stellt und dann den Reset Knopf drückt. Denn dann 
startet das Programm nicht, sondern der Bootloader, welcher die SWD 
Schnittstelle eingeschaltet lässt.

von Detlef _. (detlef_a)


Angehängte Dateien:

Lesenswert?

Hi,

ich habe nochmal weitergeforscht und bin per scope darauf gekommen, dass 
CubeIDE in meiner Konfiguration die Signale T_JTCK und T_JTMS bespaßt, 
siehe angehängter Schaltplanausschnitt. Ich hab den Bluepill an STM_JTCK 
und STM_JTMS gehängt, da tut sich garnix. Muss ich die Signale umlöten 
oder kann man das bei CubeIDE umkonfigurieren?

THX
Cheers
Detlef

von pegel (Gast)


Lesenswert?

Jetzt wird es langsam Merkwürdig, so schwer ist das eigentlich nicht.

Mach doch mal ein Foto vom Aufbau.

von Detlef _. (detlef_a)


Lesenswert?

Hi nochmal,

looft, der Dreck.

Ich HABE die Signale umgelötet und ging auf Anhieb, kein Problem mit dem 
timing. Er lädt und verifiziert das Programm.

Die LED PC13 vom bluepill ist an wenn ich PC13 als output konfiguriere, 
ansonsten aus. Ich kann sie auch nicht ausschalten, vllt. läuft das 
Programm nicht los. Stefan, hast Du da ne Idee?

Bis hierher vielen Dank, die infos auf Stefans website sind Gold wert. 
Und an den Bären danke für den Hinweis wie blöd ich eigentlich bin, 
hatte ich auch fast vergessen.

THX
Cheers
Detlef

von pegel (Gast)


Lesenswert?

Detlef _. schrieb:
> von einem evalboard von ST abgebrochen

Das war vielleicht der Fehler, dadurch wurden vermutlich SWCLK oder 
SWDIO getrennt.

Hättest nur die die SWD Jumper ziehen müssen.

von Harry L. (mysth)


Angehängte Dateien:

Lesenswert?

Also. ich versteh ehrlich gesagt den ganzen Aufriss nicht.

Ich hab das eben mal auf die Schnelle mit nem Bluepill und einem 
Nucleo-Board getestet, und das lief auf Anhieb, auch ohne irgend etwas 
umzulöten.

* Die beiden Jumper auf dem Programmer-Teil des Nucleo gezogen
* Vtarget, SWCLK, SWDIO und GND mit dem Bluepill verbunden
* Neues Project erzeugen, STM32F103R8Tx als MCU auswählen
* SWD-Debugging im CubeMX aktivieren
* Code generieren

* Debugger starten sieht dann so aus:
1
STMicroelectronics ST-LINK GDB server. Version 6.1.0
2
Copyright (c) 2022, STMicroelectronics. All rights reserved.
3
4
Starting server with the following options:
5
        Persistent Mode            : Disabled
6
        Logging Level              : 1
7
        Listen Port Number         : 61234
8
        Status Refresh Delay       : 15s
9
        Verbose Mode               : Disabled
10
        SWD Debug                  : Enabled
11
        InitWhile                  : Enabled
12
13
Waiting for debugger connection...
14
Debugger connected
15
Waiting for debugger connection...
16
Debugger connected
17
Waiting for debugger connection...
18
      -------------------------------------------------------------------
19
                        STM32CubeProgrammer v2.10.0                  
20
      -------------------------------------------------------------------
21
22
23
24
Log output file:   /tmp/STM32CubeProgrammer_ZJQwGO.log
25
ST-LINK SN  : 0671FF495252717267203806
26
ST-LINK FW  : V2J39M27
27
Board       : NUCLEO-F412ZG
28
Voltage     : 3,25V
29
SWD freq    : 4000 KHz
30
Connect mode: Under Reset
31
Reset mode  : Hardware reset
32
Device ID   : 0x410
33
Revision ID : Rev X
34
Device name : STM32F101/F102/F103 Medium-density
35
Flash size  : 64 KBytes
36
Device type : MCU
37
Device CPU  : Cortex-M3
38
BL Version  : --
39
40
41
42
Memory Programming ...
43
Opening and parsing file: ST-LINK_GDB_server_p1jUSi.srec
44
  File          : ST-LINK_GDB_server_p1jUSi.srec
45
  Size          : 5,90 KB 
46
  Address       : 0x08000000 
47
48
49
Erasing memory corresponding to segment 0:
50
Erasing internal memory sectors [0 5]
51
Download in Progress:
52
53
54
File download complete
55
Time elapsed during download operation: 00:00:00.443
56
57
58
59
Verifying ...
60
61
62
63
64
Download verified successfully

...und läuft. (die leere Endlosschleife)

von pegel (Gast)


Lesenswert?

Detlef _. schrieb:
> evalboard von ST

Da gibt es viele Möglichkeiten...

Hat sich aber Erledigt.

von Monk (roehrmond)


Lesenswert?

Detlef _. schrieb:
> Muss ich die Signale umlöten

Du hättest nichts umlöten sollen, dann hätte es "einfach so" 
funktioniert.

: Bearbeitet durch User
von Monk (roehrmond)


Lesenswert?

Detlef _. schrieb:
> Die LED PC13 vom bluepill ist an wenn ich PC13 als output konfiguriere,
> ansonsten aus. Ich kann sie auch nicht ausschalten, vllt. läuft das
> Programm nicht los.

Das PC13 als Ausgang aktiv wurde beweist, dass das Program los gelaufen 
ist. Der Fehler steckt wohl eher in dem uns unbekannten Programm.

Bei LOW muss die LED leuchten, bei HIGH geht sie aus - ergibt sich aus 
dem Schaltplan. Anders herum soll man diesen Pin nicht nutzen. Dazu gibt 
es besondere Hinweise im Datenblatt, Fußnote 5 unter der Tabelle mit der 
Pinbelegung.

: Bearbeitet durch User
von Detlef _. (detlef_a)


Lesenswert?

Hallo,

BluePill läuft tadellos. Allerdings auf dem internen RC 8MHz als 
Oczillator. Bluepill hat ja auch einen externen 8MHz Quarz. Wie krieg 
ich den denn über CubeIDE an den Start?

Es reicht nicht die PD0/PD1 als Osc-Pins zu konfigurieren. Wie kann ich 
in der clocktree Konfiguration den externen 8MHz ( der ist schon 
eingezeichnet, allerdings ausgegraut ) mit dem Eingang verbinden, auch 
ausgegraut?

THX
Cheers
Detlef

: Bearbeitet durch User
von Vorname N. (mcu32)


Lesenswert?

System Core -> RCC -> High Speed Clock (HSE) die Option Crystal / 
Ceramic Resonator.

Aber mal ehrlich , ein wenig solltest du dich schon mit der IDE 
auseinandersetzen.

von Stefan F. (Gast)


Angehängte Dateien:

Lesenswert?

Detlef _. schrieb:
> Bluepill hat ja auch einen externen 8MHz Quarz. Wie krieg
> ich den denn über CubeIDE an den Start?

Du musst in Cube MX den HSE Oszillator aktivieren und die Frequenz 
einstellen.

von Detlef _A (Gast)


Lesenswert?

Ah, geht.
Vielen Dank
Cheers
Detlef

Bitte 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
Noch kein Account? Hier anmelden.