Hallo Experten! Auf das Problem bin ich folgendermaßen gestoßen: [[Beitrag "STM32 externer Interrupt funktioniert nicht immer!"]] Dabei bin ich darauf gekommen, dass auch der Systick Interrupt nicht funktioniert! Mittlerweile habe ich mir die die STM32F10x_StdPeriph_Lib_V3.5.0 besorgt und das Beispiel mit dem Systick compaliert (0 Fehler 0 Warnings). Ich habe das im Bsp. Hinterlegte IAR-Projekt verwendet. In IAR habe ich die das Projekt STM3210E-EVAL eingestellt damit wird der Startup startup_stm32f10x_hd.s verwendet. Der Systick läuft, aber es wird nicht in die ISR gesprungen! Ich verwende das STM32-LCD Board von Olimex (STM32-F103ZE) zum debuggen verwende ich den ARM-USB-OCD mit OpenOCD (Debugger Einstellungen im IAR-Projet angepasst: GBD-Server, localhost,3333). Als Entwicklungsumbebung ist das IAR - Kickstart V 6.0 im Einsatz. Ich bin dankbar für jede Hilfe!
Hat keiner einer Idee was da faul sein könnte? Falsche Einstellungen oder irgend eine blöde Kleinigkeit oder so. Bin nämlich schön langsam am verzeifeln!
Wir wissen nicht was Du alles verstellt hast. Deinstallieren und noch mal von vorn anfangen. Und dann nimm als Start ein IAR-Beispiel als Projekt-Vorlage. Oder flash das Programm mal mit einen anderen Tool, vielleicht hat der Debugger ne Macke.
Danke für den Tipp! Werd es Mal versuchen. Meld mich dann wieder. Was mir noch eingefallen ist: kann man die Interrupts beim STM32 irgendwo global aktivieren/deaktivieren und wenn ja welsches Register/welcher Befehl? PS: schönes Wochenende!
Global aktivieren nein. Ich habe lange dran rumgefummelt den richtigen EXTI_Kanal zu finden. Schau ins Errata sheet. Eventuell auch noch der Klassiker ? Alle Header eingebunden ( misc.h für Systick) ? Alles notwendige mit Takt versorgt? Richter µc eingebunden ? (#defines ) mfg Jan
Hab IAR EW und OpenOCD deinstalliert und wieder installiert. Danach habe
ich mit IAR EW ein Projekt für den STM32F103ZE (es gibt von IAR ein
eval-Board) geöffnet. Habe dann die Files aus dem ST Bsp in das Projekt
eingefügt. Compalieren 0 Fehler 0 Warnings. Funktionierte leider wieder
nicht!
> Oder flash das Programm mal mit einen anderen Tool, vielleicht hat der
Debugger ne Macke.
Ich habe leider nur das Eine. Aber die Variablen und der Programm ablauf
werden ja richtig angezeit. Ist es dann möglich das der Programmablauf
in keine ISR springt? Ich besorge mir aber vielleich noch ein neus Tool.
@Jan:
Der Kanal war schon der richtige, es hat ja ab und zu funtioniert. Die
header müssten alle vorhanden sein. Versorgung mit Takt ist eingestellt,
ich verwende das Bsp von ST, da müssten doch alle Takte richtig
eingestellt sein.
Ich finde nur seltsam das der Programmablauf nicht in die ISR Springt
obwohl der MC den Interrupt erkennt und das passende Bit im
Pend-Register setzt.
Kann mir einer vielleicht ein Bsp mit SysTick oder externen Interrupt
für IAR EW zukommen lassen, das schon mal funktioniert hat. Das könnte
ich dann bei mir test.
>Hab IAR EW und OpenOCD Du hast aber auch eine seltsame Konfiguration. Man sollte einen Debugger nehmen, der auch von IAR unterstützt wird. Empfehle Dir den ST-Link, kostet ca. 25 Euro und ist optimal auf die STM32 (und nur diese!) abgestimmt. Dann kannst Du auch zB. das kostenlose Atollic TrueStudio Lite nehmen, was keine Kode- bzw. Debugeinschränkungen hat.
> Empfehle Dir den ST-Link, kostet ca. 25 Euro und ist optimal auf die > STM32 (und nur diese!) abgestimmt. Danke für den Tipp! Habe ihn soeben bestellt! > Du hast aber auch eine seltsame Konfiguration. Ich verwende den ARM-USB-OCD Debugger on Olimex. Treiber und Beschreibung habe ich von der Homepage heruntergeladen. Es war auch eine Anleitung dabei wie ich das Tool in IAR EW nutzen kann. Es hat auch alles gleich geklappt, bis auf das mit den Interrupts. Na ja, ich hoffe das es mit dem ST-Link funktioniert. PS: Ich habe den ST-Link/V2 bestellt der müsste ja auch passen oder?
Hab auch eimal das Problem gehabt. Es lag an den unterschiedlichen Schreibweisen von "SysTick_Handler"(z.B.SysTickHandler) Schau in deinem Startup file nach,was da genau steht. Weiters sind beim STMF32 die peripheren Einheiten mit Clock zu versorgen bevor man auch nur irgendwas in dessen Register schreibt. Grüße Gebhard
Du verwendest OpenOCD? Dann kannst Du doch alle Interrupts abfangen. Verbinde Dich während des debuggens mit der Telnet-Konsole:
1 | telnet 4444 |
.. und gib dort folgendes ein:
1 | cortex_m3 vector_catch all |
Damit hält er automagisch an, wann immer ein Intterupt oder Fault auftritt. Eventuell sieht mann dann auch im Assembler-code, ob er in den korrekte Intterupt-Handler springt.
Angehängte Dateien:
Sorry ich hab mich in letzter Zeit mit anderen Dingen beschäfigen müssen und hatte noch nicht viel Zeit weiter an dem Problem zu arbeiten. @Gebhard Raich: Die ISR Namen stimmen. >Und gab es Probleme mit der V2 ? Ja also, die Verwendung von V2 hat mit meiner Version von IAR nicht funktioniert, darum habe ich mir die neuste Version geholt. Damit habe ich auch das SysTick Bsp. zum laufen bekommen (funktioniert alles einwandfrei, auch die Interrupts). Nur wenn ich den Code erweitere ich also zum Bsp. ein printf für Debugausgaben oder andere größere Funktionen einfüge wird der Code zwar fehlerfrei compaliert, aber beim laden auf den Controller hängt sich der IAR dann immer auf! Wenn ich nur ein paar Codezeilen einfüge ist dies allerdinges kein Problem. Mit OpenOCD habe ich dieses Problem nicht, allerdings besteht hier weiter das Problem mit den Interrupts! @Turbo J: Danke für den Tipp. Ich kann es aber leider erst mitte nächster Woche ausprobieren. Ich meld mich aber dann sofort mit Ergebnissen. @alle: Hat jemand eine Idee was mit dem ST-Link/V2 schief laufen könnte? Die Version 2 muss doch eigentlich funktionieren oder kann es sein, dass irgendwelche Kompatibilitätsprobleme mit IAR EWA bestehen? Hier nochmal die Eckdaten: - ST-Link/V2 - Treiber von ST-Homepage heruntergeladen (für V2) - IAR EWA Verson 6.2 - Einstellungen ST-Link siehe Anhang Habe auch andere Einstellungen (Reset Pin und Connect during reset)versucht, ohne Erfolg. - STM32-LCD Board von Olimex mit STM32-F103ZE Für weitere Tipp und Anmerkungen wäre ich dankbar!
Versuch doch mal die Systick-Intervallzeit zu vergrößern. Vielleicht ist er mit der Funktion noch nicht durch, wenn er wieder auslöst. Es kann auch ein Problem mit dem Stack sein, wenn z.B. ein struct nicht auf einer Adresse anfängt, die eine vielfache von 4 ist. z.B. 8 bit variable auf 32 bit Controller. So richtig habe ich das Problem an der Stelle noch nicht gefunden, aber solche Probleme tauchten in meinem Projekt momentan öfter auf. Ich habe nun z.B. alle Stringlängen in vielfachen von 4 und keine Probleme mehr. Programmiere allerdings mit gcc.
Turbo J schrieb: > cortex_m3 vector_catch all > > Damit hält er automagisch an, wann immer ein Intterupt oder Fault > auftritt. Im Gegensatz zu anderen ARM Prozessoren kann man damit bei Cortex-M Prozessoren keinen Interrupt abfangen. Da musst Du schon einen Breakpoint auf die ISR setzen. -- Marcus
hallo Marcus, Marcus Harnisch schrieb: > Im Gegensatz zu anderen ARM Prozessoren kann man damit bei Cortex-M > Prozessoren keinen Interrupt abfangen. Weisst Du auch, warum das so ist? Danke! ZiZi
ZiZi schrieb: >> Im Gegensatz zu anderen ARM Prozessoren kann man damit bei Cortex-M >> Prozessoren keinen Interrupt abfangen. > > Weisst Du auch, warum das so ist? Bei einem, bzw zwei Interrupts war das noch zu rechtfertigen, aber bei bis zu 496? Da ist es auch keine Lösung, bei beliebigem Interrupt in den Debug state zu gehen. Außerdem hat man zumindest in den üblichen Cortex-M3 Implementierungen acht BP plus WP. Da kann man ja ruhig mal einen auf die ISR setzen. -- Marcus
>Versuch doch mal die Systick-Intervallzeit zu vergrößern. Vielleicht ist >er mit der Funktion noch nicht durch, wenn er wieder auslöst. Ich hab den Systick so eingestellt das jede ms ein Interrupt kommen sollte (ist die Standardeinstellung im ST Bsp.). Das sollte doch auf keinen Fall zu schnell sein oder? Das mit den vielfachen von 4 kann ich nicht beurteilen, werde es mir mal anschauen. Ich finde nur komisch, das die Interrupts mit dem ST-Link funktionieren aber dieser bei größeren Code immer einen Absturtz des IAR EWA verursacht (beim laden des Codes auf den Controller). Sehr sehr seltsam.
So jetzt ist es so weit, es funktioniert! Also woran das Problem im Detail lag weis ich nicht. Auf jeden Fall habe ich mir den ST-LINK (V1) besorgt und mit IAR EW 6.1 zum laufen bekommen. Hier nochmal die Varianten die nicht funktionierten: Debug-Tool IAR EW Version Problem ------------------------------------------------------------------------ ---- Olimex ARM-USB-OCD 6.1 Interrupts funktionierten nicht ST-LINK/V2 6.1 IAR EW erkannte ST-Link/V2 nicht ST-LINK/V2 6.2 IAR EW hängte sich beim flashen immer auf ST-LINK 6.2 -"- ST-LINK 6.1 alles funktioniert wunderbar!! Wenn sich einer einen Reim daraus machen kann, kann er es gerne posten. Ich werden jetzt mit dieser Konfiguration weiter arbeiten. Danke an alle für ihre hilfreichen Posts!!
Thread beobachten
Seitenaufteilung abschaltenBitte 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.