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.
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.
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.
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.