Brauche noch mal etwas Starthilfe. Bei OpenOCD erinnerte ich mich, daß
das Image, das man mit file und load angegeben hatte, automatisch
geflasht wurde.
Jetzt, mit dem (XTW) ST-LINK V2 Stick fehlt mir noch der Schritt zum
Flashen.
Ich kann folgendes bisher machen:
1
$ arm-none-eabi-gdb
2
GNU gdb (GNU Tools for Arm Embedded Processors 8-2018-q4-major) 8.2.50.20181213-git
3
Copyright (C) 2018 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-apple-darwin10 --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".
Probier's mal mit "monitor reset halt", danach "load". So funktioniert
das jedenfalls mit OpenOCD und dem Atmel-ICE.
Das "monitor"-Kommando im GDB schiebt die Argumente als Kommando an den
GDB-Server, also das "reset halt" wird von diesem ausgewertet.
Christoph K. schrieb:> (gdb) x/10 0> 0x0: Cannot access memory at address 0x0
Da is (im GDB) nix gemappt an Adresse 0. Flash startet im STM32 ab
Adresse 0x8000000.
Jim M. schrieb:> Christoph K. schrieb:>> (gdb) x/10 0>> 0x0: Cannot access memory at address 0x0>> Da is (im GDB) nix gemappt an Adresse 0. Flash startet im STM32 ab> Adresse 0x8000000.
Ja, danke. Das war nämlich noch das, was mich wunderte. Die Relocation
Adresse wird doch beim Laden (load) angegeben. Und was muß man im GDB
noch mappen? Als ich mit OpenOCD gearbeitet hatte, war das Problem nicht
da. Da gab ich nur den .elf file an. Arbeitet der mit BMP geflashte
(XTW) Stick auch als reiner ST-LINK mit OpenOCD? Der hat ja zwei
Devices:
crw-rw-rw- 1 root wheel 18, 9 5 Dez 07:41 /dev/cu.usbmodem7AAF76931
crw-rw-rw- 1 root wheel 18, 11 5 Dez 07:41 /dev/cu.usbmodem7AAF76933
Mein Fehler. Beim Makefile in der ld-Phase hatte ich noch einen Fehler
drin. kernel.ld file fehlte. Allerdings noch nicht ganz gelöst. Gibt
immer noch "load failed".
Wenn ich einen anderen .elf file nehme, der schon mal unter OpenOCD
funktioniert hat, dann kriege ich:
Habe gerade noch mal versucht, zurückzuschalten auf Dinge, die
funktioniert haben, aber jetzt auch nicht mehr funktionieren. Gut, es
war das DISCO, was funktioniert hat. Jetzt habe ich das Nucleo mit
seinem ST-LINK genommen und zunächst mal unter WIndows mit ST-Link
Utility das Nucleo geflasht mit einer Applikation. Die läuft über die
VCOM und ich kann interagieren mit
>Wieso funktioniert OpenOCD auf einmal nicht mehr?
Weil Du mit OOCD laut
>Info : Listening on port 4242 for gdb connections
über den Port 4242 sprechen sollst und nicht über
>Remote debugging using /dev/cu.usbmodem14203
Kann's leider nicht mehr löschen. Ich muß ja zum serverport verbinden.
Gut, also die Strecke funktioniert. Zurück zu BMP:
Bleibt also das Problem, daß das memory mapping im gdb im Falle
blackmagic nicht funktioniert.
Christoph K. schrieb:> Bleibt also das Problem, daß das memory mapping im gdb im Falle> blackmagic nicht funktioniert.
GDB kann dem GDB-Server ein memory mapping (in Form eines kleinen
XML-Snippets) rüberreichen. Könnte es sein, dass Blackmagic das nicht
unterstützt und dass die Probleme damit zusammen hängen?
Habe sowas vor Jahren für AVaRICE mal implementiert.
Ich stecke allerdings in deinem Projekt zu wenig drin, um dir fundiert
helfen zu können, bin halt nur kreuz und quer bei ähnlichen
Veranstaltungen schon mal lang gekommen.
ps: Irgendeine Doku, was ihre Firmware auf GDB-Server-Seite als
Protokoll unterstützt, finde ich bei denen leider nicht, und die
Firmware scheint auch nicht Opensource zu sein.
Christoph K. schrieb:> Bleibt also das Problem, daß das memory mapping im gdb im Falle> blackmagic nicht funktioniert.
GDB 6.8 and higher set any memory area not in the memory map as
inaccessible. This can be changed to the old behaviour by using the
following GDB command
set mem inaccessible-by-default off
Required Field schrieb:> set mem inaccessible-by-default off
Nur: warum will man das? Nicht zugreifbaren Speicher muss der GDB doch
auch nicht zugreifen können.
Achso, OK: falls der GDB-Server gar keine memory map liefert, kann es
natürlich sein, dass der GDB dann auch gar nichts zugreifen möchte …
Required Field schrieb:> Christoph K. schrieb:>> Bleibt also das Problem, daß das memory mapping im gdb im Falle>> blackmagic nicht funktioniert.>>>> GDB 6.8 and higher set any memory area not in the memory map as> inaccessible. This can be changed to the old behaviour by using the> following GDB command>> set mem inaccessible-by-default off
Danke. Das hat's jetzt erst mal gebracht, was den Memoryzugriff angeht.
Sollte man sich in die .gdbinit schreiben.
Habe noch Probleme mit BMP und GDB.
Mich wundert, wieso nach ein paar Steps durch das Programm der
Reset-Vektor überschrieben wird.
Nach einem load sieht es zunächst gut aus:
1
(gdb)load
2
Loadingsection.text,size0x3bdclma0x0
3
Startaddress0x3a6a,loadsize15324
4
Transferrate:130KB/sec,957bytes/write.
5
(gdb)x/10x0
6
0x0:0x200003300x00003a6b0x000038ab0x000038ab
7
0x10:0x000038ab0x000038ab0x000038ab0x00000000
8
0x20:0x000000000x00000000
Nach einigen Steps wird das Flash überschrieben (Programmspeicher):
Stelle übrigens fest, daß die gdb/BMP Kombination in eine Situation
kommen kann, aus der man nicht harauskommt, außer neu zu starten.
Wenn das Programm einen Segmentation Fault gemacht hat (SIGSEGV), kann
man es nicht mehr neu starten. Interrupt wirkt nicht.
Christoph K. schrieb:> Wenn das Programm einen Segmentation Fault gemacht hat (SIGSEGV)
Versteh' ich nicht ganz, welches Programm macht das SIGSEGV? Das auf
dem Controller? Das sollte ja dann eher einen hardfault bringen.
Jörg W. schrieb:> Christoph K. schrieb:>> Wenn das Programm einen Segmentation Fault gemacht hat (SIGSEGV)>> Versteh' ich nicht ganz, welches Programm macht das SIGSEGV? Das auf> dem Controller? Das sollte ja dann eher einen hardfault bringen.
Das unter gdb zu debuggende Programm. Das Target.
Naja, wie gesagt, das generiert normalerweise einen Hardfault, und der
übliche Hardfault-Handler ist eine Endlosschleife.
Aber dieses Blackmagic-Dingens scheint sich arg anders zu benehmen als
andere GDB-Server, habe ich den Eindruck.
Hat irgendjemand eine Bemerkung zu dem Vorschlag in
https://github.com/blacksphere/blackmagic/issues/267?
@ Jörg: BMP generiert das XML Teil fuer unterstuetzte Devices.
Ansonsten kann man inzwischen BMP auch auf dem PC kompilieren. Dann
flasht ein "blackmagic <bla.bin>" direkt von der Kommandozeile aus.
Bzgl "(gdb) x/10 0
0x0: Cannot access memory at address 0x0"
Das ist normales GDB Verhalten solange man nicht "set mem
inaccessible-by-default off" gesetzt hat.
Und Blackmagic PC kann auch mit STLINK, Jlink, FTDI und CMSIS_DAP
sprechen.
Und bei Problemberichten die Version des BMPs anzugeben, waere auch
nicht falsch.
Uwe Bonnes schrieb:> Hat irgendjemand eine Bemerkung zu dem Vorschlag in> https://github.com/blacksphere/blackmagic/issues/267?>> @ Jörg: BMP generiert das XML Teil fuer unterstuetzte Devices.>
Nur interessehalber: was für ein XML-Teil? Ist das eine Antwort auf eine
nicht gestellte Frage? :) Oder hab' ich was verpaßt?
Und noch eine Frage zum Verständnis:
Hier ein Auszug vom Start meiner gdb-Session:
Christoph K. schrieb:> Ist das eine Antwort auf eine nicht gestellte Frage?
Nein, es ist eine Antwort auf meine Vermutung, dass die Übermittlung des
Speicherlayouts möglicherweise nicht unterstützt sein könnte.
@Uwe: ist die Firmware eigentlich Opensource? Hatte nichts gefunden,
ansonsten hätte ich das selbst nachgesehen.
Wollte mal versuchen, binutils-gdb mit dem vorgeschlagenen Patch zu
kompilieren.
Auf
https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm
find ich auf der Mitte der Seite:
GDB
You can find the sources to Arm Embedded Binutils at
git://sourceware.org/git/binutils-gdb.git. All embedded branches are at
*users/ARM/embedded-gdb-[version]-branch*. You can contribute in the
same way that you contrinbute to GCC.
Weiß jemand, wo genau ich diese branches finde? Ich hatte mal ein git
clone gemacht, aber damit kommt nichts von users/ARM mit herunter.
Johannes S. schrieb:
...
> Das XML wird aber WIMRE nicht benutzt und bei der initialien Feature> Verhandlung negativ beantwortert, das wird für die komplexeren> Prozessoren wie X86/64 gebraucht.>>
Mach mal in gdb ein "info mem", da wird der xml String gebraucht.
Ausserdem mach gdn bei "load" etwas anders, je nachdem ob im Flash oder
Ram geschriebenwerden soll.
PS: In gdn fehlt das Gegenstueck zu "dump" um eine bin File wieder
zurueck auf das Device zu bringen.
Christoph K. schrieb:> Warum sagt gdb, daß das Programm schon gestartet sei?
Es fehlt das "att 1". Nach einem Kaltstart waere gar nichts gegangen,
bei Warmstart bleiben einige Register verbogen zurueck, so dass manches
ohne vorheriges Attach geht.
Uwe Bonnes schrieb:> Christoph K. schrieb:>>> Warum sagt gdb, daß das Programm schon gestartet sei?>> Es fehlt das "att 1". Nach einem Kaltstart waere gar nichts gegangen,> bei Warmstart bleiben einige Register verbogen zurueck, so dass manches> ohne vorheriges Attach geht.
Eigentlich habe ich es in .gdbinit:
Uwe Bonnes schrieb:> Fuer welche Hardware ist das Programm. Kannst Du mir das elf File oder> besser den Sourcebaum mit dem Elf File zukommen lassen? Vielleicht als> issue in https://github.com/blacksphere/blackmagic/issues oder dropbox?> Und/oder kannst Du den Vorschlag in> https://github.com/blacksphere/blackmagic/issues/267 testen?
Letzteres habe ich versucht bzw. bin dabei. Im Moment noch gcc Fehler
bei Kompilation. Hatte den Sourcetree auf gitlab ausgemacht.
Meine Target Source schicke ich heute abend. Bin im Moment auf Achse.
Uwe Bonnes schrieb:> Keine Eile, Und kein Versprechen meinerseits...
Hier ist das eingedampfte Projekt.
README:
make clean all
./GDB_bmp
1. Warum sagt gdb "A program is being debugged already"?
2. Warum stoppt das Target nicht auf dem gesetzten Breakpoint?
3. Warum sagt es bei r(un):
The program being debugged has been started already.
Start it from the beginning? (y or n) y
4. Warum sehe ich ab 0x400 nach meinem Programm nicht 0xfffffff
durchweg,
wenn ich vorher ein mon erase_mass gemacht habe. Irgendwo muß ich
doch sehen, daß der Flash gelöscht ist.
Auch hinter 0x08000000 sehe ich keine FFFF.
Grüße
Christoph
Anm.: aus Versehen ist der .gdbinit als .gdbinit.gz herübergekommen. Den
bitte noch entpacken.
Christoph K. schrieb:> 3. Warum sagt es bei r(un):>> The program being debugged has been started already.> Start it from the beginning? (y or n) y
Mit 'attach' hängt sich gdb an einen laufenden Prozess, da darf er also
annehmen das das Target schon läuft und die Frage beim run Befehl macht
Sinn.
Hier gibt es schon wenige die den Debugger nutzen und sicher noch viel
weniger die das über die Shell machen. Eine IDE nutzt den mi command
interpreter vom gdb und diese Fragen stellen sich gar nicht.
Das der Breakpoint nicht getroffen wird könnte daran liegen das der Code
wegoptimiert wurde und auf die entsprechende Sourcecodezeile kein BP
gesetzt werden kann (falls es um Sourcecode Debugging ging).
Johannes S. schrieb:> Christoph K. schrieb:>> 3. Warum sagt es bei r(un):>>>> The program being debugged has been started already.>> Start it from the beginning? (y or n) y>> Mit 'attach' hängt sich gdb an einen laufenden Prozess, da darf er also> annehmen das das Target schon läuft und die Frage beim run Befehl macht> Sinn.
Das Target ist ja noch nicht mal geladen zu diesem Zeitpunkt. Also meine
ich schon, daß diese GDB Kombination mit dem Server
diesen Zustand irgendwie berücksichten sollte. Aber gut, wie hieß es
hier letztens ja, einem geschenkten...
> Hier gibt es schon wenige die den Debugger nutzen und sicher noch viel> weniger die das über die Shell machen. Eine IDE nutzt den mi command> interpreter vom gdb und diese Fragen stellen sich gar nicht.> Das der Breakpoint nicht getroffen wird könnte daran liegen das der Code> wegoptimiert wurde und auf die entsprechende Sourcecodezeile kein BP> gesetzt werden kann (falls es um Sourcecode Debugging ging).
Ja, Assembler-Source code Debugging.
Wegoptimiert? Vom Programmierer selbst geschriebener Assemblersourcecode
wird nicht "wegoptimiert". Das wäre ja noch schöner :)
Nachtrag:
Habe jetzt folgende Vorgehensweise als "trittfest" festgestellt:
So scheint erst mal step-Betrieb möglich.
Wenn ich aber ein
r(un)
absetze, wird der Breakpoint nicht getroffen und das Programm macht ein
SIGSEGV, wonach dann nur noch Neustart des Targets und GDB möglich sind.
(gdb)
108 ands r0, #HSERDY
(gdb)
Merkwürdiges Problem mit gdb. Ich habe das Programm, das nicht läuft, in
das stm32-407-DIYMORE Board geflasht.
Ich steppe durch eine Programmpassage und untersuche immer, was im
Vektorbereich erscheint. Der sollte ja eigentlich nicht verändert
werden, da er ja im Flash liegt. Jetzt sieht es aber so aus, als
schreibe das Programm dorthin, obwohl es eigentlich nach 0x20000004
schreiben soll.
Große Verwunderung:
Eigentlich sollte ja die 0x188 nach [r0], also 0x20000004 geschrieben
werden. Es steht aber dann in 0x00000004 (!?).
Wie das? Denkfehler meinerseits? Fehler im GDB/BMP?
Ich brauche noch mal einen "reload", was flashen mit BMP angeht.
Hatte das Projekt einige Monate nicht angerührt und ich versuche jetzt,
zu rekonstruieren, was ich damals gemacht habe.
Mein Szenario ist momentan:
STM32F407-DISC1 board mit dem on board STLINK-V2 über USB-Kabel an Mac
angeschlossen. Der STLINK ist so gejumpert, daß er nicht mit der
Discovery MCU verbindet, also beide Jumper von CN3 off.
Target ist ein STM32F407 DIYMORE breakout board, das ich über die
SWD-Leitungen (SCLK, SWDIO, RESET - pins 2-4-6 am SWD Interface)
angeschlossen habe.
Wenn ich mich richtig erinnere, konnte man blackmagic als hosted server
kompilieren, so das es ein USB-serial device * zur Verfügung stellt,
über das GDB verbindet. War das richtig so? Und zuletzt funktionierte
etwas nicht mit dem blackmagic (build?). Da würde ich gerne wieder
aufsetzen.
*) Korrektur: nicht USB-Device, sondern einen tcp-port
Das kompilierte blackmagic macht leider nichts. Auch wenn ich die
Compiler-Fehler zu Warnungen umwidme, tut das blackmagic Binary nichts.
Es startet und macht leise weinend einen exit. Auch Verbositätserhöhung
führt zu nichts.
Es wird auch gemeckert, daß ein hidapi-libusb nicht im pkg-config PATH
gefunden wurde, was das Linken zwar nicht zu stören scheint, aber
letztlich zu dem unbrauchbaren Binary führt.
make PROBE_HOST=hosted clean; make PROBE_HOST=hosted HOSTED_BMP_ONLY=1
braucht weniger Bibliotheken. Und fuer hosted muss die BMP Firmware
einigermassen aktuell sein. Fuer BMP/Stlink muss man aber "make
PROBE_HOST=hosted" kompilieren. Auch die ST/Stlink-Firmware muss
aktuelle sein.
Christoph K. schrieb:> ...> Target ist ein STM32F407 DIYMORE breakout board, das ich über die> SWD-Leitungen (SCLK, SWDIO, RESET - pins 2-4-6 am SWD Interface)> angeschlossen habe.>>> ...>
Ist das eigentlich richtig? 2-4-6? Oder muß das nicht 2-4-5 sein ?
Thread beobachten
Seitenaufteilung abschalten