[STM32] GDB und systick

[Max D. (max_d)]

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

[Dr. Sommer (Gast)]

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

[Max D. (max_d)]

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.

[public (Gast)]

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

[Max D. (max_d)]

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

[Steffen R. (steffen_rose)]

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.

[Jay (Gast)]

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

[Max D. (max_d)]

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.

[public (Gast)]

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

[Steffen R. (steffen_rose)]

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?