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
Pinout & configuration - Categories - System Core - Sys - Mode - Debug : Serial Wire
Immer noch 'Target no device found' Hast du nen funktionierendes Projekt für dieses setup? THX Cheers Detlef
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.
Connect under reset Reset drücken Verbinden klicken Reset los lassen
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
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.
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
Achso. Vergessen. Wie müssen denn die beiden bootjumper stehen, kann es daran liegen?
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.
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?
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.
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?
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
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.
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.
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.
>>>> 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
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.
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.
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
Jetzt wird es langsam Merkwürdig, so schwer ist das eigentlich nicht. Mach doch mal ein Foto vom Aufbau.
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
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.
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)
Detlef _. schrieb: > Muss ich die Signale umlöten Du hättest nichts umlöten sollen, dann hätte es "einfach so" funktioniert.
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.
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
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.
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.