Moin zusammen,
ich debugge gerade recht viel auf dem STM32F4-Discovery. Das mache ich
mit Eclipse Yagarto und eben dem GDB-Server von Atollic für den ST-Link
V2.
Das funktioniert auch alles super, mein Problem ist aber der Reset.
Um den Debugger in Eclipse zu reseten weil ich im Code zuweit gelaufen
bin muss ich immer "Terminate and Restart" machen, dann startet der aber
die gesammte Debugsession neu und Flasht das Programm neu. Das dauert
ewig.
Der eigendliche Resettaster ist aus gegraut. Weiß jemand wie ich eclipse
dazu überredet bekommen einfach im Debug auf Knopfdruck den Controller
zu reseten und wieder von Reset_Handler aus los zu laufen?
Das Plugin Zylin habe ich auch bereits aus probiert aber das nimmt meine
Startup commands nicht an/bzw. der gdb sagt er unterstützt das Commando
nicht.
1
target remote localhost:61234
2
3
# Set flash parallelism mode to 32, 16, or 8 bit when using STM32 F2/F4 microcontrollers
4
# 2=32 bit, 1=16 bit and 0=8 bit parallelism mode
5
monitor flash set_parallelism_mode 2
6
7
monitor reset
8
9
monitor sleep 2000
10
11
# Load the program executable
12
load
13
14
# Set a breakpoint at main().
15
tbreak main
16
17
# Run to the breakpoint.
18
continue
Das sind meine derzeitigen Startupcommands für Zylin
Funktionieren tut das Debugging aber nur über den Standard-GDB von dem
GDB Hardware Debuggin Plugin.
Also wie mach ihr den Reset?
MfG
Tec
Mit einer weiteren Debug-Configuration ohne "load"-Anweisung versucht?
Ich lege mir meist drei Konfigurationen an: (1) nur flashen und laufen
lassen (2) flashen und debugging starten (3) debugging starten ohne
flashen (also ohne load).
Leider noch keinen STM32F4 hier um eine getestete "Musterlösung"
anbieten zu können, bei anderen Targets funktioniert der Ansatz aber
ausreichend gut.
Hallo Martin,
Danke für den Vorschlag. Ich denke ich werden diese Workaround mal
probieren. Aber wirklich glücklich bin ich damit noch nicht :)
Meine ganze Toolchain läuft jetzt richtig schon nur der Reset stört mich
:)
Ich weiß ich könnte Keil,IAR,Crossworks und Konsorten nehmen, aber die
haben keine guten Editoren, und sind bis auf Crossworks zu teuer.
Und die Lite von Atollic kann kein Cpp.
Ich werd mal noch bei den Coocox leuten schauen wie die das machen vllt
kann man was von dehnen in das normale Eclipse einbauen.
MfG
Tec
Hallo Jungs,
ich bin neu hier und habe immer mal wieder Verbindungsprobleme zu dem
genialen STM32F4-Discovery-Board über Eclipse-Indigo und
ST-Link-gdb-server. So wie im Lotto bekomme ich Zugang zum Board obwohl
mit dem ST-Link-Utility alles reibungslos läuft. (Beim St-Link-Server
Start blinkt die LED kurz grün und ist dann wieder rot obwohl eine
aktive Verbindung angezeigt wird)
Nach dem ersten Debugging geht’s nur wieder mit abziehen des USB-Kabels.
Woran krankt diese Verbindung?
Wie stelle ich Eclipse 100% richtig ein?
External-Program: ST-Link_gbdserver.exe (V2) mit “–e –d”
Debug-Conf: \arm\bin\arm-none-eabi-gdb.exe ; TCP/IP ; localhost ; 61234
Main: Using GDB(DSF) Hardware Debugging Launcher
Haken bei: Use Worksp Set;
BuildConf=Debug
Habe schon viele Einstellungen probiert, auch so was:
ST-Link_gbdserver.exe -e -s -d -l 31 -p 4242 -v -r 15
oder so...an am Port liegt es nicht.
ST-Link_gbdserver.exe -e -s -d -l 31 -p 61234 -v -r 15
Atollic TrueSTUDIO gdbserver for ST-Link. Version 1.4.0 Pro
Developed by Atollic AB for STMicroelectronics
Copyright 2010-2011, Atollic AB and STMicroelectronics
Starting server with the following options:
Persistant Mode : Enabled
LogFile Name : debug_log.txt
Logging Level : 31
Listen Port Number : 61234
Status Refresh Delay : 15s
Verbose Mode : Enabled
SWD Debug : Enabled
NVIC_DFSR_REG = 0x00000009
NVIC_CFGFSR_REG = 0x00000000
ST_LINK Major version =2 Jtag version =14
ST_LINK VID=1155 PID=14152
ST_LINK device status: HALT_MODE
Hardware watchpoint supported by the target
FuncEntry
STM32 device: id =20006411
STM32 device: Flash size =1024
FuncExit
FuncEntry
FuncExit
Connected to the ST-Link Debugger.
Start Logging
Waiting for client to connect on port 61234 ...
Auch mit dieser Einstellung geht es einige Zeit.
Wenn es nicht geht heißt es „Error while launching command: gdb
--version
Wer hat diese Probleme auch?
Wie ist es 100% richtig. In der Leitung ist kein Wackelkontakt ;)
Vielen Dank
Tomy
Moin Thomas,
http://chibios.org/dokuwiki/doku.php?id=chibios:guides:stlink_eclipse
Diesen Guide habe ich genommen um meinen ST-Link einzustellen, ich
benutze auch das F4 Discovery. Ich hab nur recht selten Probleme mit der
Verbindung und da reicht meist ein simpler neustart des GDB Servers.
MfG
Tec
Hallo Tec,
Habe es mal genauso wie Chibios eingegeben...aber der gdb-Server hat
mich nicht lieb.
Gleiche Fehlermeldung.
Wie gesagt mit dem ST-Link-V2-Utility funktioniert alles.
Da habe ich Heute mal das Atollic-StudioSTM32-Light installiert.
Dann den die STM32F4-Discovery-Demo als Workspace verwendet und das
Projekt RCC(Demonstration) importiert, Build, alles läuft
fehlerfrei...gut den Target noch auf 32F4Discovery ändern.
Dann ohne externes Programm einzufügen auf Debug den ST-Link gewählt und
es geht los. Man geht hin- und her ohne Probleme. So soll es sein.
Warum geht das nicht mit Indigo oder Helios in WinXP.
TrueStudio nutzt jetzt ST-Link_gdbserver 1.4.1 statt 1.4.0 in Indigo
Dann ist in TrueStudio die arm-atollic-eabi-gdb.exe = 18.071kbyte vom
10.11.2011
Die Indigo arm-none-eabi-gdb.exe = 4.135kbyte vom 20.4.2011
Hat noch jemand ne Idee?
Bei wem es funktioniert, Bitte mal die genauen Daten zu
ST-Link_gdbserver und arm-none-eabi-gdb.exe und Einstellungen bekannt
geben. Ich sage Euch dann auch wie Euer F4Discovery in der Anwendung
40mA weniger Strom nimmt.;)
Tomy
Moin,
Also ich habe Yagarto mit dem 4.6.2er GCC bei mir, Mein GDB müsste aus
dem Atollic 2.3.0 sein.
Aber wenn der Atollic GDB bei dir mit dem 1.4.1 StLink Server geht dann
nimm doch den.
Die einzigen Probleme die ich habe ist das ich nach einem erneuten Flash
download im MemManage_Handler lande und nicht in der main.
sonst läuft das bei mir in Eclipse sogar besser als Atollic, das springt
bei mir der GDB wie wild durch die gegend. Da ist irgend ne Optimierung
an die ich nicht finde ist mir aber auch egal.
Also ich kann dir nur sagen das was in dem Chibios Guide steht
funktioniert bei mir auf ner Win7 x64 Maschine mit Eclipse Indigo
tatellos. sonst update doch mal alle Komponenten Schrittweise vllt
bringt das was.
MfG
Tec
Hallo Tec,
Nun hatte ich mal wieder Zeit und alle Eclipse-Indigo-Updates gemacht.
Man stochert irgendwie im Nebel rum.
Nach ChibiOS alles eingetragen, kommt nun beim Debugstart nen Fenster
„Launch Debug Conf. Selction“ Fenster mit folgender Auswahl
- Embedded GDB
- Gdbserver
- Remote gdb/mi
Ich wähle gdbserver oder die anderen mit immer dem gleichen alten
Fehler.
Was passiert: Er trägt bei C/C++Application im Debug-Setup „mp32f4.elf“
ein, mein Linkerfile ok.
Im dazugehörigen Menü gibt’s wieder Main, ,..Debugger. Dort steht „gdb“
und bei Command “.gdbinit“. Das gdb habe ich mal auf
„\Indigo\arm\bin\arm-none-eabi-gdb.exe“ geändert....und nix wird besser.
Bei Source steht „Default“
Was steht bei Euch da drin? Jetzt wo TrueStudio die Türen zu macht. ;(
Tomy
Moin Tomy,
Das habe ich auch, du kannst nicht direkt auf Debug klicken, du musst in
dem Dropdown die Debugkonfig von dem Projekt direkt starten.
MfG
Tec
Man Tec,
das war es...und ich dachte nur ich bin zu blöd.
Warum läst Du mich so lange zappeln? ;)
Vielen Dank dafür.
So ist das wenn man mit wenig Geld auskommen will.
So wie versprochen nen kleiner Tipp zur Stromaufnahme.
Nutzt man das F4-Board in der Anwendung ist der ST-Link-Teil mit seiner
ganzen Umgebung noch aktiv.
Einfach im Schaltplan nachschauen und den Reset-Pin an R18 über einen
kleinen Draht zu den ungenutzten Jumper links oben verdrahten. Natürlich
vorher die Masseverbindung oben auf dem Bord unterbrechen. Geht ganz
einfach. Dann in der Anwendung den Jumper links oben stecken und RST vom
ST-Link-Teil auf Masse setzen. Das Board dankt es nun mit 40mA weniger
Strom.
Tomy
Servus,
Ich verwende zwar Eclipse Galileo, aber vielleicht hilft es...
Bei mir hat der Restart-Button auch nicht wirklich funktioniert, er war
zwar nicht ausgegraut, hat aber bei Benutzung zu einer Fehlermeldung
geführt. Das Commando Run werde nicht unterstützt.
Habe dann in meiner .gdbinit das Kommando Run einfach definiert:
define run
monitor reset
continue
end
Et voilà, es funktionierte.
HTH, Ralf
Vieleicht lest ihr ja noch mit:
@Ralf:
Kannst du das bitte genauer erklären, wie du wo "run" neu definiert
hast.
Eine Datei mit .gdbinit habe ich nicht.
Steffen
Run/Debug Configurations../
Links im Tree hab ich unter GDB Hardware Debugging einen Eintrag
"ST-Link Load".
Rechte Maustaste "duplicate"
Dann umbenannt in "ST-Link RUN"
Jetzt rechts im Reiter "Startup" den Haken bei "Load Image" entfernt.
Mit dem neuen Knopf kannst Du jetzt das gleiche machen. Nur wird nicht
mehr geflasht.
Das flashen vor Debug ist nicht das Problem.
Ich möchte wissen, wie ich eigene Befehle definieren kann.
Steffen
By the way: Gibt es mittlerweile eine Lösung für den Neustart des
Debuggers ohne vorher mit "Terminate" alles abschießen zu müssen?
Klick auf "PAUSE" und geh mal unten in die Konsole "ST-Link Run [GDB
Hardware Debugging] gdb".
Gib ein:
continue
Er läuft dann weiter
Gib ein:
start
Und du bekommst die Meldung:
The "remote" target does not support "run". Try "help target" or
"continue".
Hier die Erklärung:
http://sourceware.org/gdb/onlinedocs/gdb/Starting.html
Wie ich das lese gibt es keine Möglichkeit bei einem Remote-Target einen
Reset durchzuführen.
Hi Leute,
ich versuche seit gestern vergeblich den GDB mit dem gdbserver von
Atollic zum laufen zu bringen.
Wenn ich den gdbserver starte bekomme ich folgendes:
1
C:\Users\Thomas>ST-LINK_gdbserver -d -e -v
2
3
4
Atollic TrueSTUDIO gdbserver for ST-Link. Version 1.6.0 Pro
5
Copyright 2010-2012, Atollic AB.
6
7
8
Starting server with the following options:
9
Persistant Mode : Enabled
10
LogFile Name : debug_log.txt
11
Logging Level : 31
12
Listen Port Number : 61234
13
Status Refresh Delay : 15s
14
Verbose Mode : Enabled
15
SWD Debug : Enabled
16
17
Connecting to the ST-Link Debugger...NVIC_DFSR_REG = 0x00000009
18
NVIC_CFGFSR_REG = 0x00000000
19
ST_LINK Major version =2 Jtag version =15
20
ST_LINK VID=1155 PID=14152
21
ST_LINK device status: HALT_MODE
22
Hardware watchpoint supported by the target
23
FuncEntry
24
STM32 device: id =10016413
25
STM32 device: Flash size =1024
26
FuncExit
27
FuncEntry
28
FuncExit
29
OK
30
Start Logging
31
Waiting for debugger connection...Waiting for TrueSTUDIO client to connect on port 61234 ...
Sobald ich dann mit dem gdb über
1
target remote localhost:61234
darauf zugreifen will, beendet sich der gdbserver:
Hab gerade gesehen dass die ganzen Anleitungen auf dem gdbserver der
Version 1.4 basieren, ich hab aber 1.6. Kann mir jemand von euch den
GDB-Server und die DLL der Version 1.4 zuschicken? Im Internet scheint
es diese Version nicht mehr zum Download zu geben!
E-Mail: thomas (a) oc-tuning (dot) de
Danke schonmal!
I have found older versions of the Atollic GDB server here:
http://download.atollic.com/TrueSTUDIO/
Both v 3.0.0 (GDBserver version 1.5.6) and 3.1.0 (GDBserver version
1.6.0) seem to accept GDB connections from the Sorcery
arm-none-eabi-gdb.exe version 7.4.1
Best regards (Und entschuldigung für nicht deutsch schreiben :-) )
Hallo, leider schlag ich mich jetzt auch mit dem Problem herum,
gibt es schon eine Lösung - ich versuche es gerade mit
Atollic TrueSTUDIO gdbserver for ST-Link. Version 1.7.0 Pro
und
GNU gdb (Sourcery CodeBench Lite 2011.09-69) 7.2.50.20100908
Fehler ist:
[2.142] Socket_WaitForTrueStudioConnection(): Receive buffer size set
to 65536 bytes.
[2.142] Socket_Write(): Tx: #4c63$
[2.142] Socket_Read(): Rx: +
[2.142] Socket_Read(): Rx: $qSupported:qRelocInsn+#9a
[2.242] main(): Error while waiting for debugger connection.
Hallo,
ich habe exakt das selbe Problem, finde aber auch nirgends die kleinere
Version.
Wäre jemand so nett und würde mal den GDB Server 1.6.0 zippen und
irgendwo hochladen?
Das wäre super!
Gruß
Stomper
Hi,
stehe vor dem selben Problem.
Board ist ein STM32dicovery mit stm32f100rbt6, dazu atollic gdb server
1.8.0 pro und eclipse juno incl. aktuellen yagarto.
Compilieren funktioniert so weit ich sehen kann gut, nur beim
flash-versuch kommt folgendes:
TrueSTUDIO client connected.
Receiver buffer size set to 65536 bytes.
Error while waiting for debugger connection, error 37.
Shutting down...
Debugger connection lost.
Shutting down...
Zum error 37 habe ich online nichts hilfreiches gefunden.
Hat jemand inzwischen eine Kombination gefunden die zuverlässig
funktioniert?
Weis jemand wo ich momentan ältere Versionen des gdb-servers her bekomme
bzw. ob das überhaupt weiter hilft?
Vielen Dank für eure Hilfe im Voraus,
viele Grüße
Alex
Martin Thomas schrieb:> Ich lege mir meist drei Konfigurationen an: (1) nur flashen und laufen> lassen (2) flashen und debugging starten (3) debugging starten ohne> flashen (also ohne load).
Hallo,
kannst Du Deine Konfiguration etwas beschreiben? Ich laufe gerade in ein
ähnliches Problem, bei dem Konfiguration (3) womöglich hilft (siehe
Thread hier: Beitrag "Cortex M3 - Debugger nachträglich anschließen?" ).
Viele Grüße
W.T.