Ich hab jetzt dem algemeinen Trend nachgegeben und mit ein STM32F0 discovery geholt. Die Blink-Demo von gnu-arm-eclipse compiliert auch soweit recht reibungsarm (nachdem ich die ganzen debug-print dinger rausgeworfen hab, die killen iwie die kiste). Leider blinkt die LED nicht wenn man sich mit dem Debugger verbindet und das laufen lässt. Wenn der debugger aus ist (also keine gdb-verbindung), dann blinkt die LED fröhlich rum. Der Code passt also. Irgendwie verhindert wohl die debug-verbindung den systick den die demo zum timen des blinkens benutzt. Das muss doch irgendwie zu umgehen sein. Vlt. braucht ja der debugger nur einen speziellen Parameter oder so. Bei der blinkenden LED ist das jetzt ja rel. harmlos, aber wenn das mal losgeht mit richtigen Projekten, dann hätte ich schon gerne einen Debugger (v.a. Wenn der eh schon da is). PS: Das Setup sieht so aus: - STM32F0-Discovery mit ST-Link - PC: 64-Bit Kubuntu 14.04 - st-util - arm-gcc-none-eabi aus dem launchpad.net - eclipse mit gnu-arm-eclipse plugin - als projekt einfach die STM32F0 demo von dem plugin gewählt
Gast
#4102805
Läuft dein Programm denn überhaupt?! Wenn du einfach nur den GDB startest, wird der Controller angehalten. Du musst erst mit "c" das Programm laufen lassen...
Dr. Sommer schrieb: > Läuft dein Programm denn überhaupt?! Wenn du einfach nur den GDB > startest, wird der Controller angehalten. Du musst erst mit "c" das > Programm laufen lassen... Das ist zwar eine von den F-Tasten (F7 oder F8 glaubihc) und nicht "c", aber ja das läuft. Das läuft sogar so weit, dass es die LED anmacht, aber halt nie wieder aus, weil es ewig in einer while schleife wartet, dass der systick die wartevariable runtergezählt hat.
Gast
#4103055
Hallo Max, wieviele Brechpunkte hast du gesetzt? Meines Wissens nach sind 3 das Maximum, alles was darüber liegt führt zu komischem Verhalten bzw. abstürzen. Wenn es nicht an den Brechpunkten liegt mach doch mal diesen Durchlauf per Tastendruck F11 glaube ich war das... Schau dir parallel doch mal den LED-GPIO an, passiert da etwas? Beste Grüße public
Also Breakpoints hab ich im Moment genau 0, zwischendurch hatte ich mal einen in den Systick rein (eben weil ich vermutet hab, dass der nicht feuert). Bei mir startet F11 das debugging (was ich auch manuell über die ui auch anstoße).
Während des Debuggens werden häufig Interrupte nicht angesprungen. Meist ist es auch eine Einstellungssache. Gerade so ein Timerinterrupt würde sich sonst ständig einmischen. Breakpoint nach der while() und laufenlassen. Wenns hilft - welche GUI nutzt du zum Debuggen mit gdb? Die Funktionstasten dürften beim gdb selbst nicht gehen.
Gast
#4103219
Hallo, ich benutze zwar OpenOCD und nicht ST-Util aber vielleicht hilft es ja trotzdem. Ich hatte einige Male das Phänomen, dass die MCU anscheinend einfach stehen geblieben ist. Wenn ich die MCU im Debugger dann angehalten habe, ist mir aufgefallen, dass er an einer Stelle stehen geblieben ist, an der ich FRÜHER einen Breakpoint hatte. Diesen BP hatte ich in der Zwischenzeit aber schon gelöscht. Das einzige, was dann geholfen hat, war in der BP-Übersicht rechtsklicken und ALLE Breakpoints entfernen auswählen. Danach lief das Programm wie gewohnt weiter. (PC neustarten wird's wahrscheinlich auch tun) CU, Jay
Steffen Rose schrieb: > Wenns hilft - welche GUI nutzt du zum Debuggen mit gdb? Die > Funktionstasten dürften beim gdb selbst nicht gehen. Eclipse (mit gnu-arm-plugin falls das was ändert). Ich hab quasi diese Anleitung: https://www.mikrocontroller.net/articles/STM32_Eclipse_Installation genommen und wo's gehakt hat bischen rumprobiert. Ich hatte gehofft, dass es vlt. so einen switch in der Art "--enable-interrupts=true" oder so gibt. Bei dem Switch-jungle blink ich halt in tausend Jahren nich durch, deswegen hatte ich gehofft, dass da jemand das gleiche schon hatte oder so. Jay schrieb: > Hallo, > > ich benutze zwar OpenOCD und nicht ST-Util aber vielleicht hilft es ja > trotzdem. Ich hatte einige Male das Phänomen, dass die MCU anscheinend > einfach stehen geblieben ist. Wenn ich die MCU im Debugger dann > angehalten habe, ist mir aufgefallen, dass er an einer Stelle stehen > geblieben ist, an der ich FRÜHER einen Breakpoint hatte. Diesen BP hatte > ich in der Zwischenzeit aber schon gelöscht. Das einzige, was dann > geholfen hat, war in der BP-Übersicht rechtsklicken und ALLE Breakpoints > entfernen auswählen. Danach lief das Programm wie gewohnt weiter. > (PC neustarten wird's wahrscheinlich auch tun) > > CU, > Jay Das kann bei mir eigtl. nich sein, weil ich ja erstmal komplett ohne breakpoints angefangen hab.
Gast
#4103510
Hey Das thema mit den breakpoints und scheinbar latent noch vorhanden kenne ich auch. Da hilft dann wirklich nur alle punkte löschen. Aber zurück zu dem richtigen problem. Stell doch mal deine software rein, oder schick nen link. Irgendwo hab ich auch noch so ein board rumfliegen. Beste grüsse Public
Max D. schrieb: > Ich hatte gehofft, dass es vlt. so einen switch in der Art > "--enable-interrupts=true" oder so gibt. Bei dem Switch-jungle blink ich > halt in tausend Jahren nich durch, deswegen hatte ich gehofft, dass da > jemand das gleiche schon hatte oder so. Vielleicht geht dies in die richtige Richtung: https://forums.openpilot.org/topic/1671-debugging-with-interrupts-in-eclipse/ Ich nutzen deine Umgebung nicht. Würde aber denken, dass dies mittlerweile default ist, also im Schrittbetrieb Interrupte aus und wenn du das Programm laufen läßt Interrupte an. Das sollte sich leicht nachprüfen lassen. Funktioniert dein Programm nach 'continue' wieder wie erwartet?
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.