Was macht RTOS-Debug?
Übersicht
Nutzen Sie diese Fähigkeit, um RTOS-Probleme zu debuggen, indem Sie den Scheduler-Zustand, die Task-Stack-Gesundheit, Synchronisation, Interrupt-Priorität, Timing und Ressourcenbesitz analysieren. Beginnen Sie immer mit dem beobachtbaren RTOS-Zustand, bevor Sie Prioritäten ändern oder Verzögerungen einfügen.
Verwendung
Verwenden Sie diese Fähigkeit, wenn:
- Die Firmware FreeRTOS, RT-Thread, Zephyr, ThreadX, CMSIS-RTOS oder einen anderen eingebetteten Scheduler verwendet.
- Der Benutzer von Deadlock, Starvation, verpassten Ereignissen, Queue-Timeout, Stack-Überlauf, Watchdog-Reset, Prioritätsinversion oder nicht laufenden Tasks berichtet.
- Das Problem ISR-zu-Task-Signalisierung, Timer, Semaphoren, Mutexe, Message Queues oder Task-Benachrichtigungen betrifft.
Verwenden Sie diese Fähigkeit nicht, bevor nicht bestätigt ist, dass das Ziel bootet und zumindest etwas Firmware ausführt. Für RTOS-spezifische Tiefenanalysen bevorzugen Sie freertos-kernel-debug, zephyr-integration oder rt-thread-integration, sobald das RTOS identifiziert ist.
Erste Fragen
Fragen Sie nach:
- RTOS-Name/-Version und MCU/SoC.
- Symptom und wann es auftritt.
- Task-Liste mit Prioritäten, Stack-Größen und Hauptaufgaben.
- Ob Stack-Überlaufprüfung, Laufzeitstatistiken, Trace oder Thread-Awareness aktiviert sind.
- Beteiligte ISR-Quellen und Interrupt-Prioritäten.
- Logs, Asserts, Watchdog-Grund oder Debugger-Task-Ansicht.
Workflow
-
Bestätigen, dass der Scheduler startet. Überprüfen, ob das System den Scheduler-Start erreicht und mindestens eine bekannte Task läuft.
-
Task-Zustand erfassen. Task-Namen, Zustände, Prioritäten, Stack-High-Watermarks, CPU-/Laufzeitstatistiken und blockierte Objekte sammeln.
-
Zuerst Stack und Heap prüfen. Stack-Überlauf und Heap-Erschöpfung tarnen sich oft als zufällige RTOS-Fehler.
-
Synchronisation inspizieren. Identifizieren, welcher Task welchen Mutex besitzt, welche Queue voll/leer ist und ob ISR-sichere APIs aus Interrupts verwendet werden.
-
Interrupt-Prioritätsregeln prüfen. Sicherstellen, dass ISR-Prioritäten für RTOS-API-Aufrufe zulässig sind und den Scheduler-Tick nicht aushungern.
-
Vermutungen durch Sonden ersetzen. Trace-Hooks, Assertions, Wasserstände, Zähler oder Ereignisprotokolle verwenden, anstatt willkürliche Verzögerungen einzufügen.
Prüfungen
- Stack-High-Watermark für jede Task.
- Heap-frei/minimal je freier Speicher.
- Tick-Interrupt läuft mit erwarteter Rate.
- Watchdog-Überwachungstask wird nicht ausgehungert.
- Mutex-Besitz und rekursive/nicht-rekursive Fehlanpassung.
- Queue-Länge, Item-Größe, Sende-/Empfangs-Timeout.
- ISR verwendet korrekte
FromISR-APIs, wo erforderlich. - Kritische Abschnitte sind kurz und begrenzt.
- Prioritätsinversionsschutz vorhanden, wo gemeinsame Ressourcen genutzt werden.
Verifizierung
Bevor Sie Fortschritte im RTOS melden:
- RTOS, Scheduler-Status, Task-Zustände und Stack-/Heap-Nachweise angeben.
- Die blockierte oder ausgehungerte Task und das Objekt, auf das sie wartet, identifizieren.
- Angeben, ob Interrupt-Prioritäten für die RTOS-API-Nutzung zulässig sind.
- Alle Assertions-, Watchdog- oder Stack-Überlauf-Hook-Nachweise melden.
Häufige Fehler
- Task-Priorität erhöhen, ohne zu wissen, warum sie blockiert ist.
- Verzögerungen einfügen, um Race Conditions zu verstecken.
- Nicht-ISR-sichere APIs aus Interrupts aufrufen.
- Stack-High-Watermarks ignorieren.
- Queue-Payload debuggen, bevor Queue-Item-Größe und Besitz bestätigt sind.
Beispiel
Benutzer:
FreeRTOS hat eine Task, die gelegentlich nicht läuft, und schließlich erfolgt ein Watchdog-Reset.
Agent:
- Fragt nach Task-Liste, Prioritäten, Stack-Größen, Watchdog-Eigentümer und Task-Zuständen.
- Prüft High-Watermarks, Heap, Tick und blockierte Objekte.
- Überprüft ISR-Priorität und Queue-/Mutex-Besitz, bevor Prioritätsänderungen vorgeschlagen werden.