STM32F446 Interrupt Probleme

[Chris (christophe_d)]

Hi,

ich habe hier ein seltsames Problem mit einem STM32F446. Das Problem 
klingt irgendwie, als hätte ich was grundsätzliches übersehen, deswegen 
erst mal eine grobe Beschreibung:

Ich habe eine ISR, welche Daten vom SERCOM empfängt -> die funktioniert 
problemlos.

In meinem Main-Loop bearbeite ich diese Daten (entkoppelt über einen 
Ringbuffer) -> der Loop funktioniert nur so lange, wie die ISR nicht 
aufgerufen wird. So bald das passiert, bleibt der Mainloop an der Stelle 
stehen, an der sich die Ausführung beim Auftreten des Interrupts 
befunden hat.

Mein erster Verdacht: der Interrupt kommt zu oft und die ISR verbraucht 
zu viel Rechenzeit. Wenn ich allerdings, so bald das Problem aufgetreten 
ist, keine Daten mehr an den STM sende, so dass auch keine Interrupts 
mehr kommen, läuft der Mainloop trotzdem nicht weiter. Sprich es liegt 
offenbar nicht daran, dass ich den STM mit zu vielen IRQs totschieße.

Auch andersherum: wenn ich erst mal keine Daten sende, so dass kein 
Interrupt ausgelöst wird, so läuft der Mainloop problemlos. So bald aber 
auch nur ein einziger Interrupt eintrudelt, bleibt der Main-Loop wieder 
stehen.

Das passiert auch, wenn ich die Verarbeitung der ISR-Daten im Mainloop 
komplett rausnehme, so dass also keine logische Verbindung mehr zwischen 
ISR und Mainloop besteht. Heißt also dass auch kein Bug in der 
Verarbeitung der vom ISR empfangenen Daten die Ursache sein kann.

Was könnte ich hier übersehen haben? Muss ich irgend ein spezielles 
Interrupt-Register Setzen/Löschen, um wieder aus dem Interruptkontext 
herauszukommen?

Oder was sonst könnte die Ursache sein?

Danke!

[Wastl (hartundweichware)]

Chris schrieb:
> Ich habe eine ISR, welche Daten vom SERCOM empfängt

Ich habe das Reference Manual des STM32F446 stundenlang
durchgeackert und kein einziges Mal das Wort SERCOM gefunden.

Kann man SERCOM essen? Ist SERCOM gesund?

Chris schrieb:
> Oder was sonst könnte die Ursache sein?

Schreibe ein Minimal-Programm das dein Problem reproduzierbar
macht und poste hier das Projekt dazu. Sonst gibt's hier
grosses Rätselraten, Salamitaktik und Amusement dazu.

[Harry L. (mysth)]

Schau mal hier:
Beitrag "[STM32/HAL] simples U(S)ART-Library"

[Stefan F. (Gast)]

Chris schrieb:
> Muss ich irgend ein spezielles Interrupt-Register
> Setzen/Löschen, um wieder aus dem Interruptkontext
> herauszukommen?

Ich habe keine Erfahrung mit STM32F4, dafür aber mit F1 bis F3. Bei 
denen ist das so, dass man alle EXTI Interrupts im EXTI_PR Register 
bestätigen muss, sonst ruft er die ISR nach ihrem Ende sofort wieder 
auf. Man muss die Bestätigung sogar ein bisschen früher machen, als ganz 
am Ende der ISR.

http://stefanfrings.de/stm32/stm32f3.html#exti

Soweit ich auf die Schnelle sehen kann, ist das beim STM32F4 ebenso.

Zum Debuggen könntest du innerhalb der ISR ganz am Anfang einen I/O Pin 
aug HIGH setzen, und ganz am Ende auf LOW. Dann schaust du mit einem 
Oszilloskop nach, wie oft die ISR aufgerufen wird, wie lange sie läuft, 
und wie viel Zeit zwischen den Aufrufen verbleibt.

Zeige deinen Quelltext!

[Chris (christophe_d)]

Stefan F. schrieb:
> Ich habe keine Erfahrung mit STM32F4, dafür aber mit F1 bis F3. Bei
> denen ist das so, dass man alle EXTI Interrupts im EXTI_PR Register
> bestätigen muss, sonst ruft er die ISR nach ihrem Ende sofort wieder
> auf.

Danke, der Hinweis war entscheidend!

Tatsächlich wird der Receive-Interrupt beim Lesen des DR-Registers 
bereits bestätigt.

Was ich aber völlig übersehen habe: es gibt noch eine Latte anderer 
Interrupts. So tritt z.B. zuverlässig ein Overflow-Interrupt auf, wenn 
ich den Code im Debugger anhalte. Naja und wenn ich den Interrupt nicht 
zumindest zurücksetze, lande ich in exakt dem endlosen Interrupt-Loop, 
den du beschrieben hast.

Also: Danke :-)

[Ingo L. (corrtexx)]

Das ist leider so bei dem STM32, die setzen nicht wie man es vom AVR 
gewohnt ist, die Interrupt-Flags selber zurück, dass muss man immer 
selber machen.

[Wastl (hartundweichware)]

Ingo L. schrieb:
> Das ist leider so bei dem STM32, die setzen nicht wie man es vom AVR
> gewohnt ist, die Interrupt-Flags selber zurück, dass muss man immer
> selber machen.

Nö, du redest Käse. Bei den STM32 Controllern gibt es Interrupt
Flags die werden beim Lesen eines Registers automatisch gelöscht,
siehe USART RXNE Flag.