Morgääääähn!
Habe einen kleinen Code geschrieben bei dem ein Interrupt gesetzt werden
soll. Allerdings scheint es so, als ob er nicht mehr resettet wird.
Als IDE verwende ich hierfür EMBlocks.
"main.c":
* @brief This function handles PPP interrupt request.
10
* @param None
11
* @retval None
12
*/
13
/*void PPP_IRQHandler(void)
14
{
15
}*/
16
17
/**
18
* @brief IRQ Line 15
19
*/
20
voidEXT15_10_IRQHandler(void)
21
{
22
if(EXTI_GetITStatus(EXTI_Line15)!=RESET)
23
{
24
GPIO_ToggleBits(GPIOD,GPIO_Pin_12);// PD12 LED On / Off
25
EXTI_ClearFlag(EXTI_Line15);// Clear IRQ Line 15
26
}
27
}
28
29
/************************ (C) COPYRIGHT STMicroelectronics *****END OF FILE****/
In meinem Startup-File ist dieser Handler auch drin.
Solange ich keine steigende Flanke an den GPIO PA15 schicke,
funktioniert alles wie es soll. Sobald aber die Flanke vorbeischaut
bleibt GPIO PD12, je nachdem ob PA0 auf High oder Low lag, in seiner
Stellung und meine while Schleife wird nicht mehr ausgeführt. Fühlt sich
für mich als Anhänger danach an, dass der IRQ nicht mehr resettet wird.
Weiß jemand Rat? Bestimmt beachte ich wieder irgendwas nicht.
Libe Grüße
Reggie
EDIT: Was mir auch noch nicht so klar ist: Der Compiler durchsucht alle
von mir angegebenen Dateien und Pfade nach den benötigten Funktionen /
Variablen? Oder woher holt er sich den Handler?
Reginald L. schrieb:> EDIT: Was mir auch noch nicht so klar ist: Der Compiler durchsucht alle> von mir angegebenen Dateien und Pfade nach den benötigten Funktionen /> Variablen? Oder woher holt er sich den Handler?
Der Name des Interrupt-Handlers sollte in der IVT (Interrupt Vector
Table) auftauchen. Ist das nicht der Fall, wird das wahrscheinlich in
einem HardFault enden. Ich hab dein Programm nicht darauf hin überprüft,
nur soviel dazu.
Im Normalfall macht kein Compiler irgendwas von allein sondern strikt
das, was man ihm sagt. Natürlich muss man seine Sprache sprechen, sonst
sind "Mißverständnisse" vorprogrammiert.
Hallo reggie,
sieht alles korrekt aus, bis mir auffiel, dass Du den Handler falsche
gschrieben hast: er heißt EXTI15_10_IRQHandler, bei Dir fehlt das I.
Dadurch wird nicht deiner, sondern der Default handler (in einem der
Startup files als weak definiert), aufgerufen und der geht in eine
Endlos while()-Schleife.
pitschu
Das soll laut Manual "EXTI15_10" sein. In der Startup-File steht das
zwar auch, aber angehängt ist daran "_IRQHANDLER", so wie in meinem
Script auch. Bei den ganzen Beispielen die ich durchforstet habe, ist
das Handler auch so angegeben wie bei mir. Warum das vom Manual
abweicht, verstehe ich nicht wirklich, da ich mich durch die Startup
Routinen noch nicht durchgelesen habe.
pitschu schrieb:> Hallo reggie,>> sieht alles korrekt aus, bis mir auffiel, dass Du den Handler falsche> gschrieben hast: er heißt EXTI15_10_IRQHandler, bei Dir fehlt das I.> Dadurch wird nicht deiner, sondern der Default handler (in einem der> Startup files als weak definiert), aufgerufen und der geht in eine> Endlos while()-Schleife.>> pitschu
Das Thema "Problematik" zur Error-Ausgabe, in Bezug auf die Interrupts,
habe ich schon im Internet gefunden. Daran habe ich schon gedacht. Vom
Denken allein ist der Code trotzdem nicht weitergelaufen.
pitschu, mein drittes Auge, vielen lieben Dank! Wieder was gelernt!
An alle Anderen auch ein liebes Dankeschön für eure Mühe :)
Neues Problem, in diesem Zusammenhang:
Meine Interrupts werden zwar korrekt ausgelöst, allerdings schleicht
sich von Zeit zu Zeit ein zusätzlicher Interrupt ein. Meine Vermutung
ist, dass mein IRQ-Handler nochmals zusätzlich ausgelöst wird, sobald
der Timer einmal durchgelaufen ist (der läuft wohl intern trotzdem bis
zum Schluss, obwohl ich ihn per TIM_SetCounter(TIM2, 0) resette?)
Versuche schon seit gestern, entweder den Timer komplett neu zu starten,
oder wenigstens den zusätzlichen Interrupt anderweitig zu unterbinden,
ohne Erfolg. Bisher habe ich mir mit einem if-Block weitergeholfen, kann
ja aber nicht die Lösung des Problems sein.
Immer noch STM32F4 Discovery, CrossWorks IDE
ich kenne das Phänomen, habe selbst schonmal damit gekämpft, wobei es
bei mir TIM6 war.
Das Problem sollte durch folgende Code-Änderung lösbar sein:
Setze das Interrupt Bit nicht am Ende der ISR zurück, sondern früher.
Ich setze es immer als erste Anweisung in der ISR zurück.
Folgender Hintergrund: (so erkläre ich mir das Phänomen)
Die Timer hängen an den langsamen APB1/2. Ein Registerzugriff ist
enstprechend langsam. Bis die Anweisung, das Bit zu löschen, im
Timerregister angekommen ist, kann der Prozessor schon deutlich weiter
sein. Bis dann auch der NVIC gemerkt hat, dass kein Interrupt mehr
ansteht, kann der Core bereits aus der ISR rausgesprungen sein und
springt daher direkt wieder rein.
Hehe, das wird nur noch schlimmer :)
Jetzt kommt der Interrupt, den ich eigentlich nicht haben mag, nur noch
öfters. Normalerweise bekomme ich Timerwerte zwischen 30k - 1M. Es
kommen aber immer wieder mal die Werte 0 und 1 vor. Wenn ich nun das
InterruptBit gleich zu Anfang der ISR zurücksetze, kommen diese nicht
gewollten Werte öfter, auch die 2 ist dann schon mal aufgetaucht. Die
Werte kommen dann auch nicht mehr alle 5s, sondern öfter. Ich steh aufm
Schlauch :>
EDIT: Achso, der gewollte Interrupt löst mit etwa 1-50Hz aus, also
zeitlich is da nicht viel los.
Thread beobachten
Seitenaufteilung abschalten