ESP32 woher kommen alle 5 Minuten DMA Probleme?

Überlauf einer Register? Kommt es denn genau alle 5 Minunten? Oder irgendwie 4,2? Könnte auch ein Watchdog sein der nicht bedient ist.

DMA und Cache? Wie ist der Cachecoherenz sichergestellt?

Debuggen? Gibt es für den ESP32 richtige debuggers mit breakpoints und so? Wenn ja dann ran an das Gerät und gucken was da so läuft.

Im Debugger sieht man nichts. Alles scheint richtig zu sein, ausser den Daten. Schade da du diese Frage stellst benutzt Du anschined nicht diesen Prozessor.

Alles was WD heist ist auf anderen Werten, außerdem würde der sich auch anders melden.

Tja ein Überlauf könnte zwar sein aber da müsste man erst mal was finden, in dem von mir zusammen gebauten Code ist jedenfalls nichts dergleichen drin. Und der Systemtimer ist da noch lange nicht übergelaufen.

DMA & Interrupts sind im IRAM gelegt damit mir kein Code laden rein funken kann.

Kann mir jemand sagen auf welchem Kern diese Funktionen laufen?

portENTER_CRITICAL ist der Feind!

Ich habe damit Zugriffe auf Ansammlungen von Globalen Variablen von einem Task durch einen 2. Task verhindert. Nachdem ich das nun einfach mal ausgeklammert habe läuft alles anscheined sauber (45min). Weitere Tests über mehrere Stunden muss ich noch machen.

Warum das überhaupt so kritisch ist könnte ich versuchen abzuklären, ist mir aber nicht wichtig genug. Unter einem AVR oder unter einem STM32 hatte ich jedenfalls noch nie so ein Problem gehabt, obwohl ich bei Projekten darauf portENTER_CRITICAL sehr viel öfter benutze.

Dirk E. schrieb:

portENTER_CRITICAL ist der Feind!

Vielleicht nimmst Du eher taskENTER_CRITICAL(). Siehe auch: Beitrag "Re: ESP32 Tasks portENTER_CRITICAL"

Laut https://www.freertos.org/taskENTER_CRITICAL_taskEXIT_CRITICAL.html scheint das auch das bessere Mittel zu sein.

Warum kein Mutex? Der ermöglicht es dem RTOS den wartenden Thread schlafen zu legen wenn gerade ein anderer Thread auf die Daten zugreift.

portENTER_CRITICAL ist auf ESP32 anscheinend ein Spinlock. D.h. ein Thread welcher gerade nicht zugreifen kann rotiert "sinnlos" in einer Endlosschleife, bis der andere Thread, welcher den Lock aquiriert hat, diesen wieder freigibt.

Bei Dual-Core (ESP32S3) wird so die Leistung eines Cores verschwendet, der auch andere Threads ausführen könnte.

Bei Singlecore wird der Timeslice des wartenden Threads verschwendet. Erst wenn der präemptive Scheduler (Round Robin) den wartenden Thread nach Ablaufen der Timeslice unterbricht und zum ersten Thread zurückwechselt kann dieser mit den Daten weiter arbeiten und den Spinlock wieder freigeben.

Da ist es natürlich kein Wunder dass es nicht gut läuft. Oder überseh ich was?

So ich habe nun etwas gelesen und mir einige meiner alten Projekte angesehen.

Das portENTER_CRITICAL in den alten Projekten ist auch falsch, da fällt es nur nicht auf weil da immer nur die SIO parallel per Interrupt läuft.

Jetzt mit der Kammera und den Interrupts dazu ist es halt einfacher zu treffen.

vTaskSuspendAll & xTaskResumeAll sind da wohl erstmal die bessere Wahl. Auch wenn xTaskResumeAll die Interrupts kurz abschaltet.

Mutex ist auch eine gute Möglichkeit, macht aber hier und da es auch komplizierter wie es sein müsste.

Am besten man blockiert nichts! Bis auf eine Stelle konnte ich das auch umbauen und dafür finde ich auch noch eine Lösung.

Dirk E. schrieb:

vTaskSuspendAll & xTaskResumeAll sind da wohl erstmal die bessere Wahl.

Espressif sagt dazu:

Given that scheduler suspension on ESP-IDF FreeRTOS will only suspend scheduling on a particular core, scheduler suspension is NOT a valid method ensuring mutual exclusion between tasks when accessing shared data. Users should use proper locking primitives such as mutexes or spinlocks if they require mutual exclusion.

Außerdem interferiert es mit Delay-Aufrufen auf der anderen CPU.

Dirk E. schrieb:

Mutex ist auch eine gute Möglichkeit, macht aber hier und da es auch komplizierter wie es sein müsste.

Mutexe sind halt das Mittel der Wahl unter einem (RT)OS. Den Scheduler anzuhalten ist die ziemliche Holzhammermethode. Außerdem gibt es natürlich noch Atomics und beim ESP-IDF ist auch ein sehr hilfreicher thread-sicherer Ringbuffer mitgeliefert.

Ein korrekt(!) mithilfe von Mutex, Semaphore, Atomics implementierter Code funktioniert automatisch korrekt und effizient(!) auf Single- und Multicore-Prozessoren, weil man mithilfe dieser Primitive dem Scheduler genau mitteilt, welche Code-Abschnitte parallel ablaufen dürfen und welche nicht. Der Scheduler kann somit immer Threads finden, welche parallel laufen dürfen, und diese auf die Cores verteilen. Wenn man einfach den Scheduler abwürgt existiert diese Information nicht, und es skaliert nicht.