Fehlersuche und Diagnose¶
Beginnen Sie die Fehlersuche bei SF32 mit seriellen Protokollen. Je nach Chip, SDK-Version und Projektkonfiguration stehen zusätzlich Werkzeuge für Absturz-Dumps, Trace-Aufzeichnungen und eine RT-Thread-Shell zur Verfügung. Verwenden Sie nur Abläufe, die für die jeweilige Plattform dokumentiert sind.
Erste Diagnoseschritte¶
Verwenden Sie die serielle Konsole, um Folgendes zu erfassen:
- Startprotokolle.
- Anwendungsausgaben.
- Ausgaben der RT-Thread-Shell, sofern sie im Projekt aktiviert ist.
- Fehlermeldungen.
- Download- und Reset-Verhalten.
Bewahren Sie die Protokolle zusammen mit Board-Revision, SDK-Branch, Build-Befehl, Flash-Befehl und den seriellen Einstellungen auf.
Reihenfolge der Fehlersuche¶
- Reproduzieren Sie den Fehler mit derselben Firmware.
- Prüfen Sie, ob er nach einem Reset erneut auftritt.
- Prüfen Sie, ob er nach dem erneuten Flashen der vollständigen Firmware auftritt.
- Prüfen Sie, ob er auch mit dem ähnlichsten SDK-Beispiel auftritt.
- Fügen Sie Produktänderungen einzeln wieder hinzu.
So lassen sich Fehler in Hardware, Board-Support, Middleware und Anwendung voneinander unterscheiden.
Nützliche Werkzeuge¶
Tabelle: Nützliche Werkzeuge
| Werkzeug | Verwendung |
|---|---|
sftool |
Kommandozeilenwerkzeug für die serielle Schnittstelle mit unterstützten Flash-Lese-, Schreib- und Löschvorgängen sowie Reset; die Optionen hängen von Chip und Speicher ab. |
SiFli_Trace |
Board-Protokolle mit dem für das Ziel unterstützten Ablauf erfassen und prüfen. |
UsartServer |
Erforderliches Hilfswerkzeug für das dokumentierte UART-Debugging über die integrierte Debug-IP bei SF32LB52X und SF32LB56X; nicht pauschal auf andere Zielplattformen übertragen. |
AssertDump und Crash-Dump-Werkzeuge |
Nur verwenden, wenn sie für Chip und SDK-Version bereitgestellt werden; das dazugehörige dokumentierte Erfassungs- und Analyseverfahren befolgen. |
| RT-Thread-Shell | Laufzeitprüfung und Befehle nur dann, wenn die Projektkonfiguration die Shell aktiviert. |
Was zuerst zu prüfen ist¶
Tabelle: Was zuerst zu prüfen ist
| Symptom | Erste Prüfungen |
|---|---|
| HardFault oder Assert | Stackgröße, Nullzeiger, DMA-Puffer und Cache-Wartung. |
| Peripheriegerät reagiert nicht | Pin-Mux, Takt, Versorgungsschiene, Boardname, Treiberaktivierung. |
| Bluetooth instabil | RF-Takt, Antennenpfad, Bluetooth-Stack-Konfiguration, Verbindungsparameter. |
| Bildfehler auf dem Display | Panel-Timing, Pufferformat und Cache-/DMA-Synchronisation. |
| Zufälliger Neustart | Watchdog, Versorgungsschiene, Brownout und Stack-Überlauf. |
Checkliste für Absturzberichte¶
Geben Sie in einem Absturzbericht Folgendes an:
- Board und Revision.
- Chipvariante.
- SDK-Branch oder -Commit.
- Exaktes Beispiel oder Projekt.
- Build-Befehl und Boardname.
- Flash-Befehl.
- Serielles Startprotokoll ab dem Reset.
- Absturz-Dump oder Assert-Ausgabe.
- Ob sich das Problem mit einem unveränderten SDK-Beispiel reproduzieren lässt.
Zuletzt aktualisiert: