Error! Failed to read target status

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.

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.

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

      -------------------------------------------------------------------

16

                        STM32CubeProgrammer v2.7.0-RC1                  

17

      -------------------------------------------------------------------

18

19

ST-LINK SN  : 066CFF485153826687123124

20

ST-LINK FW  : V2J37M27

21

Board       : STM32F4DISCOVERY

22

Voltage     : 2.90V

23

SWD freq    : 4000 KHz

24

Connect mode: Under Reset

25

Reset mode  : Hardware reset

26

Device ID   : 0x413

27

Revision ID : Rev 2.0

28

Device name : STM32F405xx/F407xx/F415xx/F417xx

29

Flash size  : 1 MBytes (default)

30

Device type : MCU

31

Device CPU  : Cortex-M4

32

33

34

35

Memory Programming ...

36

Opening and parsing file: ST-LINK_GDB_server_uvX5JZ.srec

37

  File          : ST-LINK_GDB_server_uvX5JZ.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.393

49

50

51

52

Verifying ...

53

54

55

56

57

Download verified successfully 

58

59

60

Debugger connection lost.

61

Shutting down...

Habe im main.c einen Breakpoint gesetzt, aber nichts passiert.

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

1

__asm volatile("nop"::);

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.

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

> int main()

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.

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

"Debugger connection lost" ?

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.

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.