Zum ARM debuggen habe ich einen STLink Clone zur Black Magic Probe
umprogrammiert und das funktioniert auch. Die Einstellung war etwas
fummelig, es funktioniert jetzt so wie in dem angehängten Dialog für
'GDB Hardware Debugging' eingestellt.
Dabei stört mich nur eine kleine Sache: nach dem Start der debug session
wird das target angehalten und steht an einer zufälligen Stelle. Beim
debuggen über OpenOCD wird das Programm von Reset bis zum ersten
Breakpoint 'main' ausgeführt. Mit der BMP muss ich immer zuerst den
'restart' Button in der IDE drücken damit der Code von Reset an
gestartet wird. Das dürften ja nur gdb Kommandos in dem 'Run Commands'
Feld sein, aber ich habe noch nicht gefunden welche. ein 'run' oder
'jump *0 run' funktionieren nicht. Die Kommunikation IDE-gdb läuft auch
versteckt, ich sehe jedenfalls nicht was beim 'restart' button ausgelöst
wird. Wie bekomme ich den gdb dazu den reset auszuführen?
die dürfen nicht gesetzt sein weil die Verbindung dann noch nicht steht.
Im Anhang ist noch der andere Config Tab für den Debugger. Die anderen
Startmöglichkeiten die es da gibt funktionieren aber auch nicht, BMP
möchte über das target-extended verbunden werden.
Program received signal SIGSEGV, Segmentation fault.
9
0x00800000 in ?? ()
10
(gdb) jump *0x8000000
11
Continuing at 0x8000000.
12
13
Program received signal SIGSEGV, Segmentation fault.
14
0x41000000 in ?? ()
15
(gdb)
Ein Jump auf eine Startadresse kann aber auch nicht richtig sein,
irgendwie muss der Debugger ja einen richtigen reset auslösen.
Mit 'monitor connect_srst enable' hängt der gdb nach dem attach, das
geht auch nicht.
pegel schrieb:> Vielleicht bietet das die Lösung.
Das sind openOCD spezifische Kommandos, die reicht der gdb ja nur
weiter. Trotzdem schonmal Danke für die Hilfe.
stimmt, soweit habe ich da nicht runtergescrollt.
Habe das Zauberwort jetz aber gefunden: flushregs. Also in dem dem 'Run
Commands' Fenster:
1
flushregs
2
run
ja, Eclipse/OOCD/BMP/gdb ist ein riesiges Puzzle, jeden Tag ein kleines
Stückchen weiter :-)
So klappt es scheinbar, und BMP ist auch sehr fix.
Irgendwo müsste es in Eclipse auch zu sehen sein wie mit dem gdb
gesprochen wird, aber das habe ich noch gefunden. Flushregs hatte ich
hier gefunden: https://www.eclipse.org/forums/index.php/t/202861/
Uwe B. schrieb:> Probier doch erst mal das ganze im Terminal.
hatte ich gemacht, daher kamen die obigen Ausgaben.
Im Anhang nochmal der Dialog mit den hoffentlich richtigen
Einstellungen.
Jetzt bleibt nur noch das Mysterium mit dem 'connect_srst'. Einen Reset
sehe ich auf der sRST Leitung, die Hardware sollte bedient werden. Ein
'kill' zum Debugger beenden löst auch einen Reset aus wie es
dokumentiert ist.
GNU gdb (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 8.0.50.20171128-git
4
Copyright (C) 2017 Free Software Foundation, Inc.
5
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
6
This is free software: you are free to change and redistribute it.
7
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
8
and "show warranty" for details.
9
This GDB was configured as "--host=i686-w64-mingw32 --target=arm-none-eabi".
10
Type "show configuration" for configuration details.
11
For bug reporting instructions, please see:
12
<http://www.gnu.org/software/gdb/bugs/>.
13
Find the GDB manual and other documentation resources online at:
14
<http://www.gnu.org/software/gdb/documentation/>.
15
For help, type "help".
16
Type "apropos word" to search for commands related to "word".
17
(gdb) tar ext \\.\COM17
18
Remote debugging using \\.\COM17
19
(gdb) mon swd
20
Target voltage: unknown
21
Available Targets:
22
No. Att Driver
23
1 STM32F40x
24
(gdb) att 1
25
Attaching to Remote target
26
warning: No executable has been specified and target does not support
27
determining executable automatically. Try using the "file" command.
28
0x08007fba in ?? ()
29
(gdb)
Nach dem Attach steht der Debugger irgendwo im angehaltenen programm.
Ich habe gerade mal versucht herauszubekommen was OOCD beim reset-init
macht, habe das aber nicht gefunden.
Starte am besten gdb mit dem <xxx>.elf file oder lade das File in dem
Zustand oben mit "file <xxx>.elf. Dann ein "r" fuer reboot oder "s" fuer
step oder "n" fuer next.
'r' ist run, in der Eclipse Debuggerconfig reicht das eben nicht. In der
Kommandozeile geht es, also scheint es ein eclipse Problemchen zu sein.
Das ist reproduzierbar, ohne 'flushregs' geht es in eclipse nicht. Oder
das 'run' wird da nicht richtig ausgeführt. In der Kommandozeile muss
ich das run mit y bestätigen.
1
(gdb) tar ext \\.\COM17
2
Remote debugging using \\.\COM17
3
(gdb) mon swd
4
Target voltage: unknown
5
Available Targets:
6
No. Att Driver
7
1 STM32F40x
8
(gdb) att 1
9
Attaching to Remote target
10
warning: No executable has been specified and target does not support
11
determining executable automatically. Try using the "file" command.
12
0x080005e8 in ?? ()
13
(gdb) file mbed-os-example-blinky_STM32F407VE.elf
14
A program is being debugged already.
15
Are you sure you want to change the file? (y or n) y
16
Reading symbols from mbed-os-example-blinky_STM32F407VE.elf...done.
17
(gdb) b main
18
Breakpoint 1 at 0x800e050: file ../main.cpp, line 59.
19
(gdb) run
20
The program being debugged has been started already.
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang