Versuche gerade unter STM32CubeIDE ein Projekt laufen zu lassen, was
vermeintlich mal funktioniert hat. Wenn ich es baue und laufen lassen
will, bekomme ich:
1
STMicroelectronics ST-LINK GDB server. Version 5.8.0
2
Copyright (c) 2020, STMicroelectronics. All rights reserved.
Opening and parsing file: ST-LINK_GDB_server_uM7eEK.srec
37
File : ST-LINK_GDB_server_uM7eEK.srec
38
Size : 6156 Bytes
39
Address : 0x08000000
40
41
42
Erasing memory corresponding to segment 0:
43
Erasing internal memory sector 0
44
Download in Progress:
45
46
47
File download complete
48
Time elapsed during download operation: 00:00:00.396
49
50
51
52
Verifying ...
53
54
55
56
57
Download verified successfully
58
59
60
Error! Failed to read target status
61
Debugger connection lost.
62
Shutting down...
STM32F407-DIYMORE-Board hängt am STLINK des STM32F407VG-DISC1. Jumper
von CN3 off (ST-LINK aktiv). DIYMORE über SWD 2-4-6 (SCLK, SWIO,RESET)
mit dem Target verbunden.
Was mache ich falsch?
Christoph K. schrieb:> DIYMORE über SWD 2-4-6 (SCLK, SWIO,RESET)> mit dem Target verbunden.
Sehr merkwürdig. Ich hätte noch GND erwartet. Und beim DIYMROE ist der
Reset auch gar nicht auf einen Pin geführt.
Zum Testen der Verbindung macht das ST-Link-Utility übrigens deutlich
mehr Spaß als der GDB-Server.
Christoph K. schrieb:> Download verified successfully> Error! Failed to read target status> Debugger connection lost.
Das hört sich nach dem üblichen SWD Pin deaktivieren im Programm an.
Walter T. schrieb:> Christoph K. schrieb:>> DIYMORE über SWD 2-4-6 (SCLK, SWIO,RESET)>> mit dem Target verbunden.>> Sehr merkwürdig. Ich hätte noch GND erwartet. Und beim DIYMROE ist der> Reset auch gar nicht auf einen Pin geführt.>
Hatte eine Reset Leitung an das DIYMORE angelötet.
GND ist natürlich durchverbunden über Poweranzapfung.
> Zum Testen der Verbindung macht das ST-Link-Utility übrigens deutlich> mehr Spaß als der GDB-Server.
Ach, ich hatte mal wieder vergessen, den BOOT0-Jumper zu setzen auf
diesem Board.
Erledigt.
Vielleicht sollte ich für die sich gleich anschließende Frage einen
neuen Thread aufmachen, aber wie kriege ich es innerhalb des IDE hin,
daß ich mal auf einem Breakpoint anhalten kann?
1
STMicroelectronics ST-LINK GDB server. Version 5.8.0
2
Copyright (c) 2020, STMicroelectronics. All rights reserved.
Christoph K. schrieb:> aber wie kriege ich es innerhalb des IDE hin,> daß ich mal auf einem Breakpoint anhalten kann?
Die klassische Antwort lautet: Den Breakpoint irgendwo hinmachen, was
nicht wegoptimiert wird. Im schlimmsten Fall fügt man eine
volatile-Variable hinzu, die genau für diesen Zweck beschrieben wird.
//FIXME-Kommentar nicht vergessen. Sonst wundert man sich u.U. Wochen
später, warum eine bestimmte Variable volatile ist.
Walter T. schrieb:> Christoph K. schrieb:>> aber wie kriege ich es innerhalb des IDE hin,>> daß ich mal auf einem Breakpoint anhalten kann?>> Die klassische Antwort lautet: Den Breakpoint irgendwo hinmachen, was> nicht wegoptimiert wird. Im schlimmsten Fall fügt man eine> volatile-Variable hinzu, die genau für diesen Zweck beschrieben wird.> //FIXME-Kommentar nicht vergessen. Sonst wundert man sich u.U. Wochen> später, warum eine bestimmte Variable volatile ist.
Gut, das kann ja mal in komplexeren Fällen nötig sein, aber in so einem
elementaren Programm wie dem blinky? Warum macht er denn ein disconnect?
Habe mal einen Screenshot hinzugefügt. Habe auch ein volatile eingebaut
und zwei Breakpoints gesetzt (siehe Bild). Nichts passiert.
Auch, wenn ich mal die onboard MCU debugge, also Jumper CN3 auf
DISCOVERY setze, so kriege ich kein Anhalten (Regular breakpoint) hin.
Walter T. schrieb:> Im schlimmsten Fall fügt man eine volatile-Variable hinzu, die genau für> diesen Zweck beschrieben wird.
Alternativ: alles, was auf Hardware zugreift (LED einschalten oder so),
das kann auch nicht weg optimiert werden. Oder ein kurzes
Christoph K. schrieb:> Habe auch ein volatile eingebaut und zwei Breakpoints gesetzt
Setz doch mal eine auf das Schalten der LED.
Wenn das auch nicht geht, dann hat dein Debugger irgendwie ein Problem.
Zeile 89 und 96 enthalten keinen ausführbaren Code, da kann man nicht
anhalten.
pin_state=0 ist hier ein Sonderfall. Innerhalb einer Funktion wäre das
ausführbarer C Code, aber außerhalb definiert es nur den initialen Wert
der Variable. Alle globalen Variablen werden von einem Stück Assembler
Code initialisiert, der noch vor der main() Funktion ausgeführt wird.
Konzentriere dich auf die Inhalte von Funktionen:
1
intmain()
2
{
3
...
4
}
Die Zeilen an der Stelle von ... kann man debuggen, und alles, was von
dort aufgerufen wird.
Wenn du das Programm bei Änderungen von variablen anhalten willst, musst
du eine andere Funktion verwenden. Sie heißt "watchpoint". Das ist in
einer separaten View versteckt, die du gerade nicht offen hast.
Ich habe die IDE am Arbeitsplatz nicht installiert, sonst könnte ich dir
einen Screenshot davon zeigen.
Schau mal hier: https://www.youtube.com/watch?v=Z3lQ2mFa1xI
Da ist eine andere IDE, aber sie ist ähnlich.
Stefan ⛄ F. schrieb:> Zeile 89 und 96 enthalten keinen ausführbaren Code, da kann man nicht> anhalten.>> pin_state=0 ist hier ein Sonderfall. Innerhalb einer Funktion wäre das> ausführbarer C Code, aber außerhalb definiert es nur den initialen Wert> der Variable. Alle globalen Variablen werden von einem Stück Assembler> Code initialisiert, der noch vor der main() Funktion ausgeführt wird.>> Konzentriere dich auf die Inhalte von Funktionen:>>
1
>intmain()
2
>{
3
>...
4
>}
5
>
pin_state=0 ist ja eine Zuweisung innerhalb der Funktion (main.c).
Also muß ich da auch einen BP hinsetzen können.
Habe jetzt mein DIYMORE Board abgeklemmt und konzentriere mich mal auf
ein Beispiel (Blinky) in der Onboard MCU des Discovery.
Christoph K. schrieb:> pin_state=0 ist ja eine Zuweisung innerhalb der Funktion (main.c).
Jein, es ist ein Initialwert, keine Zuweisung als solches. Ist die
Frage, ob der Compiler das explizit als Statement ausweist.
Irgendwelche Breakpoints in zu trivialen Code reinbauen zu wollen, geht
meistens schief, denn der Compiler erkennt die Trivialität und schmeißt
vieles weg.
Christoph K. schrieb:> pin_state=0 ist ja eine Zuweisung innerhalb der Funktion (main.c).
Ach so, das ist alles innerhalb von main.c. Sorry, da habe ich mich
verguckt. Also dann müsste Zumindest der Unterbrechungspunkt in Zeile 89
funktionieren.
Hast du denn den Debugger auch gestartet (klick auf den grünen Käfer)?
Sieht nicht danach aus.
Jörg W. schrieb:> Christoph K. schrieb:>> pin_state=0 ist ja eine Zuweisung innerhalb der Funktion (main.c).>> Jein, es ist ein Initialwert, keine Zuweisung als solches. Ist die> Frage, ob der Compiler das explizit als Statement ausweist.>
Man müßte sich das Kompilat mal angucken. Evtl. die Optimierung mal
abstellen? Manche Debugger oder IDEs sagen einem sogar, wenn ein
Breakpoint nicht erreicht werden kann, IIRC.
> Irgendwelche Breakpoints in zu trivialen Code reinbauen zu wollen, geht> meistens schief, denn der Compiler erkennt die Trivialität und schmeißt> vieles weg.
:)
Habe jetzt mal ein frisches DISCOVERY Board ausgepackt und
angeschlossen. Das IDE sagt sogar, daß es die ST-LINK-Version upgraden
muß. Mal sehn.
Christoph K. schrieb:> Evtl. die Optimierung mal abstellen?
Kannst du testhalber machen, dann sollten sich auf jeden Fall
Breakpoints setzen lassen. Würde ich aber an deiner Stelle nicht als
Dauerlösung nehmen, denn man debuggt dann völlig anderen
(Maschinen-)Code als den finalen, der ja optimiert werden soll.
Hier noch mal der letzte Stand. Nagelneues STM32F407G-DISC1 Board.
Firmware auf neuestem Stand. Mehrere BP gesetzt, aber keiner wird
getroffen.
Auch USB direkt angeschlossen (kein HUB). macOS 11.3.1
man kann auch vom ResetHandler an debuggen, ist ein Häkchen irgendwo in
der Launch Config.
Target Lost passiert wie genannt beim umkonfigurieren der SWD oder bei
Fehlern in der Clock Config.
Der Download ging allerdings auch verdächtig schnell, das sieht alles
nicht richtig konfiguriert aus. Oder das Projekt wurde nicht aus einem
für die MCU passenden Template erstellt.
Johannes S. schrieb:> man kann auch vom ResetHandler an debuggen, ist ein Häkchen irgendwo in> der Launch Config.> Target Lost passiert wie genannt beim umkonfigurieren der SWD oder bei> Fehlern in der Clock Config.>> Der Download ging allerdings auch verdächtig schnell, das sieht alles> nicht richtig konfiguriert aus. Oder das Projekt wurde nicht aus einem> für die MCU passenden Template erstellt.
Wie gesagt, das Programm (Blinky) läuft.
Ich glaube, es lag daran, daß ich die ganze Zeit auf den "normalen"
Run-Knopf gedrückt habe. Drücke ich auf den "Käfer"*, so klappt es. Das
muß einem ja mal jemand sagen (!). Im Visual Studio war ich gewohnt, auf
Run zu drücken und was an Breakpoints scharf war, wurde getroffen.
Jetzt kann ich auch meinen Assembler-File debuggen :)
*) Hätt' ich eigentlich wissen müssen, bin ich doch früher selbst Käfer
gefahren.
Christoph K. schrieb:> Drücke ich auf den "Käfer"*, so klappt es. Das> muß einem ja mal jemand sagen (!).Stefan ⛄ F. schrieb:> Hast du denn den Debugger auch gestartet (klick auf den grünen Käfer)?> Sieht nicht danach aus.
Stefan ⛄ F. schrieb:> Christoph K. schrieb:>> Drücke ich auf den "Käfer"*, so klappt es. Das>> muß einem ja mal jemand sagen (!).>> Stefan ⛄ F. schrieb:>> Hast du denn den Debugger auch gestartet (klick auf den grünen Käfer)?>> Sieht nicht danach aus.
Tut mir leid. Gerade diese Zeile hatte ich im Eifer des Gefechts
überlesen. So kann's gehen.
Thread beobachten
Seitenaufteilung abschalten