Bin mir immer noch nicht sicher, unter welchem OS und welcher Plattform
ich das STM32F4 Projekt entwickeln bzw. debuggen soll, je mehr ich
lese.
Angefangen hatte ich, als ich mit 2 kleinen Zeilen im macOS Terminal
das Nucleo F411RE mit mecrisp-forth flashen konnte und es war ein
totales Erfolgserlebnis. Das war, als ich bereits versucht hatte, die
GNU MCU32 CDT unter Eclipse (macOS) zu installieren, aber irgendwie hing
ich am QEMU und xPack fest.
Hatte dann STMCube und STM32-STLINK-Utility probiert. Jetzt suche ich
nach den Pendants zu st-flash unter Windows. Gibt's das 1:1 ?
Dann lese ich noch, daß das discovery Board auch ohne IC-debugger
STLINK/V2 direkt, also ohne Hardware (SWD) unterstützt. Und das könne
auch über OpenOCD geschehen. Man könne sogar den gdb mit dem OOCD server
(target:3333) verbinden.
Eigentlich bevorzuge ich vi und command-line tools, wobei ich dies im
Moment lieber unter Windows 10 hätte, weil das Bedienprogramm des
Projekts auch unter Windows läuft.
Eure Meinung/Hilfe sehr willkommen.
Grüße
Christoph
Ich würde einfach den STM32Workbench und einen richtigen externen
ST_Link v2 oder v3Mini nehmen.
Damit bist du fertig und kannst in Zukunft auf allen STM32 entwickeln ob
nackt oder auf nem Eval Board.
Mbed ist Multi Kulti, entwickeln gebt mit dem mbed-cli am Besten und das
läuft unter Linux/Mac/Windows. Installieren ist unter Windows am
einfachsten, da gibt es einen Installer, Mac weiss ich nicht, Linux sind
ein paar manuelle Schritte die man nach der Anleitung auch hinbekommt.
https://os.mbed.com/docs/mbed-os/v6.2/quick-start/build-with-mbed-cli.html
Dann das Blinky von Github klonen:
https://github.com/ARMmbed/mbed-os-example-blinky
da die Schritte 1,2,3 befolgen.
Kompilieren mit 'mbed compile -t GCC_ARM -m NUCLEO_F411RE' oder noch mit
Schalter '-f' dahinter, dann sollte direkt geflasht werden (wenn der
STLink auf dem Board aktuell ist).
Als schlanke IDE geht VSCode gut, da kann man das compile Kommando als
Task einbauen. Mit Cortex-Debug Extension lässt sich auch debuggen.
Ein Mbed-Studio gibt es mittlerweile auch, ich weiss aber nicht ob das
mittlerweile auf dem Mac läuft.
Christoph K. schrieb:> Jetzt suche ich> nach den Pendants zu st-flash unter Windows. Gibt's das 1:1 ?
1:1 eher nicht. Aber beide Windows ST-Flasher (ST-Link Utility und
STM32CubeProgrammer) sollten ein CLI haben.
Ich verwende OpenOCD unter macOS, Ubuntu und Windows, sowohl zum Flashen
als auch zum Debuggen (mit GDB). Unter anderem auch mit einem Nucleo
F411RE.
OpenOCD funktioniert in meinem Fall zweistufig:
1. Starten des Servers:
echo program firmware.elf verify reset | nc localhost 4444
Punkt (2) braucht halt eine Pipe-fähige Shell.
Das Flashen lässt sich bei Bedarf aber auch in eine Zeile packen; dabei
wird dann kein Server-Prozess gestartet.
Philip S. schrieb:> OpenOCD funktioniert in meinem Fall zweistufig:
Wenn man nur flashen will, kann man das auch in ein einziges cfg-Script
packen. Das ist nützlich, um es dem Projekt beizulegen.
Philip S. schrieb:
> OpenOCD funktioniert in meinem Fall zweistufig:
Blackmagic kann man inzwischen auch fuer den PC kompilieren und auf BMP
Firmware Probes, Stlink V2 und V3, Libftdi/MPSSE Adaptern und CMSIS DAP
Adaptern laufen lassen. "blackmagic <file.bin>" flasht dann an den Start
des Flashbereich und kennt weitere Parameter. Ohne Argumente
"blackmagic" wird auf Port 2000 der GDB Server gestartet. Jlink geht im
Prinzip auf, nur schnarchlagsam...
Philip S. schrieb:> Ich verwende OpenOCD unter macOS, Ubuntu und Windows, sowohl zum Flashen> als auch zum Debuggen (mit GDB). Unter anderem auch mit einem Nucleo> F411RE.>> OpenOCD funktioniert in meinem Fall zweistufig:>> 1. Starten des Servers:>
>
Danke. Versuch's gerade unter macOS im Terminal.
Der Server scheint nicht zu starten, gibt aber auch keine Fehlermeldung:
$ pwd
/Users/kuku/opt/xpack-openocd-0.10.0-14
$ sudo bin/openocd -f scripts/board/stm32f4discovery.cfg -c "gdb_port
4242" -c "telnet_port 4444"
Password:
xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev-00378-ge5be992df
(2020-06-26-12:31)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The
results might differ compared to plain JTAG/SWD
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 2000 kHz
$ lsof -i :4444
$ lsof -i :4242
$
Christoph K. schrieb:>> Danke. Versuch's gerade unter macOS im Terminal.> Der Server scheint nicht zu starten, gibt aber auch keine Fehlermeldung:>> $ pwd> /Users/kuku/opt/xpack-openocd-0.10.0-14> $ sudo bin/openocd -f scripts/board/stm32f4discovery.cfg -c "gdb_port> 4242" -c "telnet_port 4444"> Password:
Mmmh.
"Bei mir tut's". ;-)
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
7
adapter speed: 2000 kHz
8
adapter_nsrst_delay: 100
9
none separate
10
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
11
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
12
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
13
Info : clock speed 1800 kHz
14
Info : STLINK v2 JTAG v37 API v2 SWIM v0 VID 0x0483 PID 0x3748
15
Info : using stlink api v2
16
Info : Target voltage: 2.869321
17
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Unterschiede, die ich sehe:
- Ich hab' OpenOCD mittels HomeBrew installiert.
- Ich starte OpenOCD ohne sudo -- hat bei mir aber auch mit sudo
funktioniert.
Ich hab's eben auch mit einem STM32F4 Discovery probiert. Wenn ich
stattdessen die selbe .cfg Datei, aber ein anderes phys. Board (Nucleo
STM32F411RE) verwende, dann steigt OpenOCD mit einem Fehler aus.
Danke. Es gilt mal wieder die alte Regel: "Einschalten erhöht die
Empfindlichkeit" :)
Hatte das Board nicht unter Spannung/angeschlossen.
bin/openocd -f scripts/board/stm32f4discovery.cfg -c "gdb_port 4242" -c
"telnet_port 4444"
xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev-00378-ge5be992df
(2020-06-26-12:31)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The
results might differ compared to plain JTAG/SWD
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 2000 kHz
Info : STLINK V2J37M26 (API v2) VID:PID 0483:3752
Info : Target voltage: 2.892781
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for stm32f4x.cpu on 4242
Info : Listening on port 4242 for gdb connections
und wartet ...
Gut, kann man wahrscheinlich auch in den Hintergrund schieben
So, jetzt muß ich erst mal lesen, wie man gdb mit openocd benutzt.
Muß wahrscheinlich .elf Images nehmen.
Christoph K. schrieb:> So, jetzt muß ich erst mal lesen, wie man gdb mit openocd benutzt.>> Muß wahrscheinlich .elf Images nehmen.
Ich hab’ das hier in meiner .gdbinit stehen:
Philip S. schrieb:> Christoph K. schrieb:>> So, jetzt muß ich erst mal lesen, wie man gdb mit openocd benutzt.>>>> Muß wahrscheinlich .elf Images nehmen.>> Ich hab’ das hier in meiner .gdbinit stehen:>>
1
> file firmware.elf
2
> target remote localhost:4242
3
> load firmware.elf
4
>
Danke. Es scheint zu funktionieren. Zumindest erscheint keine
Fehlermeldung. Aber ich bekomme irgendwie noch kein Zeichen vom
Programm, wenn ich "continue" eingebe. Es sollte etwas auf USART3
schreiben.
Die virtuelle COM und das Debug-Interface stehen sich ja nicht im Wege?
Das ist der openOCD-Aufruf:
Christoph K. schrieb:> Die virtuelle COM und das Debug-Interface stehen sich ja nicht im Wege?>
Nein, die sollten sich nicht ausschließen.
> Das ist der openOCD-Aufruf:>> [code]/Users/kuku/opt/xpack-openocd-0.10.0-14/bin/openocd -f> /Users/kuku/opt/xpack-openocd-0.10.0-14/scripts/board/st_nucleo_f4.cfg> -c "gdb_port 4242" -c "telnet_port 4444"> [...]> Anm: flash erase und flashen tut das openOCD nicht? Oder nur auf Geheiß?>
Richtig. Wenn Du OpenOCD so startest, dann wird es nur als Server
funktionieren. Über's Telnet Interface kannst Du Kommandos an OpenOCD
schicken; auf dem GDB Port lauscht der GDB Server.
Für die Optionen zum Flashen via OpenOCD siehe Beitrag #6398475 weiter
oben:
> echo program firmware.elf verify reset | nc localhost 4444
[...]
> openocd -f <Config File>.cfg -c "program firmware.elf verify reset exit"
Letztere Option beißt sich aber mit dem OpenOCD Server da der Programmer
sonst zwei mal geöffnet werden würde. Das ist eigentlich eher dann
relevant, wenn Du keinen GDB Server brauchst oder willst.
> Was aber geht, ist, wenn ich den RESET-Knopf drücke, daß dann das> Programm läuft und ich im picocom den Prompt sehe.>> ^C im gdb unterbricht dann.
Ja, so wie ich das verstehe hast Du mit dem "load" Befehl in der
.gdbinit das ELF Image geflasht.
Wenn Du den µC also via H/W Reset neu startest, dann sollte das Programm
ja aus dem Flash los laufen.
Bei mir wird beim Flashen via GDB der Prozessor auch gleich in den Reset
geschickt -- und bleibt dort stehen. Erst das "continue" im Debugger
sorgt dafür, dass das Programm auch los läuft.
Warum das "continue" bei Dir nicht funktioniert, kann ich nicht sagen.
Ich hatte hin und wieder den Fall, dass ein Neustart von OpenOCD hilft.
Evtl. gibt ja aber auch der Program Counter / Instruction Pointer einen
Hinweis, was schief läuft: "info reg pc" im GDB, falls nicht bekannt.
Danke für die Ausführungen. Sehr hilfreich mit dem nc. Ich wollte schon
telnet nachinstallieren aber fand es in macports ohnehin nicht so
schnell.
Philip S. schrieb:> ...> Warum das "continue" bei Dir nicht funktioniert, kann ich nicht sagen.> Ich hatte hin und wieder den Fall, dass ein Neustart von OpenOCD hilft.>> Evtl. gibt ja aber auch der Program Counter / Instruction Pointer einen> Hinweis, was schief läuft: "info reg pc" im GDB, falls nicht bekannt.
Tatsächlich läuft das Programm los, loopt aber an einer Stelle im
Bereich des UART init. Das folgt jetzt in einem anderen Thread. Soweit
hier alles erledigt.
Grüße
Christoph
Philip S. schrieb:> Christoph K. schrieb:
...
> Für die Optionen zum Flashen via OpenOCD siehe Beitrag #6398475 weiter> oben:>> echo program firmware.elf verify reset | nc localhost 4444> [...]>> openocd -f <Config File>.cfg -c "program firmware.elf verify reset exit">> Letztere Option beißt sich aber mit dem OpenOCD Server da der Programmer> sonst zwei mal geöffnet werden würde. Das ist eigentlich eher dann> relevant, wenn Du keinen GDB Server brauchst oder willst.>>> Was aber geht, ist, wenn ich den RESET-Knopf drücke, daß dann das>> Programm läuft und ich im picocom den Prompt sehe.>>>> ^C im gdb unterbricht dann.>> Ja, so wie ich das verstehe hast Du mit dem "load" Befehl in der> .gdbinit das ELF Image geflasht.>> Wenn Du den µC also via H/W Reset neu startest, dann sollte das Programm> ja aus dem Flash los laufen.>> Bei mir wird beim Flashen via GDB der Prozessor auch gleich in den Reset> geschickt -- und bleibt dort stehen. Erst das "continue" im Debugger> sorgt dafür, dass das Programm auch los läuft.>> Warum das "continue" bei Dir nicht funktioniert, kann ich nicht sagen.> Ich hatte hin und wieder den Fall, dass ein Neustart von OpenOCD hilft.>> Evtl. gibt ja aber auch der Program Counter / Instruction Pointer einen> Hinweis, was schief läuft: "info reg pc" im GDB, falls nicht bekannt.
Habe mal versucht, über das "nc" Kommando das board zu flashen und
bekomme dieses:
1
$ echo program firmware.elf verify reset | nc localhost 4444
2
????????Open On-Chip Debugger
3
> program firmware.elf verify reset
4
Unable to match requested speed 2000 kHz, using 1800 kHz
5
Unable to set adapter speed
6
Unable to match requested speed 2000 kHz, using 1800 kHz
7
mem2array: Read @ 0xe0042004, w=4, cnt=1, failed
8
Error executing event examine-end on target stm32f4x.cpu:
Ich glaube, die Zeile beinhaltet eine falsche Syntax, schrieb mir jemand
in der OpenOCD-mailing list. Ich solle das openOCD Manual im Bereich
"program" studieren.
Du schriebst zwar, daß mit dem "load" Befehl in der .gdbinit ohnehin die
Datei firmware.elf geflasht wird.
Das scheint aber nicht der Fall zu sein. Nach dem Start und continue
läuft wieder die Demoversion (rotating leds)
Ja, so funktioniert das bei mir. Ich hab' das vor vielen Jahren initial
aufgesetzt; seither ist das in meinen Makefiles vergraben und
funktioniert relativ problemlos. Wie weiter oben beschrieben kannst Du
Dir den Umweg über netcat / telnet sparen; das ganze funktioniert bei
Bedarf auch als Einzeiler.
Kannst Du das Board eigentlich anders, z.B. mit st-link oder dem
ST-eigenen Tool flashen? Sprich: Bist Du Dir sicher, dass die Hardware
funktioniert?
Du schreibst ja hier von einem Nucleo F411RE; in Deinem Thread zum UART
Problem ist die Rede vom STM32F4 Discovery Board. Bist Du Dir sicher,
dass Du die richtigen OpenOCD Config Files für's jeweilige Board
verwendest? Das Nucleo Board funktioniert bei mir mit
"st_nucleo_f4.cfg"; das Discovery Board mit "stm32f4discovery.cfg".
Danke. Ja, meine openOCD cfg-Datei ist stm32f4discovery.cfg.
Hauptsächliches Zielsystem ist im Moment das stm32f407G-DISC1 board, auf
dem ich erst mal zum verifizieren der Programmierkette das mecrisp-Forth
auf anderem UART-Port zum Laufen kriegen wollte.
Habe es gerade noch mal probiert. Ja, das mit dem load-Befehl
funktioniert so, wie Du es beschreibst. Vielleicht ist etwas mit dem
.elf File nicht in Ordnung. Ich hatte den .elf File vom mecrisp-forth in
firmware.elf umbenannt. Der wird aber nicht geflasht, weshalb auch meine
Frage aufkam.
Wie gesagt, nehme ich das Demonstration Programm STM32F4-DISC0.elf,
so flasht gdb, mit dem .elf vom mecrisp-forth nicht. Letzteres kann ich
nur mit
Christoph K. schrieb:> .elf File nicht in Ordnung. Ich hatte den .elf File vom mecrisp-forth in> firmware.elf umbenannt.
[...]
> Wie gesagt, nehme ich das Demonstration Programm STM32F4-DISC0.elf,> so flasht gdb, mit dem .elf vom mecrisp-forth nicht. Letzteres kann ich> nur mit>>
>> flashen.
Hast Du die Datei "mecrisp-stellaris-stm32f407.bin" nur in
"firmware.elf" umbenannt oder explizit nach ELF gewandelt? Ist
"mecrisp-stellaris-stm32f407.bin" wirklich ein ELF file?
Das könntest Du mit "file" prüfen. Beispiel:
1
$ file firmware.bin
2
firmware.bin: data
3
$ file firmware.elf
4
firmware.elf: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, with debug_info, not stripped
Philip S. schrieb:> Christoph K. schrieb:
...
>> Wie gesagt, nehme ich das Demonstration Programm STM32F4-DISC0.elf,>> so flasht gdb, mit dem .elf vom mecrisp-forth nicht. Letzteres kann ich>> nur mit>>>>
>>>> flashen.>> Hast Du die Datei "mecrisp-stellaris-stm32f407.bin" nur in> "firmware.elf" umbenannt oder explizit nach ELF gewandelt? Ist> "mecrisp-stellaris-stm32f407.bin" wirklich ein ELF file?>> Das könntest Du mit "file" prüfen. Beispiel:>>
> statically linked, with debug_info, not stripped
6
>
Genau das hatte ich gemacht. Auch mit dem file-Befehl noch mal explizit
überprüft. Ich habe den .elf-file genommen, nicht den .bin file.
Der bin-file wird ja mittels objcopy aus dem elf-File generiert. Also
dachte ich, zum Debuggen, den .elf-File nehmen zu können. Ist doch wohl
auch der richtige Weg?
Ja. Gebaut wird das ELF File. Daraus wird mit objcopy das .bin File
generiert. Bin mir nicht sicher, ob der Weg von .bin nach ELF überhaupt
gehen würde.
Ich bin mir auch nicht sicher, ob OpenOCD oder GDB das .bin File flashen
können; ich nutze der Einfachheit halber immer das ELF File.
Wenn Du also wirklich das ELF File versucht hast mit GDB zu flashen und
es weder mit GDB noch mit OpenOCD funktioniert, dann gehen mir langsam
auch die Ideen aus.
Ein Unterschied zw. .bin und ELF File, der mir noch einfällt: Wenn Du
das .bin File flashst, dann musst Du ja die Zieladresse explizit mit
angeben (0x0800 0000). Beim Flashen des ELF Files muss diese Information
ja irgendwie aus den ELF Headern kommen; man gibt sie ja sonst nirgendwo
an. Vielleicht lohnt es sich die Adressen im ELF File anzuschauen.
Philip S. schrieb:> Ja. Gebaut wird das ELF File. Daraus wird mit objcopy das .bin File> generiert. Bin mir nicht sicher, ob der Weg von .bin nach ELF überhaupt> gehen würde.>> Ich bin mir auch nicht sicher, ob OpenOCD oder GDB das .bin File flashen> können; ich nutze der Einfachheit halber immer das ELF File.>> Wenn Du also wirklich das ELF File versucht hast mit GDB zu flashen und> es weder mit GDB noch mit OpenOCD funktioniert, dann gehen mir langsam> auch die Ideen aus.>> Ein Unterschied zw. .bin und ELF File, der mir noch einfällt: Wenn Du> das .bin File flashst, dann musst Du ja die Zieladresse explizit mit> angeben (0x0800 0000). Beim Flashen des ELF Files muss diese Information> ja irgendwie aus den ELF Headern kommen; man gibt sie ja sonst nirgendwo> an. Vielleicht lohnt es sich die Adressen im ELF File anzuschauen.
Hi Philip,
danke für Deine Überlegungen. Ich bin jetzt in dem Thread "gdb
breakpoint setzen" schlauer geworden. .bin-file hat ja gar keine
Symbolinformation mehr. Komme jetzt ganz gut klar mit gdb und dem
.elf-File und kann mich jetzt dem eigentlichen Problem, warum ich aus
der USART-Schnittstelle noch nichts herausbekomme, widmen. Das Loopen in
der Clockinitialsierung der HSEClock ist auch verschwunden. War
vielleicht auch eine irrige Annahme auf Grund noch fehlender
Voraussetzung, sowohl bei mir als auch beim gdb-Setup :)
Grüße
Christoph
Thread beobachten
Seitenaufteilung abschalten