Forum: Compiler & IDEs MCU Eclipse Plugin: MCU startet nicht ohne debugger


von Peinlich (Gast)


Lesenswert?

Irgendwie stehe ich gerade auf dem Schlauch: Ich habe das MCU Eclipse 
Plugin in Eclipse Photon installiert. Läuft auch alles. Nun will ich ein 
Blue Pill Board mit nRF24L01+ als Sender an verschiedenen Stellen im 
Haus per Wandwarze betreiben, um am Rechner den Empfang zu testen. Die 
LED PC13 (run-indikator) blinkt aber nicht...

Ich habe "Release" beim build eingestellt, neue Debug-Konfiguration, 
"break at main" nicht aktiviert. Mit Debugger läuft auch dieser build 
korrekt. Wo muß ich da noch was bei den debugger-tabs einstellen? Ich 
hätte gedacht, daß das bei "Release" automatisch vom plugin gemacht 
wird.

von Christopher J. (christopher_j23)


Lesenswert?

Eventuell semihosting aktiviert?

von Lutz (Gast)


Lesenswert?

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).

von Lutz (Gast)


Lesenswert?

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?

von Micha (Gast)


Lesenswert?

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.

von Jim M. (turboj)


Lesenswert?

Lutz schrieb:
> Irgendwie bin ich gerade voll blind.
> Vorschläge?

Startup code disassemblieren. Entweder mit dem Map File oder notfalls in 
der Vektortabelle nachschauen wo der anfängt. Kann man auch bequem aus 
Eclipse raus beim Debugging machen.

Wenn da "bkpt" Instruktionen auftauchen, hat man Semihosting Code 
gefunden.

von Lutz (Gast)


Lesenswert?

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.

von Johannes S. (Gast)


Lesenswert?

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?

von Lutz (Gast)


Lesenswert?

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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.