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