Erfassen der letzten Systemereignisse
Crash-Analyse ohne Gerätepark
Fortsetzung des Artikels von Teil 1
Mehr als Absturz-Analysen
Die Analyse der Aufnahmen mit SystemViewer zeigt in diesem Beispiel, dass die letzten Aktivitäten des Systems vom Überwachungs-Task durchgeführt wurden, der die Sensordaten verarbeitet. Wenn man den Weg weiter zurückverfolgt, gab es eine Anweisung an den Steuerungs-Task, dass das Heiz-System runtergefahren werden soll. Während dieser Task aktiv war, gab es einen Timer-Interrupt, der den Steuerungs-Task unterbricht und den Überwachungs-Task startet. Dieser versucht nun die Sensor-Daten zu lesen. Eine genauere Analyse ergibt, dass der Zugriff auf den Sensor einen Absturz verursachen kann, wenn das Heiz-System gerade herunterfährt. Für die Lösung bietet sich in diesem Fall an, den Zugriff auf den Sensor mit einer Resource-Semaphore zu sperren. Nach Implementierung dieser Änderung traten die Abstürze nicht mehr auf.
Der Post-Mortem-Modus eignet sich aber nicht nur für die Analyse von Abstürzen. Auch Systeme die offenbar ungestört operieren, können von der Analyse profitieren. In manchen Systemen lassen sich Effekte wie Differenzen in der Zeitmessung oder auch Memory Leaks beim Debuggen nicht identifizieren, können sich aber auf das Verhalten des Serienprodukts auswirken.
Auch hier ein Beispiel zur Verdeutlichung: Neben anderen Informationen zeigt das System die Betriebszeit an. Bei Langzeit-Tests stellt sich nach einigen Stunden eine Abweichung zu einer mitlaufenden Stoppuhr von 1 Minute ein. Beim regulären Debuggen lässt sich diese Abweichung nicht nachvollziehen, die Systemzeit wird ausgelesen und korrekt dargestellt. Das Problem erscheint nur, wenn das System über einen längeren Zeitraum läuft. Ein angeschlossener Debugger, der für einen Langzeit-Test mitläuft, kann das Systemverhalten so beeinflussen, dass die Abweichung nicht auftritt.
Mit dem Post-Mortem-Modus kommt man auch hier auf das Problem: Der Langzeittest wird nach Einfügen des SystemView-Moduls und Aktivierung des Post-Mortem-Modus erneut gestartet. Sobald die Zeit wieder abweicht, wird die Debug Probe wieder verbunden, und der SystemView-Buffer wird ausgelesen. Eine Analyse mit SystemView zeigt, dass ein Timer-Interrupt länger als eine Millisekunde läuft und damit jedesmal ein SysTick-Interrupt verloren geht. Dies wiederum bewirkt, dass die Systemzeit ebenfalls eine Millisekunde verliert und damit von der tatsächlichen Zeit abweicht. Um diesen Umstand zu beheben, wurde der Timer-Interrupt verschlankt. Teile des Timer-Interrupts, die nicht zeitkritisch waren, wurden in einen niederprioren Task verschoben.
Das Systemverhalten, die Zusammenhänge zwischen Tasks und Interrupts, sowie das Zeitverhalten von Interrupts und Tasks lassen sich einfach mit SystemView analysieren. Die Fähigkeiten, Systemverhalten zu verifizieren, das Zeitverhalten zu verbessern und unerwartetes Verhalten zu erkennen, sind ein wichtiger Bestandteil moderner Produktentwicklung und des störungsfreien Betriebs im Feld.
Jobangebote+ passend zum Thema
- Crash-Analyse ohne Gerätepark
- Mehr als Absturz-Analysen
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Open Flash Loader
Unterstützung von neuen Chips selbst programmieren
Systemanalyse
Blick unter die Haube
User Interface
Responsive Design – nicht nur für's Web
Sicherheitslücken aufdecken
Binäranalyse für ARM
