Hallo,
ich versuche mit ST-Link V2 und GDB unter CodeBlocks zu debuggen.
Es gibt keine Fehler - aber es passiert auch nichts.
Hier die Anzeige in CodeBlocks:
Debugger name and version: GNU gdb (GNU Tools for STM32 9-2020-q2-update.20201001-1621) 8.3.1.20191211-git
Vielleicht ist mein Denkfehler aber auch, dass der GDB ein ganz normaler
Debugger ist wie Lauterbach oder AVR-Studio
Gruß Matthias
(Edit: pre-Tags eingefügt - Mod.)
Matthias schrieb:> at Johannes: Den Server habe ich vorher über eine Batch gestartet.
Zur Inetriebnahem startet man sowas erstmal über eine Console. So hat
man nämlich die Chance, eventuell hilfreiche Fehlermeldungen auch
mitzubekommen.
Matthias schrieb:> at c-hater: Die Meldungen des ST-Link Servers findest Du im angefügten> rtf-Dokument.
Ich bin doch nicht bescheuert und öffne ein *.rtf aus unbekannter
Quelle.
Mach' das draus, was auch alle anderen Leute für Logs verwenden. Eine
Textdatei.
na ja, viele machen auch gerne ein unleserliches Foto vom Bildschirm.
Im UM2576 und im UM2237 ist das (fast) alles beschreiben. Ausser
vielleicht das diese Kombi den Hardware Reset haben, was ich hier ja
auch vor kurzem gefragt hatte.
c-hater schrieb:> Ich bin doch nicht bescheuert und öffne ein *.rtf aus unbekannter> Quelle.
Im Gegensatz zu einem .docx dürfte ein RTF vergleichsweise sicher sein,
da es keine Makros transportieren kann.
In diesem konkreten Fall enthält es eh nur ein einzelnes Bild,
vermutlich also ein Screenshot. Aber das ist natürlich an sich schon mal
sinnlos: dann hätte man das Bild auch gleich direkt posten können. Viel
sinnvoller wäre stattdessen jedoch ein Text-Mitschnitt per copy & paste.
Auch dafür wiederum startet man sowas erstmal außerhalb der IDE in einem
normalen Terminal, in dem copy & paste einfach zu bewerkstelligen ist.
(Außerdem crasht LibreOffice beim Versuch, das Ding zu öffnen, ich sehe
also keinen Inhalt.)
Ich kann die RTF Datei ohne Probleme öffnen. Mit LibreOffice 7.0.4.2
unter Debian Linux mit Gnome 3. Ich habe das Bild mal angehängt.
paradoxerweise ist es jetzt nur noch 1/40 so groß.
Warum halten sich immer mehr Leute für Softwareentwickler, die nicht
einmal ihren eigenen Computer bedienen können?
Stefan ⛄ F. schrieb:> Ich kann die RTF Datei ohne Probleme öffnen.
Ändert nichts dran, dass man das hätte besser als Text copy & pasten
sollen.
Außerdem sagt es auch bloß, dass der Debugger sich nicht verbindet.
Also: GDB extern (in zweitem Kommandofenster) starten, und dann ein
1
targ rem :61235
ausführen. Kein .gdbinit oder dergleichen abarbeiten.
Keine Ahnung, was für'n GDBserver das ist … ich würde hier eher zu
OpenOCD tendieren.
Stefan ⛄ F. schrieb:> Ich kann die RTF Datei ohne Probleme öffnen.
Schön. Nun kann man sogar lesen, dass da sogar ein Textfile fix und
fertig zum Upload erzeugt wurde...
Was den sonstigen Inhalt des Screenshots betrifft: Dat Dingens läuft.
Man braucht sich bloß noch verbinden.
Stefan ⛄ F. schrieb:> Jörg W. schrieb:>> Keine Ahnung, was für'n GDBserver das ist>> Steht in der Titelzeile des Fensters (im Screenshot).
OK.
Ist der irgendwie besser als OpenOCD? Oder warum haben die das Fahrrad
nochmal erfunden?
Jörg W. schrieb:> Ist der irgendwie besser als OpenOCD? Oder warum haben die das Fahrrad> nochmal erfunden?
Es wird schon irgendwas was da sein, was besser ist. OpenOCD ist ja nun
nicht gerade das Gelbe vom Ei. Die typische Eierlegende Wollmilchsau,
kann alles, aber nix wirklich gut oder gar schnell.
Jörg W. schrieb:> Ist der irgendwie besser als OpenOCD? Oder warum haben die das Fahrrad> nochmal erfunden?
Mit dem ST-Link GDB kann die STM32 Cube IDE Trace SWO Meldungen
innerhalb der IDE anzeigen.
Mit OpenOCD muss man sie hingegen in eine Datei schreiben die man sich
dann außerhalb der IDE anschaut. Zudem hat die IDE für diese Variante
keinen Button zum anklicken, dass muss man manuell konfigurieren.
Sonst sind mir keine Unterschiede aufgefallen.
Matthias schrieb:> Was muss ich tun, um mich zu verbinden.
Habe ich oben geschrieben: "target remote :61235" am GDB-Prompt
eingeben.
Erstmal das, und manuell gucken, ob der GDB mit allem zurecht kommt.
Erst, wenn das geht, sich um die IDE-Integration Gedanken machen (die
dann wohl auf ein .gdbinit-Script hinaus läuft).
Stefan ⛄ F. schrieb:> Mit dem ST-Link GDB kann die STM32 Cube IDE Trace SWO Meldungen> innerhalb der IDE anzeigen.
OK, dafür ist vermutlich dann der zweite TCP-Port da, der da angegeben
ist.
Habe ich noch nie benutzt, wir haben entweder eine UART (oft auch mit 1
MBaud) benutzt (die dann auch abseits des Debuggers nutzbar ist), oder
wenn es schnell gehen muss, dann mit GPIOs hantiert, die man auf einem
LA darstellt.
Mit dem Port 61234 bekomme ich eine Verbindung, aber irgendwo klemmts
noch.
Continuing...
In ()
Cannot find bounds of current function
Cannot find bounds of current function
Continuing...
Trying to interrupt process with pid: 28028; child pid: 0 gdb pid: 30212
Continuing...
Trying to interrupt process with pid: 28028; child pid: 0 gdb pid: 30212
Trying to interrupt process with pid: 28028; child pid: 0 gdb pid: 30212
Continuing...
Trying to interrupt process with pid: 28028; child pid: 0 gdb pid: 30212
Continuing...
Trying to interrupt process with pid: 28028; child pid: 0 gdb pid: 30212
Trying to interrupt process with pid: 28028; child pid: 0 gdb pid: 30212
Trying to interrupt process with pid: 28028; child pid: 0 gdb pid: 30212
Trying to interrupt process with pid: 28028; child pid: 0 gdb pid: 30212
Matthias schrieb:> Das System hat versucht, einem Verzeichnis, das sich auf einem> mit JOIN zugeordneten Laufwerk befindet, ein Laufwerk mit SUBST> zuzuordnen.
Versuche mal, auf Netzlaufwerke zu verzichten. Mache alles nur in
lokalen Verzeichnissen auf deiner eigenen Festplatte bzw SSD.
Matthias schrieb:> ich versuche mit ST-Link V2 und GDB unter CodeBlocks zu debuggen.
Beim Raspi mit Codeblocks hab ich das so gemacht:
eine Debugger Konfiguration mit:
executable: /usr/bin/arm-none-eabi-gdb
initialization: target extended-remote localhost:3333
monitor reset halt
mit stlink oder über die Massenspeicherschnittstelle der
Nucleo/Discovery boards lade ich das zu debuggende Programm.
in einem extra Fenster starte ich openocd mit der Boardkonfiguration
z.b. : openocd -f board/stm32f469discovery.cfg
und debugge fröhlich vor mich hin
mfG Dieter
Hallo Stefan,
mit dem Port 61234 scheint sich einiges zu tun.
Bezüglich Codeblocksintegration bin ich nach diesem Artikel[STM32F4 mit
Code::Blocks] vorgegangen. Mit den Debug-Kommandos aus Codeblocks
passiert auch irgendetwas, siehe letzter Post. In dem Artikel hieß es,
dass mit dem Start des Debuggers das elf-file geflasht wird. Aber das
passiert nicht. Scheinbar gab es seit diesem Artikel eine Evolution in
den verwendeten Tools.
wie wird denn der gdb-server gestartet? Ich doch schon das Beispiel von
VSC genannt, es muss der STLink-gdbserver mit -cp cubeprogrammer --swd
gestartet werden.
STMicroelectronics ST-LINK GDB server. Version 5.8.0
4
Copyright (c) 2020, STMicroelectronics. All rights reserved.
5
6
Starting server with the following options:
7
Persistent Mode : Disabled
8
Logging Level : 31
9
Listen Port Number : 50000
10
Status Refresh Delay : 15s
11
Verbose Mode : Disabled
12
SWD Debug : Enabled
13
14
Target connection mode: Default
15
Reading ROM table for AP 0 @0xe00fffd0
16
Hardware watchpoint supported by the target
17
COM frequency = 24000 kHz
18
ST-LINK Firmware version : V3J7M2
19
Device ID: 0x413
20
PC: 0x80045a0
21
ST-LINK device status: HALT_MODE
22
ST-LINK detects target voltage = 3.22 V
23
ST-LINK device status: HALT_MODE
24
ST-LINK device initialization OK
25
Waiting for debugger connection...
26
Waiting for connection on port 50000...
27
28
--- nach dem Verbinden von arm-none-eabe-gdb:
29
Accepted connection on port 50000...
30
Debugger connected
31
Enter STM32_AppReset() function
32
NVIC_DFSR_REG = 0x00000008
33
NVIC_CFGFSR_REG = 0x00000000
und in einem anderen den arm-none-abi-gdb mit
1
arm-none-eabi-gdb
2
GNU gdb (GNU Tools for STM32 9-2020-q2-update.20201001-1621) 8.3.1.20191211-git
3
Copyright (C) 2019 Free Software Foundation, Inc.
4
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
5
This is free software: you are free to change and redistribute it.
6
There is NO WARRANTY, to the extent permitted by law.
7
Type "show copying" and "show warranty" for details.
8
This GDB was configured as "--host=x86_64-w64-mingw32 --target=arm-none-eabi".
9
Type "show configuration" for configuration details.
10
For bug reporting instructions, please see:
11
<http://www.gnu.org/software/gdb/bugs/>.
12
Find the GDB manual and other documentation resources online at:
13
<http://www.gnu.org/software/gdb/documentation/>.
14
15
For help, type "help".
16
Type "apropos word" to search for commands related to "word".
17
(gdb) tar rem localhost:50000
18
Remote debugging using localhost:50000
19
warning: No executable has been specified and target does not support
20
determining executable automatically. Try using the "file" command.
21
0x080045a0 in ?? ()
22
(gdb) mon reset
23
STM32 Successfully completed reset operation
24
(gdb)
der gdb wird so gestartet für Kommandozeilenbedienung. Wenn eine IDE den
bedient, dann wird üblicherweise ein anderes Protokoll verwendet
und ein
1
"-q" "--interpreter=mi2"
angehängt.
Wenn der STLink Prozess sich beendet, dann bekomme ich auch die falsche
Fehlermeldung
1
(gdb) tar ext localhost:50000
2
localhost:50000: Das System hat versucht, einem Verzeichnis, das sich auf einem mit JOIN zugeordneten Laufwerk befindet, ein Laufwerk mit SUBST zuzuordnen.
edit:
habe die langen Pfade mal rausgenommen damit es etwas leserlicher wird.
Müsste bei dir entsprechend nach dem Start von arm-none-eabi-gdb mit
1
tar rem localhost:61234
verbinden.
noch ein Nachtrag:
es gibt 'target remote ip:port' und 'target extended remote //./COMx',
letzteres z.B. über einen seriellen port oder USB. Wenn der gdbserver
das nicht erwartet, dann kann der sich wie in meinem Beispiel
verabschieden.
Matthias schrieb:> PARSE ERROR: Argument: --interpreter=mi2> Couldn't find match for argument> Brief USAGE:> ST-LINK_gdbserver.exe
Das Argument gehört an den GDB, nicht an den GDB-Server.
Matthias schrieb:> Mit diesem Argument verbindet sich der debugger nicht mehr mit dem> Server.
Lass dir doch bitte nicht alles aus der Nase ziehen: was genau tut er,
was passiert, welche Fehlermeldungen gibt es?
(Bitte füge mal [ pre ] ... [ /pre ] Tags bei deinen
Terminalmitschriften ein, die Leerzeichen dabei weglassen.)
Nun, du hast da glaub' ich immer noch einen Automatismus, und alles wird
in einem Terminalfenster verwurschtelt.
Starte doch den Kram mal getrennt: ein Fenster den GDB-Server mit seinen
Ausschriften, in einem anderen Fenster den GDB - ohne irgendein
.gdbinit.
Ich habe keinen STlink hier, daher mal am Beispiel von OpenOCD:
1
$ openocd -f .openocd/samd20.cfg
2
Open On-Chip Debugger 0.11.0+dev-00294-g3d9534b8a (2021-08-02-22:38)
3
Licensed under GNU GPL v2
4
For bug reports, read
5
http://openocd.org/doc/doxygen/bugs.html
6
DEPRECATED! use 'adapter speed' not 'adapter_khz'
7
Warn : Interface already configured, ignoring
8
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
9
Info : Listening on port 6666 for tcl connections
10
Info : Listening on port 4444 for telnet connections
~"License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law."
6
~"\nType \"show copying\" and \"show warranty\" for details.\n"
7
~"This GDB was configured as \"--host=x86_64-unknown-freebsd12.2 --target=arm-none-eabi\".\n"
8
~"Type \"show configuration\" for configuration details.\n"
9
~"For bug reporting instructions, please see:\n"
10
~"<https://www.gnu.org/software/gdb/bugs/>.\n"
11
~"Find the GDB manual and other documentation resources online at:\n <http://www.gnu.org/software/gdb/documentation/>."
12
~"\n\n"
13
~"For help, type \"help\".\n"
14
~"Type \"apropos word\" to search for commands related to \"word\".\n"
15
(gdb)
16
targ rem :3333
17
&"targ rem :3333\n"
18
~"Remote debugging using :3333\n"
19
=thread-group-started,id="i1",pid="42000"
20
&"warning: No executable has been specified and target does not support\ndetermining executable automatically. Try using the \"file\" command."
Der sieht halt mit diesem --interpreter=mi2 bissel seltsam aus, aber es
funktionieren trotzdem noch ganz normale GDB-Eingaben.
Ohne --interpreter=mi2 sieht er "normaler" aus:
1
$ arm-none-eabi-gdb
2
GNU gdb (GDB) 10.2
3
Copyright (C) 2021 Free Software Foundation, Inc.
4
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
5
This is free software: you are free to change and redistribute it.
6
There is NO WARRANTY, to the extent permitted by law.
7
Type "show copying" and "show warranty" for details.
8
This GDB was configured as "--host=x86_64-unknown-freebsd12.2 --target=arm-none-eabi".
9
Type "show configuration" for configuration details.
10
For bug reporting instructions, please see:
11
<https://www.gnu.org/software/gdb/bugs/>.
12
Find the GDB manual and other documentation resources online at:
13
<http://www.gnu.org/software/gdb/documentation/>.
14
15
For help, type "help".
16
Type "apropos word" to search for commands related to "word".
17
(gdb) target remote :3333
18
Remote debugging using :3333
19
warning: No executable has been specified and target does not support
20
determining executable automatically. Try using the "file" command.
21
0x000000a4 in ?? ()
22
(gdb) disp /i $pc
23
1: x/i $pc
24
=> 0xa4: b.n 0xa4
25
(gdb) si
26
0x000000a4 in ?? ()
27
1: x/i $pc
28
=> 0xa4: b.n 0xa4
29
(gdb)
30
0x000000a4 in ?? ()
31
1: x/i $pc
32
=> 0xa4: b.n 0xa4
33
(gdb)
34
0x000000a4 in ?? ()
35
1: x/i $pc
36
=> 0xa4: b.n 0xa4
37
(gdb)
38
0x000000a4 in ?? ()
39
1: x/i $pc
40
=> 0xa4: b.n 0xa4
41
(gdb)
42
0x000000a4 in ?? ()
43
1: x/i $pc
44
=> 0xa4: b.n 0xa4
45
(gdb)
46
0x000000a4 in ?? ()
47
1: x/i $pc
48
=> 0xa4: b.n 0xa4
49
(gdb) mon reset halt
50
SWD DPIDR 0x0bc11477
51
target halted due to debug-request, current mode: Thread
52
xPSR: 0x21000000 pc: 0x00000a5e msp: 0x20002038
53
(gdb) si
54
0x00000a60 in ?? ()
55
1: x/i $pc
56
=> 0xa60: cmp r3, #0
57
(gdb)
58
0x00000a62 in ?? ()
59
1: x/i $pc
60
=> 0xa62: bne.n 0xa5e
61
(gdb)
62
0x00000a5e in ?? ()
63
1: x/i $pc
64
=> 0xa5e: subs r3, #1
65
(gdb)
66
0x00000a60 in ?? ()
67
1: x/i $pc
68
=> 0xa60: cmp r3, #0
69
(gdb) c
70
Continuing.
71
^C
72
Program received signal SIGINT, Interrupt.
73
0x000000a4 in ?? ()
74
1: x/i $pc
75
=> 0xa4: b.n 0xa4
76
(gdb) det
77
Detaching from program: , Remote target
78
Ending remote debugging.
79
[Inferior 1 (Remote target) detached]
80
(gdb) quit
Funktionieren muss aber beides, und das mi2-Interface ist halt dafür
konzipiert, dass man damit den GDB besser woanders einbetten kann.
Nachdem das alles nicht fruchtbar war, bin ich jetzt leider Gottes doch
wieder auf die STM32 Cube IDE umgestiegen.
Jetzt stellt sich mir die Frage, wie ich in eine Library hineindebuggen
kann.
Ich hab zwar die Sourcen, bekomme aber der IDE nicht beigebracht, wo sie
suchen soll. Selbst wenn die Sourcen im Projekt liegen und nur vom Build
ausgeschlossen sind (ich ziehe ja die Library an) werden sie beim
debuggen nicht gefunden und bekomme nur die Assembleransicht.
Thread beobachten
Seitenaufteilung abschalten