MCU Eclipse Plugin: MCU startet nicht ohne debugger

Witzig. Habe das gerade mal ausprobiert. Geht bei mir auch nicht: Habe 
die gleiche Konfiguration (Photon und Plugin). Semihosting beim wizzard 
nicht aktiviert. Vor längerer Zeit hat es mal funktioniert.

Ein bug im plugin scheint zu sein, daß beim startup-tab in der 
debug-config das Häkchen "Set breakpoint at main" deaktivieren nicht 
reicht. Ich mußte zusätzlich in der debug-perspektive auf dem 
breakpoint-tab den breakpoint deaktivieren (bei der Gelegenheit gleich 
alle, falls da noch welche wären).

Weiterhin unter C/C++ Build -> Settings: Es dauert 8 Sekunden, bis das 
Fenster aufgebaut wird. Das könnte aber auch mit dem "GTK3-bug" 
zusammenhängen (also evtl. kein Problem, wenn mit GTK2 gestartet wird).

Spannend. Hatte mich moch mal damit beschäftigt, bekomme es aber nicht 
hin.

Alle mir bekannten semihosting-Einstellungen sind nicht da (auch kein 
irgendwo angehängtes --specs=rdimon.specs).
Wenn ich mit "attach to running target" rangehe, läuft das Ding wie es 
soll los. Ich kann auch stoppen und lande im code (mit entsprechendem 
ELF).
Auch mit JLinkExe bzw. dessen Linuxpendent das Selbe: Sofort nach 
connect läuft er los.
Kein breakpoint zu finden.
An der debug configuration liegt es auch nicht: Einfach ein anderes ELF, 
und es funktioniert.
Mit debugger ist das Problem aber nicht da, so daß ich im Moment nicht 
weiß, wie ich da weiter vorgehen soll. Vielleicht ist es eine 
Einstellung im startup code vom plugin, aber mit sowas habe ich mich 
bisher noch nicht beschäftigt. Irgendwie bin ich gerade voll blind. 
Vorschläge?

Lutz schrieb:
> Weiterhin unter C/C++ Build -> Settings: Es dauert 8 Sekunden, bis das
> Fenster aufgebaut wird. Das könnte aber auch mit dem "GTK3-bug"
> zusammenhängen (also evtl. kein Problem, wenn mit GTK2 gestartet wird).

Das dauert bei mir noch länger als 8 Sekunden, liegt aber tatsächlich am 
GTK3-Bug, mit GTK2 ist es verschwunden.

Danke, komplettes Neuland betreten. Das war/ist es aber nicht 
(wirklich). Habe bei jedem ISR-Vektor einen bkpt 0x000 gefunden. Obwohl 
im Compilerstring in Eclipse nicht ersichtlich, war __DEBUG_BKPT() durch 
-DDEBUG unter "C/C++ Build" - "Settings" aktiviert. Das dann 
rausgenommen und keine bkpt mehr im disassemler. Zeigt aber trotzdem das 
gleiche Verhalten. Hm.

Dann mit "restore defaults" im plugin (C/C++ Build - Settings) das 
-DDEBUG wieder herstellen: Eclipse semmelt jedesmal ab. Egal ob mit GTK2 
oder GTK3.

Morgen ist auch noch ein Tag.

Lutz schrieb:
> Dann mit "restore defaults" im plugin (C/C++ Build - Settings)

das habe ich als sehr gefährlich in Erinnerung - stellt das nicht alles 
mögliche auf default zurück?

Na ja, zumindest nicht das, was ich versuche.
In diesem Fall sogar gonnix, da es absemmelt.

Ich habe Eclipse bisher immer als Konstante gesehen: Immer die gleiche 
IDE, egal welches Target. Genaugenommen hat mir der Editor immer am 
besten gefallen. Aber jeder bastelt ein plugin dazu (ist jetzt echt 
nicht negativ gemeint, eher das Gegenteil!) und es kommt die "was 
passiert dann Maschine" bei raus. Ich habe jetzt sehr oft die gleichen 
Prozeduren durchgeführt, und öfters reagiert die IDE anders. Das schafft 
nicht unbedingt vertrauen. Ob das jetzt von Eclipse oder vom plugin 
kommt, gute Frage. Wenn ich z.B. mit Strg+v in den Ordner "source" eine 
c-Datei einfüge, läuft in 5 von 6 Fällen irgendein merkwürdiges Fenster 
danach durch. Und danach findet er beim compilieren z.B. _start() nicht, 
dann sind Definitionen von <stdint.h> nicht geläufig usw..
Das CDT ist ja auch ... sagen wir, anders.

Mal sehen; heute habe ich sowieso schlechte Laune. Also erstmal was 
anderes machen.