UART Receive Interrupt mit Freertos

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

Das kann auch FreeRTOS.

Na ich würde eher auf die Konfiguration ST wetten...Das einzige imho, das in Sachen Interrupte bei FreeRTOS sinnvoll konfigurierbar ist, ist der HAL Interrupt. Die Konfiguration sorgt dafür, das ein Interrupt ab Level X auch den Scheduler unterbrechen darf...Aber dafür darf in Interrupten über diesem konfigurierten Level keine FreeRTOS API verwendet werden.

Such mal nach: configMAX_SYSCALL_INTERRUPT_PRIORITY

Eros S. schrieb:

Ich vermute ein Problem bzw. eine falsch konfigurierte Interrupt Priorität.

Priorität spielt keine Rolle sofern nicht ein anderer Interrupt permanent alles blockiert.

Unterbrich das Programm mal im Debugger in dem Moment, in dem eigentlich der Interrupt kommen sollte. Wenn sich das Programm nicht in einem Interrupt Handler befindet und außerdem BASEPRI=0 und PRIMASK=0 (in der Registeransicht prüfen) sind, sollte der Interrupt auslösen, unabhängig von der Priorität.

Wenn er dennoch nicht auslöst, liegt der Fehler im Code.

Die Priorität des FreeRTOS ISR darf nicht "wichtiger" als die Priorität irgend eines anderen ISRs sein. Sonst kommt es dazu, dass der FreeRTOS ISR auf den anderen ISR genested wird. Und wenn dann der FreeRTOS Scheduler versucht die Task zu wechseln schaltet der falsch den drunter liegeneden ISR Stack um. Das erkennt der Cortex-M interessanterweise in Hardware und wirft eine Exception ich meine ein Usage Fault. Lässt sich in den Status Registern auch diagnostizieren, ob das der Fall ist.

Ist ein recht mieser Fehler, da das recht lange gut läuft, solange eben keine zwei ISRs gleichzeig auftreten.

Möchte man den FreeRTOS Scheduler wichtier als irgend einen unwichtigen ISR machen, müsste man mit Subprioritäten arbeiten. Leider unterstützt FreeRTOS diese jedoch nicht...

Malte _. schrieb:

Möchte man den FreeRTOS Scheduler wichtier als irgend einen unwichtigen ISR machen

... würde man die ISR einfach als Task implementieren und im IRQ Handler den Task starten / entblockieren. Sollte schnell genug gehen um das wichtige FreeRTOS Zeug nicht zu stören.

Niklas G. schrieb:

... würde man die ISR einfach als Task implementieren und im IRQ Handler den Task starten / entblockieren. Sollte schnell genug gehen um das wichtige FreeRTOS Zeug nicht zu stören.

Ich gebe zu mein Anwendungfall ist eine absolute Nische.

Der Threadstarter hat vermutlich auch ein anderes Problem. Wenn er glaubt sein ISR wird nicht ausgeführt, sollte er mal in das passende UART Pending Bit im NVIC schauen.

Malte _. schrieb:

Die Priorität des FreeRTOS ISR darf nicht "wichtiger" als die Priorität irgend eines anderen ISRs sein. Sonst kommt es dazu, dass der FreeRTOS ISR auf den anderen ISR genested wird. Und wenn dann der FreeRTOS Scheduler versucht die Task zu wechseln schaltet der falsch den drunter liegeneden ISR Stack um. Das erkennt der Cortex-M interessanterweise in Hardware und wirft eine Exception ich meine ein Usage Fault. Lässt sich in den Status Registern auch diagnostizieren, ob das der Fall ist.

Was ist denn mit Priorität freeRTOS gemeint? Der Systick? RTOS Tick darf sehr wohl interrupte unterbrechen. Hatte den von dir beschriebenen Fall so noch nie beobachtet in meinen Projekten.

Auf Cortex-M (M3/M4/M7):

Tasks laufen mit PSP (Process Stack Pointer)

ISRs laufen mit MSP (Main Stack Pointer)

Der Context Switch passiert über den PendSV-Handler (und oft SysTick für das Ticken).

FreeRTOS wechselt nur den PSP beim Taskwechsel, der MSP bleibt für alle Interrupts gleich. Deshalb ist es völlig okay, dass PendSV innerhalb anderer Interrupts läuft – das ist bewusst so designt.

Joe J. schrieb:

Was ist denn mit Priorität freeRTOS gemeint? Der Systick? RTOS Tick darf sehr wohl interrupte unterbrechen. Hatte den von dir beschriebenen Fall so noch nie beobachtet in meinen Projekten.

ok, du meinst den Scheduler kernel Interrupt.

Niklas G. schrieb:

Eros S. schrieb:

Ich vermute ein Problem bzw. eine falsch konfigurierte Interrupt Priorität.

Priorität spielt keine Rolle sofern nicht ein anderer Interrupt permanent alles blockiert.

Unterbrich das Programm mal im Debugger in dem Moment, in dem eigentlich der Interrupt kommen sollte. Wenn sich das Programm nicht in einem Interrupt Handler befindet und außerdem BASEPRI=0 und PRIMASK=0 (in der Registeransicht prüfen) sind, sollte der Interrupt auslösen, unabhängig von der Priorität.

Wenn er dennoch nicht auslöst, liegt der Fehler im Code.

Das dürfte schwierig werden. Der Interrupt soll ja ausgelöst werden, wenn über die UART Schnittstelle ein Zeichen empfangen wird. Genau DANN das Programm zu pausieren, wenn das Zeichen vermeintlich raus ist...

Die ISR funktioniert ja grundsätzlich, wenn FreeRTOS nicht konfiguriert wird. Auch dass generell Interrupts ja zu funktionieren scheinen, zeigt der PCINT, der ja funktioniert. Ein weiteres Indiz ist aber, dass die PWM Ansteuerung meiner RGB LEDs nicht mehr funktioniert, sobald FreeRTOS eingebunden wird. Ich vermute nach wie vor ein Problem bei der Konfiguration. An sich funktioniert der Code ja.

Eros S. schrieb:

Genau DANN das Programm zu pausieren, wenn das Zeichen vermeintlich raus ist...

Muss nicht genau dann sein, nur irgendwann danach. Der Interrupt sollte ja "pending" bleiben und nicht einfach "verpuffen".

Eros S. schrieb:

Ich vermute nach wie vor ein Problem bei der Konfiguration. An sich funktioniert der Code ja.

Lässt sich halt so nur schwer diagnostizieren. Debuggen ist auch nötig um Konfigurationsfehler zu finden. Mein Vorschlag mit dem Pausieren ist blitzschnell geprüft.