PLS Programmierbare Logik & Systeme

Zehn Tipps für das Debugging

Mit zunehmender Komplexität der Mikrocontroller und Schaltungen gewinnt das Debuggen eine immer größere Bedeutung. Doch welche Diagnose- und Debug-Funktionen braucht man wirklich und was ist unnötig?

PLS 

Vollbild

Heiko Riessland, PLS: »Moderne Debugger sind heutzutage oft weit mehr als nur ein interaktives Werkzeug zur Fehlersuche.«

Schliessen

PLS

Heiko Riessland, PLS: »Moderne Debugger sind heutzutage oft weit mehr als nur ein interaktives Werkzeug zur Fehlersuche.«

Diesen Fragen sind wir nachgegangen und haben zusammen mit Heiko Riessland, Produktmanager von PLS Programmierbare Logik & Systeme zusammengestellt, worauf Anwender bei der Auswahl des passenden Debug-Tools achten sollten.

Tipp Nr. 1: Sparen Sie nicht bei der Debug-Schnittstelle

Die Debug-Schnittstelle erlaubt die Beobachtung von Hard- und Software sowie deren Zusammenspiel. Sie ist eine der wichtigsten Möglichkeiten, ein Mikrocontrollersystem nicht nur als Black Box zu testen. »Wann immer möglich, sollte ein System-on-Chip mit einer leistungsfähigen Diagnose-Schnittstelle ausgewählt und diese dann auch in der leistungsfähigsten Ausbaustufe auf der Hardware implementiert werden«, erklärt Heiko Riessland, Produktmanager von PLS. »Moderne Debug-Interfaces sind ebenso komplexe Baugruppen wie die funktionalen Peripherals, und sie verlangen die gleiche Aufmerksamkeit in der Leitungsführung bezüglich Stromversorgung, Taktfrequenz etc. Zur Kostenersparnis können Steckverbinder in der Serienhardware unbestückt bleiben. Im Platinenlayout sollte man sie aber möglichst immer vorsehen.«

Tipp Nr. 2: Brauche ich Trace?

»Zwingend ist ein Trace immer dann, wenn der Programmfluss oder die Änderung von Programmdaten lückenlos rekonstruiert werden muss, um die Ursache eines Problems zu finden«, so Riessland. »Aber auch sonst ist eine zusätzliche leistungsstarke Schnittstelle für Code- und/oder Daten-Trace absolut empfehlenswert, weil die Ergebnisse eines Trace nicht nur - wie fälschlicherweise oft angenommen - allein der Fehlersuche dienen, sondern auch eine solide Basis für das Debuggen auf Systemebene mit Funktionen wie Profiling, Code Coverage und Execution Sequence Diagram darstellen.« So ließen sich beispielsweise Performance-Engpässe in der Applikation aufspüren oder die Software nach bestimmten Normen zertifizieren. Ein entsprechend leistungsfähiges Debug-Werkzeug kann heutzutage auf Basis eines Code-Trace beispielsweise auch zuverlässige Statistiken über C0- und C1-Code-Coverage erstellen. C0 bewertet die Ausführungsabdeckung jeder Maschineninstruktion, C1 die jedes Entscheidungszweiges im Programmfluss.

Tipp Nr. 3: Nutzen Sie spezielle Emulation Devices

Für einige besonders leistungsfähige 16- und 32-Bit-Mikrocontroller wie die Automotive-SoCs der Familien XC2000 und TriCore von Infineon gibt es seit längerem spezielle, zum Serienchip 100-prozentig footprint-kompatible Emulation Devices, die neben dem Serienchip auch eine zusätzliche Debug- und Trace-Logik implementiert haben. »Nach heutigem Stand der Technik und aus eigener Erfahrung ist dies wohl der effizienteste Diagnose- und Debug-Ansatz, weil es de facto technisch immer schwieriger und aufwendiger wird, die in einem komplexen SoC intern anfallenden Datenmengen für Diagnosezwecke nach außen zu transportieren«, verdeutlicht Riessland. »Inzwischen zeichnet sich ab, dass wohl auch andere Hersteller diesem Ansatz folgen werden.« Steht ein entsprechendes Emulation Device zur Verfügung, sollten nach Überzeugung des Experten einige Prototypen einer neuen Hardware damit bestückt werden. Der überschaubare zusätzliche Aufwand in Hardware und unterstützende Tools mache sich meist schon bei der ersten Suche nach der Ursache eines komplexeren Fehlers bezahlt.

Tipp Nr. 4: Ein Bild sagt mehr als 1000 Zahlen

Um bei einer modernen SoC-Applikation den Überblick zu behalten, sollte das Debug-Tool eine Sicht auf das System in unterschiedlichen Abstraktionsstufen beinhalten. Dazu gehört auch die grafische Darstellung komplexer Zusammenhänge. Typische Beispiele hierfür sind die grafische Darstellung von Daten und Prozessgrößen im zeitlichen Verlauf und in Relation zueinander, Funktionslaufzeiten und Programmfluss. Dazu Riessland: »Gesetzt den Fall, es liegen von vier Prozessgrößen je 1000 Messwerte vor: Grafisch ist in der Regel schon auf den ersten Blick zumindest tendenziell eine Verlaufsbewertung möglich. Das reicht für eine erste schnelle Einschätzung der Situation, und für eine detaillierte Auswertung stehen dann immer noch die Messwerte parallel zur Grafik zur Verfügung.«

Tipp Nr. 5: Debugger - nur für die Fehlersuche viel zu schade

Ein bewährter Programmiergrundsatz lautet: Arbeite jeden neu geschriebenen Source-Code mindestens einmal im Debugger im Einzelschritt durch. »Nicht, dass dieser Leitsatz an Aktualität oder Sinn verloren hätte«, merkt Riessland an. »Aber moderne Debugger sind heutzutage oft weit mehr als nur ein interaktives Werkzeug zur Fehlersuche. Bei kleineren Projekten beispielsweise lassen sich mit einem skriptfähigen Debugger sogar Tests selber erstellen und automatisiert ausführen. Bei größeren Projekten kann der Debugger den Zugang zum und die Ablaufsteuerung auf dem Target bereitstellen und mit einem entsprechenden Tool zur Arbeit mit den Testfällen gekoppelt werden.« Wichtig sei nur, dass entsprechend leistungsfähige, idealerweise standardisierte nicht-proprietäre Schnittstellen zur Verfügung stünden, die es dem Entwickler erlauben, mit seinen Werkzeugen eigene optimierte Workflows zusammenzustellen oder die Tools in Frameworks wie Eclipse nahtlos einzubinden.

1. Teil: Zehn Tipps für das Debugging
2. Teil: Zehn Tipps für das Debugging

Weiterführende Links:

• Neue Debug-Schnittstellen: Guter Draht zum Target
• UDE 3.0 optimiert die Test- und Debug-Möglichkeiten des Cortex-M4-Cores: Test- und Debug-Tool für Kinetis-Mikrocontroller
• Safety und Energie-Effizienz sind die treibenden Faktoren: Fünf Trends kennzeichnen die Entwicklungssystembranche
• Schlüsselfertig integriert: Entwicklungswerkzeuge für ARM-Prozessoren
• PLS Programmierbare Logik & Systeme: PLS-Tools unterstützen TriCore 1.6
• Debug-Tool für kommende Infineon-MCUs: PLS: UDE 3.2.1 unterstützt neue Infineon-XMC4000-Mikrocontroller
• Neue Version der Universal Debug Engine (UDE): PLS: UDE 3.2 vereinfacht Multicore-Kontrolle