Debugging von Embedded Systemen oder vom Smoke Test zum printf() Debugging

Transkript

1 Debugging von Embedded Systemen oder vom Smoke Test zum printf() Debugging Ich muss gestehen, dass meine ersten Kontakte im Bereich Debugging für Microcontroller Systeme sehr primitiv ausgesehen haben. Dieses geschah während des Studiums auf Basis eines 80c535 von der Firma Siemens. Die Hardware hatte ich, mit einer selbstgeätzten Platine aufgebaut, nach einer Vorlage aus dem Institut für Kolbenmaschinen an der UNI Hannover. Ein schnell geschriebenes minimales Assemblerprogramm war ins EPROM gebrannt. Jetzt kam der spannende Augenblick. Ich würde das erste Mal die Versorgungsspannung anklemmen. Als gelernter Lötmuckel (So nannten mich die Maschinenbauer am Institut aufgrund meiner vorherigen Radio- und Fernsehtechniker-Ausbildung) hatte ich eine geschulte Nase für sich gerade verabschiedende Bauteile. Mit diesem Messinstrument dicht über der Hardware, bereit die Spannungsversorgung sofort wieder zu trennen wartete ich was passierte,... und es passierte nichts. Tage später hatte ich das LCD Display am Laufen und die Qualität des Debugging hatte einen ungeahnten Komfort erreicht, vom Smoke Test zum printf() Debugging. Als ich einige Jahre später bei der Firma Tasking als Support-Ingenieur anfing und den damals für die 8051 Familie angebotenen X-Ray Debugger von der Firma Microtec zum ersten Mal gesehen habe, der einen Philips Emulator steuerte, war das schon ein beeindruckendes Erlebnis. HLL Debugging vom Feinsten für Embedded Systeme, Debugging von Embedded Systemen Seite 1 von 1

2 damals noch für die Sprache PLM/51. Ansehen von Variablen und Speicher, Setzen von Breakpoints, Single Step auf Hochsprachenzeilen... Es hat dann noch eine ganze Weile gedauert, bis ich für die Emulationssysteme der Firma Hewlett Packard zuständig war und ich in die tiefste Programmierung der Analyser dieser damals übermächtigen Systeme eingeweiht wurde. Was ich damals bereits feststellte: nur ganz wenige Anwender nutzten das volle Leistungsspektrum dieser mächtigen Systeme aus. Nur wenige Entwickler beherrschten die komplexe Programmierung der Analyser und im Prinzip wurden nur wenige Basis-Funktionen der Emulatoren genutzt. Diese Basisfunktionen schöpften oft nicht einmal die Echtzeitmöglichkeiten aus. Wieder einige Jahre später und die ersten Monitor- basierenden Lösungen wurden mit ebenso eleganten Bedienoberflächen versehen wie sie zuvor nur von Emulatoren bekannt waren, und sie boten genau die Basisfunktionalität, die von den meissten Emulator-Benutzern genutzt wurde. Diese Lösungen sind heute die meist eingesetzten Debugger. Nicht so komplex zu bedienen wie ein Emulator, preislich sehr attraktiv, auf eigener HW einsetzbar, bieten sie eine Menge für Ihr Geld. Welche Vorraussetzungen werden für den Einsatz dieser preislich so verlockenden Lösung benötigt? Wo sind die Einschränkungen, und wann komme ich doch um einen Emulator nicht herum, das ist einer der Hauptinhalte dieses Artikels. Weiterhin geht es um Debugging Möglichkeiten, wenn höhere Abstraktions-Ebenen zur Softwareentwicklung eingesetzt werden, zum Beispiel C++, Echtzeitbetriebssysteme oder CASE Tools. Wie kann dann das Debugging aussehen. Ich werde auch einige Auswahlkriterien ansprechen, deren Auswirkungen bei einer einfachen Evaluierung schnell übersehen werden, aber im Verlauf des Projektes zum echten Ärgernis werden können. Zu guter letzt wird noch ein Ausblick über die Systeme gegeben, die in der Zukunft zu erwarten sind. Das alles wird stellvertretend an der für die Infineon C166 (ST10) Familie zur Verfügung stehenden Toollandschaft erläutert. Welche Lösungen zum Debugging bietet der Markt? Zwischen Smoke Test und Emulator liegen eine Reihe von Möglichkeiten. Simulatoren. Die ersten Schritte in der Softwareentwicklung fallen am leichtesten mit einem Simulator, Simulatoren werden heute in der Regel kostenlos mit den Compilern geliefert. Sie haben den Vorteil, dass ich mein erstes Programm auch ohne jegliche Hardware und auch ohne Kenntnisse darüber schnell zum Laufen bekomme. Das ist aber auch gleich der grösste Nachteile dieser Lösungen: mit ihnen kann ich mein Programm nicht auf einer realen Hardware laufen lassen, und das ist letztendlich ja das Ziel einer jeden Softwareentwicklung. Und nicht selten treten Probleme gerade in Verbindung mit der realen Hardware und den Schnittstellen zur Außenwelt auf. Emulatoren Die aus der Vergangenheit wohl meist bekannte Lösung sind die Emulatoren. Mit ihnen lassen sich die Programme auf nahezu jede Hardware laden, und dort ausführen. Mit Ihrer Hilfe bekommen Sie Informationen über den Status Ihrer Programmausführung, nahezu ohne diese selber zu beeinflussen, aber Sie haben auch einen immer grösser werdenden Nachteil, die Adaption auf das Zielsystem. Sie sind die teuersten Debugging Lösungen und auch die technisch anspruchvollsten. Gute Emulatoren bieten heute enorme Möglichkeiten, selbst den vertracktesten Fehlern auf die Schliche zu kommen, und sie wollen auch bedient werden, was in manchen Situationen sehr hohe Kenntnisse in jeglicher Hinsicht voraussetzt. Ohne genügend Kenntnisse hilft ein noch so teurer Emulator letztendlich auch nicht weiter. Debugging von Embedded Systemen Seite 2 von 2

3 Monitor- basierende Debugger Und seit einigen Jahren gibt es nun sehr komfortable Debugger, die es auch ermöglichen die Programme auf dem eigenen Zielsystem auszuführen, jedoch nicht ohne jegliche Beeinflussung und um diese wird es in dem kommenden Kapitel gehen. Sie stellen einen guten Kompromiss zwischen den Simulatoren und den Emulatoren dar. Die Bedienung ist einfach und inzwischen gibt es auch mit diesen Systemen beeindruckende Möglichkeiten, wenn auch nicht ganz so ausgefeilt wie bei Emulatoren. Auch diese Einschränkungen werden im kommenden Kapitel genauer erläutert. Monitor- Lösungen Technische Voraussetzungen Grundsätzlich werden für den Einsatz eines Monitors einige technische Voraussetzungen erwartet. Sie beanspruchen eine Schnittstelle von Ihrer Hardware (auf der der Monitor läuft), zum PC (auf dem der eigentliche Debugger läuft). Weiterhin steht Ihnen nicht wie beim Emulator Emulationsspeicher zur Verfügung, das bedeutet sie benötigen exakt so viel RAM, das Ihr gesamtes Programm einschliesslich aller Variablen darin Platz findet. Und zu guter letzt benötigen Sie noch einige KByte zusätzliches RAM oder besser ROM um den Monitor selber unterzubringen. Wenn Sie diese Voraussetzungen haben, können wir uns nun die Details genauer anschauen. Schnittstelle Die Standard- Schnittstelle, die in der C166 Familie zum Debuggen benutzt wird, ist die ASC0 (RS232). Diese besitzt einen sogenannten Bootstraploader, mit dessen Hilfe nach dem Reset sehr einfach kleine Programme in den Speicher geladen werden können. Dessen bedienen sich die Hersteller von Debuggern um den Monitor zuerst einmal auf das Zielsystem zu laden. Dieses Vorgehen finden Sie typischerweise bei den Evaluierungslösungen, die am Markt angeboten werden, z.b. bei den Infineon Starter Pack's. So lange wie Sie bei diesen Eva Boards bleiben und nur kleine Programme laden, ist das eine ideale Lösung. Oft kommt es jedoch vor, dass bei der eigenen Applikation die ASC0 (RS232) für eigene Belange benötigt wird und dann zum Debugging nicht mehr zur Verfügung steht. Aber hier waren die Toolhersteller erfinderisch. Inzwischen gibt es Möglichkeiten andere Schnittstellen einzusetzen, z.b. (wenn vorhanden) der CAN Bus, die SSC oder einfach 2 oder 3 Pins von einem Port, über den dann eine Schnittstelle nachgebildet wird. So schön diese Lösungen auch alle sind, wenn sie benutzt werden, steht der BSL nicht mehr zur Verfügung. Das bedeutet eine weitere Anforderung an den Speicher. In diesem Fall benötigen Sie auf jeden Fall ROM (oder FLASH), um den Monitor darin resistent zu speichern. Zur Evaluierung werden auch Lösungen angeboten, die ohne diesen Speicher auskommen, aber das Handling ist nicht gerade komfortabel. Dazu wird das System zuerst über die ASC0 gebootet, dann werden die Schnittstellen umgesteckt, Applikation auf ASC0 und Debugger auf Ihre Debugging Schnittstelle, was immer Sie gewählt haben und erst dann kann der Debugger starten. Lediglich die Firma pls bietet mit Ihrer Lösung eine Hardware, die gleich die verschiedenen Schnittstellen (CAN, SSC, 3Pin auf RS232) bereitstellt und das Umstecken der Schnittstellen für Sie erledigt. Bei dieser Lösung können Sie auch wenn kein ROM zur Verfügung steht, den BSL nutzen, ohne nach jedem Reset wieder die Umsteckaktion zu starten. Der Zustand, das kein ROM auf dem Zielsystem zur Verfügung steht tritt übrigens häufiger auf als oft vermutet. Zum Beispiel wenn Ihre Hardware nicht genügend RAM hat, um die gesamte Applikation zu laden. Dann gäbe es die Lösung in einigen Prototypen- Boards der ROM Baustein durch einen RAM Baustein zu ersetzt, Debugging von Embedded Systemen Seite 3 von 3

4 nun hätten Sie genügend RAM aber kein ROM mehr zur Verfügung. Im folgenden gehe ich noch einmal genauer darauf ein. Lade-Geschwindigkeit und Projektgrösse Es gibt ein weiteres Kriterium zur Auswahl einer geeigneten Schnittstelle. Was bei Evaluierungen häufig nicht auffällt sind, die Downloadzeiten. Über die ASC0 mit einer Baudrate von 56 KBit/sec (Das ist typisch für die meisten Systeme) dauert das Laden von 100 KByte ca. 22 Sekunden. Was bei kleinen Beispiel-Applikationen mit wenigen KByte Grösse nur wenige Sekunden dauert und nicht unangenehm auffällt, kann bei einem ausgewachsenen Projekt mit 256 KByte schon im Minutenbereich liegen und bei 500 KByte kann diese Zeit nicht einmal sinnvoll mit dem Holen einer Tasse Kaffee überbrückt werden, da können Sie auf dem Flur auch noch einen kleinen Plausch mit der Sekretärin des Chefs machen. Was sagen Sie, Ihr Chef hat gar keine Sekretärin, na ja dann gebe ich Ihnen Recht, diese Zeiten sind nicht mehr spaßig. Übrigens: dazu kommen noch die Interpretationszeiten für die Symbolik. Dazu habe ich noch etwas zu sagen. Starker Druck auf die Compiler- Hersteller bezüglich der Laufzeiten der Compiler haben dazu geführt, dass diese die Symbolik aller Include Files einfach ablegen, ohne zu überprüfen, ob Symbole x-fach abgelegt werden. Diese Arbeit muss jetzt jedoch der Debugger tun und das hat dazu geführt, dass die Interpretation der Symbolik schon beachtliche Zeit in Anspruch nehmen kann. Wenn Sie erwarten, dass Ihr Code grössere Dimensionen annimmt, lohnt sich auch hier ein genauerer Blick auf die Tools. Einige Hersteller haben hier Gehirnschmalz investiert und neue Konzepte realisiert. Z. B. wird beim Start des Debuggers nicht sofort die gesamte Symbolik interpretiert, sondern nur die globalen Symbole, und die lokalen Symbole des main() Modules. Erst wenn Sie in einen neuen Gültigkeitsbereich steppen, wird die nun gültige Symbolik interpretiert. Da das Debugging oft nur in Teilbereichen der gesamten Software stattfindet, erspart diese Vorgehensweise die Interpretation von Symbolen, die nicht benötigt werden. Aber kommen wir noch einmal zu den Downloadzeiten der verschiedenen Schnittstellen zurück. Bei Programmen im Bereich über 256 KByte rate ich auf jeden Fall zu einer schnelleren Alternative, z.b. CAN Bus oder SSC. Download des Codes und Interpretation der Symbole zusammen gerechnet, liegen die Unterschiede verschiedener Lösungen für ein 256 KByte großes Codesegment zwischen einigen Sec. und einigen Minuten. Da lohnt sich ein Vergleich. Speicher Einige Applikationen haben lediglich externen FLASH Speicher geplant. Aus dem bereits angesprochenen Grund des fehlenden Emulationsspeichers lassen sich auf den ersten Blick damit Monitor- Lösungen nicht einsetzen. Nun gibt es aber die Möglichkeit, FLASH Bausteine gegen pin-kompatible RAM Bausteine auszutauschen. Damit können Sie sich einige Prototypen Boards mit eigenem Emulationsspeicher ausstatten, dann sind auch hier Monitore einsetzbar. Die wichtigsten Einschränkungen von Monitor- Debuggern Wenn Sie eine Single Chip Anwendung (gar keinen externen Speicher) planen, dann würde ich Ihnen grundsätzlich zu Emulatoren raten. Weiterhin, wenn Sie auch während des Debuggings harte Echtzeitanforderungen haben, weil Ihre Applikation ansonsten nicht sinnvoll reagiert, sollte minderst ein Emulator zur Verfügung stehen. Wenn Sie alte Software debuggen müssen, in der viele Prozesse ineinander greifen, diese auch noch auf globalen Speicher zugreifen, dann ist es häufig notwendig, auf Variablen Zugriffe zu Debugging von Embedded Systemen Seite 4 von 4

5 triggern. Das ist nur mit Emulator und deren Analyser möglich. (Dazu mehr im folgenden Kapitel Debuggen mit Emulatoren ) Letztendlich, wenn Sie aufzeichnen möchten, wie Ihr Programm real abgelaufen ist (Trace), dann ist das nur mit einem Emulator mit Trace Option möglich. Besonderheiten Monitor Varianten Es gibt zwei grundlegende Arbeitsweisen von Monitoren. 1. Pollend, 2. Interrupt basierend. Wie immer im Leben haben beide Arbeitsweisen Vor- und Nachteile. Am weitesten verbreitet ist der auf Interruptbasis arbeitende Monitor. Bei dieser Variante liegt der Monitor irgendwo versteckt im Hintergrund und schlummert vor sich hin. Nur wenn der Benutzer eine Information über den Status seines Programmes haben möchte, wird der Monitor aufgeweckt, das geschieht in der Regel durch einen externen Interrupt oder durch das Setzen von Breakpoints. Er unterbricht dann das eigentliche User Programm und übernimmt die Kontrolle über den Prozessor. Nun können Speicherinhalte angesehen werden, neue Breakpoints gesetzt werden u.s.w. Danach wird das Programm wieder gestartet und der Monitor legt sich wieder schlafen. Der Hauptvorteil dieser Variante: Wenn der Monitor nicht benötigt wird, läuft das User Programm ohne jegliche Beeinflussung in voller Echtzeit. Diese Eigenschaft erlaubt den permanenten Verbleib des Monitors im Produkt, dadurch kann er jeder Zeit für Service Zwecke und z.b. für Software Updates genutzt werden. Bei der Pollenden Variante wird der Monitor einem Timer Interrupt zugewiesen und in zyklischen Abständen aktiviert. Vorteil: sie bekommen laufend Informationen über Ihr System. Nachteil: das User Programm wird permanent beeinflusst. Echtzeit- Ausführung ist nicht möglich. Diese Art von Monitor Systemen eignet sich dadurch nicht für den Verbleib im Produkt für evtl. Service Zwecke. Service und Diagnose, Software Update Wie bereits angesprochen, werden die Monitor Lösungen zunehmend auch in übergreifenden Bereichen eingesetzt, die im eigentlichen Sinn nichts mit Debugging zu tun haben. Zum Beispiel Softwaretest, Hardwaretest, Inbetriebnahme, FLASH Programmierung, Diagnose, Fernwartung, Softwareupdate, Parametrisierung. Für die meisten dieser Bereiche wird der Monitor zum festen Bestandteil der eigentlichen Applikation. Dort schlummert er vor sich hin und kann im Bedarfsfall über einen verborgenen Mechanismus aktiviert werden. Als erste Lösung unterstützt die UDE der Firma pls genau diese Einsatzgebiete explizit. Die UDE ist dafür ausgelegt, dass das Benutzer Frontend vom Monitor (inclusive den Kommunikationsmechanismen vom PC zum Target) entkoppelt werden kann. Die Schnittstelle zwischen dem Monitor und dem eigentlichen Bedienfrontend unterstützt Standard Mechanismen wie HTML, Microsoft COM oder ganz einfach Schnittstellen zu EXEL, MS Visual C++ und Visual Basic und Java. Das ermöglicht einfache Parametrisierung von Systemen mit Hilfe von MS Exel oder die Entwicklung eines eigenen Frontends auf Basis von Visual C++ speziell für Service Zwecke. Dabei muss das Rad nicht ein zweites Mal erfunden werden, alle Mechanismen in Bezug auf das Target, die einem Debugger zur Verfügung stehen, stehen auch für diese Frontends zur Verfügung und müssen nicht selber programmiert werden. Das sind zum Beispiel Lesen und Debugging von Embedded Systemen Seite 5 von 5

6 Schreiben von Target Speicher, Programmieren von FLASH Speicher, CAN Monitor Funktionen, Sichern und Wiederherstellen von Programm Status u.s.w.. Debuggen mit Emulatoren Glücklich sind die, die genügend Budget ( ,- Euro) für Emulatoren eingeräumt bekommen und sogar noch eine Schulung zur Bedienung obendrauf. Dann haben Sie heute ungeahnte Möglichkeiten. Angefangen beim Verfolgen von komplexen Programmabläufen mit den Analysern, über Performance bis hin zur Coverage-Analyse ist nahezu alles möglich- Sie müssen nur tief genug in die Tasche greifen. Die Frage ist was davon ist alles sinnvoll? Einer der meisteingesetzten Emulatoren für die C166/ST10 Familie, ist die D-Probe von der Firma Hitex. Dieser Emulator, aber auch die vergleichbaren Modelle in dieser Preisklasse z. B. von Nohau bieten ein sehr gutes Preis- Leistungsverhältnis. Analyser mit zwei Ebenen (mehr Ebenen sind schwer zu überblicken), Zeitmessungen, Emulationsspeicher mit Dual Ported oder Shadow Memory versetzt Sie in die Lage, Variableninhalte jederzeit zu beobachten, ohne Ihre Applikation anzuhalten. Zugriffe auf alle Busse können getriggert und im Trace Speicher aufgezeichnet und wieder auf die Hochsprachenebene transformiert werden. Filter für den Trace sind heute Stand der Technik, damit können die wesentlichen Informationen über mehrere Stunden oder sogar Tage aufgezeichnet werden, zum Beispiel bei schwer reproduzierbaren Fehlern. Mapping von Emulationsspeicher in kleinen Blöcken und die Verfolgung von ausgeführtem Code auf HLL ebene mit Coverage Analyse sind kein Problem. Das wohl wichtigste Kriterium, die absoluten Echtzeit, gegenüber den Monitor-Lösungen wird durch die Bond-Out Technologie ermöglicht. Alle wichtigen Busse, auch die internen, können vom Analyser überwacht werden, damit ist auch Trigger und Trace auf interne Ereignisse (vor allem Register) möglich. Aber wann benötigen Sie all diese schönen Funktionen? Im wesentlichen wird der Emulator in 5 Situationen benötigt. 1. Sie haben eine Single Chip Applikation ohne externen Speicher. Dann fehlt Ihnen wie bereits im vorherigen Kapitel angesprochen, eine Möglichkeit die Software in Ihr Zielsystem zu laden. Im Grunde genommen benötigen Sie dann lediglich den sogenannten Emulationsspeicher. Diesen können Sie über das interne ROM mappen und dann Ihre Software dort hineinladen und darin laufen lassen. 2. Sie benötigen auch während des Debugging absolute Echtzeitanforderungen. Dann werden Sie um einen Emulator ebenfalls nicht herum kommen. 3. Wenn Ihre Hardware gerade frisch aus dem Schwalllötbad kommt, und Sie das erste Mal Ihre Software darauf testen wollen. Immer wenn Hardware und Softwareintegration stattfindet und Fehler auch auf der Hardware möglich sind, dann ist ein Emulator oft hilfreich, zumal Sie bei einer fehlerhaften Hardware eventuell den Monitor gar nicht zum Laufen bekommen würden. Dieser Zustand tritt jedoch nur sehr kurz zu Anfang des Projektes auf, und rechtfertigt nicht immer die Anschaffung eines Emulators. In vielen Fällen können die Fehler der Hardware auch mit andern Mitteln gefunden werden. Debugging von Embedded Systemen Seite 6 von 6

7 4. Dieses ist wahrscheinlich der häufigste Grund dafür, dass Emulatoren angeschafft werden. Die Software ist in die Tage gekommen, es sind Strukturen entstanden, die komplexe Fehler hervorbringen, die ohne Analyser nur schwer zu finden sind. 5. Sie haben die Grenze der Performance Ihres Mikrocontrollers erreicht, und müssen optimieren. In diesem Fall hilft Ihnen die Performance Analyse Funktion eines Emulators weiter. Mit ihr können Sie sehr viel einfacher die Stellen herausfinden, an denen sich der Ansatz zur Optimierung wirklich lohnt. Das Haupteinsatzgebiet von Emulatoren Aber ich möchte noch einmal auf den Punkt 4 zu sprechen kommen. Einer der häufigsten Situationen, in denen Emulatoren wirklich hilfreich sind, jedoch auch gleichzeitig Situationen, die zukünftig vermeidbar sind. Dafür möchte ich einen kurzen Blick darauf werfen, wie die Basis Struktur der Software, die in den vergangenen Jahren entwickelt wurde, üblicherweise aussieht und wie sich diese Software typischerweise entwickelt hat. Die meisten Applikationen, die ich bei unseren Kunden antreffe, sind folgendermaßen aufgebaut. Zum einen gibt es eine main() Loop. In dieser Loop werden Funktionen aufgerufen, die regelmäßig, jedoch nicht in einem festen Zeitraster oder mit hoher Zeitanforderung, ausgeführt werden müssen. Abfrage von Sensorik, einfache MMI's... Zum anderen gibt es die Interrupt-Ebene, auf der die Funktionen ausgeführt werden, an die hohe Echtzeit-Anforderungen gestellt werden, oder die in einem sehr engen Zeitraster ausgeführt werden müssen. Ich nenne diese beiden Ebenen Vor- und Hintergrund-Ebene, sie unterscheiden sich im wesentlichen durch unterschiedliche Prioritäten. Diese beiden Prioritäts-Ebenen müssen in der Regel miteinander kommunizieren, und das geschieht über gemeinsame Datenbereiche (Globale Daten). So weit so gut, funktioniert der Ablauf der Software bei kleinen überschaubaren Systemen zufriedenstellend. Aber Systeme haben die Eigenschaft zu wachsen. Und so werden immer mehr Funktionen in die main() Loop gepackt, diese wird immer langsamer und irgendwann zu langsam für einige der Funktionen. Aber das ist kein Problem, denn da gibt es ja noch die Timer. Damit kann eine weitere Ebene realisiert werden, in der diese Funktionen aufgerufen werden, per Timer-Interrupt. Und jetzt fangen die Probleme langsam an. Diese Funktionen können auf einmal die Funktionen in der main() Loop unterbrechen, greifen aber evtl. auf die gleichen Daten zu. Das ist bei der ursprünglichen Entwicklung nicht geplant gewesen. Was vorher kein Problem war, weil alles sequentiell nacheinander ablief, führt auf einmal zu Fehlern. Jetzt werden Verriegelungsmechanismen eingeführt (Semaphore oder Flags) um Korruptionen auf der Datenebene zu verhindern. Verstehen Sie was passiert? Die Zeitanforderung erfordert eine Änderung auf der funktionalen Ebene. Diese Änderung hat aber wiederum Auswirkungen auf der Datenebene. Diese müssen durch Verriegelungs-Mechanismen auf der Zeitebene ausgeglichen werden und da ist das Dilemma, das System wächst und gedeiht, ist nun aber leider nur noch von den wenigen Experten im Team zu beherrschen oder vielleicht gedeiht es gar nicht mehr, sondern wird eher zum Problem. Genau an dieser Stelle helfen Ihnen typischerweise Emulatoren mit Ihren Trigger und Trace Möglichkeiten. Da können Sie auf allen Ablaufebenen Triggern, z.b. auf die Zugriffe von Variabeln und sich diese aufzeichnen lassen, und sehen welche Progammteile wann zugreifen, und welche Ebene gerade hakt. Das hilft Ihnen die zu komplex gewordenen Abläufe mit all Ihren Abhängigkeiten und Verriegelungen nachzuvollziehen und das Fehlverhalten einzukreisen. Das Reproduzieren und Suchen derartiger Fehler ist oft sehr zeitaufwendig und kann unter Debugging von Embedded Systemen Seite 7 von 7

8 Umständen mehrere Tage oder sogar Wochen in Anspruch nehmen. Hier können sich Emulatoren schnell amortisieren. Eigentlich müsste die Software jetzt komplett neu strukturiert werden, aber das ist oft nicht mehr rentabel und in dieser Situation leisten Emulatoren wirklich hervorragende Dienste und helfen die Software noch einige Zeit mit vertretbarem Aufwand weiter am Leben zu halten. Jedoch sollten Sie sich dabei bewusst sein, dass sie hier Feuer löschen. Beim Start von neuen Projekten ist es sinnvoll, neben der Investition in einen Emulator, also symbolisch betrachtet in die Feuerwehr, vor allem auch oder sogar vorerst einmal nur in Feuerschutz Maßnahmen zu investieren, z.b. in OOP. Wenn dieses Projekt dann wieder in die Tage gekommen ist, werden dann Emulatoren wieder wichtiger. Heute wissen wir, wie Strukturen aufgebaut werden müssen, die auch bei höherer Komplexität noch beherrschbar bleiben. In erster Linie geschieht dieses durch die Kapselung der Funktionseinheiten über Schnittstellen, die nur auf einer Ebene liegen. Grundsätzlich gibt es 4 Ebenen, die Zeitliche, die Funktionale, die Daten und die Prioritäts-Ebene. Software wird immer dann schwer zu beherrschen, wenn Schnittstellen zwischen Funktionseinheiten Abhängigkeiten auf mehreren dieser Ebenen haben. Aufzuzeigen, welche Möglichkeiten es gibt, um das zu verhindern, würde an dieser Stelle zu weit vom Thema abweichen. Ich verweise deshalb auf die Literatur im Anhang, z.b. Wil1. JTAG oder OCDS Immer höhere Taktfrequenzen bei den Microcontrollern verursachen zunehmend größere Probleme bei der Emulation dieser Controller. Angefangen bei der Adaption bis hin zu den Analysern, die ja immer noch etwas schneller sein müssen. Dazu kommen die Auswirkungen immer komplexerer interne Mechanissmen der Controller wie Pipeline Effekte, Cash Effekte, zusätzliche parallele Interne Busse, Coprozessoren u.s.w. die die Interpretation dessen was tatsächlich intern abgelaufen ist immer schwieriger gestalten. Aus diesem Grund hat sich die Halbleiter Industrie etwas neues ausgedacht. Minimale Debugging Funktionalität wird gleich in den Chip mit eingebaut. Über eine speziell dafür vorgesehene Schnittstelle kann mit diesem Debugger kommuniziert werden. Diese Schnittstelle basiert bereits auf einer Norm und nennt sich JTAG. Ursprünglich gedacht für Hardware- Tests ist sie erweitert worden und nun auch für Software Test und Debugging geeignet. Diese erweiterte Schnittstelle hat bei Infineon den Namen OCDS (On Chip Debugging Support) bei Motorola BDM (Backround Debugging Monitor) u.s.w. Diese Lösung stellt einen guten Kompromiss zwischen den Monitor- Lösungen und den Emulatoren dar. Die Vorteile: Sie benötigen keinen Emulationsspeicher, Breakpoints und damit Stepping sind auch im ROM möglich (Sonst nur mit Emulator auf Basis von Emulationsspeicher). So genannte Hardware Breakpoints sind möglich, dass heißt Sie können auf Adressbus und Datenbus triggern und damit auch Zugriffe auf Variablen überwachen, was ohne Echtzeitverletzung mit Monitor- Lösungen nicht möglich ist. Und das alles gibt es zum erschwinglichen Preis von Monitor- Lösungen. Hört sich gut an, oder? Leider ist diese spezielle Schnittstelle nur auf den allerneusten Derivaten der C166 Famile verfügbar. (UTAH, SDA 6000, C166S) Aber für die Zukunft eine gute Aussicht. Inzwischen werden die meisten Bedienoberflächen für Monitor und Emulatoren auch für die OCDS Schnittstelle angeboten, die Preise für diese Lösungen liegen zwischen 1.000,- und 4.000,- Euro, je nach Verbindung zum PC (Parallel, USB, Ethernet...) Debugging von Embedded Systemen Seite 8 von 8

9 RTOS und System Level Debugger Die Anzahl unserer Kunden, die ein Echtzeit-Betriebssystem (RTOS) einsetzen, steigt von Jahr zu Jahr. Damit ist natürlich auch der Wunsch verbunden, Informationen auf diesem Abstraktionsgrad über den Programmablauf und Programmstatus zu bekommen. Z.B. welcher Task war wie lange aktiv, was sind die Inhalte eine Mailbox in diesem Augenblick oder warum wird ein Task nicht ausgeführt. Viele der RTOS Hersteller liefern dafür sogenannte System- Level- Debugging Möglichkeiten. Diese haben jedoch häufig wieder eine eigene Schnittstelle (RS232) und damit sind wir wieder bei der zu Anfang beschriebenen Problematik: lange Download Zeiten, RS232 wird für eigene Applikation benötigt... Hier bieten nun einige Debugger Hersteller zunehmend Unterstützung zum Beispiel durch das sogenanntes KDI (Kernel Debug Interface). Über ein derartiges Interface lassen sich die System Debug Tasks der RTOS Hersteller auch über die Bedienoberfläche der Debugger ansprechen. Vorteil: sie benötigen keine weitere Schnittstelle, Sie haben parallel Zugriff auf Informationen aus dem RTOS und auf der herkömmlichen C-Ebene. Aber nicht alle Debugger unterstützen alle RTOS Systeme, erkundigen Sie sich, welche Lösungen zusammenarbeiten. Abbildung: System- Level- Debugging Möglichkeiten: Grafische Darstellung des Programmablaufes auf RTOS-Ebene durch den Illuminator der Firma OSE Debugging von Embedded Systemen Seite 9 von 9

10 CASE Tools Was für RTOS gilt, ist auch für CASE Unterstützung gültig. Beim Einsatz von CASE Tools wird mehr Komfort auf der Seite der Softwareentwicklung durch einen höheren Abstraktionsgrad und dadurch bessere Verstehbarkeit auch bei Grossen und Komplexen Projekten erreicht. Dieser Schritt zahlt sich jedoch erst richtig aus, wenn dieser Abstraktionsgrad auch beim Debugging wieder zur Verfügung steht. Um einen Eindruck zu bekommen wovon ich spreche, stellen Sie sich vor, Sie würden in C Programmieren, könnten aber nur auf Assembler Ebene Debuggen. Sicherlich kein Idealer Zustand. Einige Werkzeuge wie beispielsweise der Nassi Shneiderman Editor EasyCODE haben aus diesem Grund Debugging Schnittstellen, die von den Debuggern genutzt werden können. Damit lässt sich auf Diagramm Ebene der Verlauf der Software verfolgen, Breakpoints setzen und Variablen Inhalte ansehen. UML / SDL Tools Hier sieht es etwas komplizierter aus. Schnittstellen auf diesem Abstraktionsgrad lassen sich nicht mehr so einfach realisieren und sind derzeit nur bei den teureren Systemen anzutreffen. Zum Beispiel gibt es eine Schnittstelle zwischen SDT (Eines der Marktführenden SDL Tools) und den Lauterbach Emulatoren. Kosten pro Arbeitsplatz über ,- DM. Aber Lösungen wie die UDE der Firma pls werden durch Ihre Flexibilität in naher Zukunft Abhilfe schaffen. Bei uns (Firma Willert Software Tools GmbH) wird derzeit an einer Anbindung des UML Tools Rhapsody an die UDE entwickelt. Damit steht in naher Zukunft eine UML basierende Lösung mit System Level Test und Debugging Möglichkeiten auch für 16 Bit Microcontroller zur Verfügung, die vergleichsweise preiswert ist. Auch in anderen Bereichen entstehen preiswertere Alternativen, die sich auch bei kleineren Projekten amortisieren. Was in der Vergangenheit nur Projekten mit 32 Bit Controllern vorbehalten war, wird in wenigen Jahren auch Standard für Projekte mit 16 Bit Controllern sein. So wie der Übergang von Assembler auf C geschehen ist, wird in den kommenden Jahren der Übergang von C auf C++, Java oder sogar UML geschehen. Immer höhere Performance, preiswerter Speicher und besser optimierende Codegeneratoren machen es möglich. Wichtig: Dieser Abstraktionsgrad muss auch in der Test und Debugging Phase zur Verfügung stehen, das stellt neue Anforderungen an die Debugger. Test / Debugging Angenommen Sie könnten mir jetzt antworten: Könnten Sie mir den Unterschied zwischen Test und Debugging erklären? Wenn ja: Sehr gut. Wenn nicht, ich verrate Ihnen den Unterschied. Wenn der Compiler ein lauffähiges Objekt File erstellt hat und Sie dieses in Ihr Zielsystem laden, beginnen Sie erst einmal mit dem Test. Das heißt Sie finden heraus, ob die gerade erstellte oder geänderte Software genau das tut, was sie erwarten was Sie tun soll. Nun stellen Sie fest, dass es an einer Stelle noch ein Fehlverhalten gibt und nun beginnt der Schritt des Debugging. Sie suchen nach der Ursache dieses Fehlverhalten. Jetzt kommt ein sehr wesentlicher Unterschied zwischen Test und Debugging. Passen Sie gut auf. Die eigentliche Prozedur des Testens ist für ein Modul in der Regel immer wieder gleich oder bei geringen Änderungen sehr ähnlich, und es bietet sich gerade zu an diesen Schritt zu automatisieren. Diese Automatisierung und Wiederholbarkeit eines Testschrittes wird Regressionstest genannt. Und inzwischen gibt es auch dafür spezielle Tools. Z.B. eine Entwicklung von Daimler Chrysler, die Klassifikationsbaum Methode in Verbindung mit dem Tool Tessy. Debugging von Embedded Systemen Seite 10 von 10

11 Hier gilt wieder: das Rad nicht zwei Mal zu erfinden. Auch diese Tools benötigen einen Zugang zum Zielsystem und Sie ahnen schon, auch dafür werden inzwischen die Debugging Systeme genutzt. Also wenn Sie zukünftig effizienter Testen möchten lohnt es, sich mit diesem Thema auseinander zu setzen und bei der Anschaffung eines Debuggers darauf zu achten, dass es eine Verbindung zu einem geeigneten Testwerkzeug gibt. Aber Achtung: Einige Hersteller von Debugging Werkzeugen behaupten, dass sich auch mit Ihren Lösungen automatische ablaufende Tests realisieren lassen. Das ist grundsätzlich richtig, aber der Teufel liegt wie so oft im Detail. Nicht die Erstellung eines Testlaufes ist der kritische Punkt, sondern die Wiederholbarkeit, wenn sich die Software geändert hat. Nur wenn sich die Testfälle nach Änderungen der Software leicht adaptieren lassen, ist das eigentliche Ziel, die einfache Wiederholbarkeit, erreicht. Und das scheitert oft schon an so kleinen Eigenschaften wie der Speicherung von Breakpoints. Wenn Sie in einem Testscript, zwecks Stimulierung einer Schnittstelle, einen Breakpoint setzen, dann wird dieser bei den meisten Debuggern als Zeilennummer in dem entsprechenden C-Sourcefile gespeichert. Nur ein einziges eingefügtes CR/LF im original Sourcefile ruft eine entsprechende Anpassung im Testscript hervor. Von diesen Tücken gibt es noch viele weitere. Unter derartigen Bedingungen lassen sich die Testscripts nicht wirklich mit vertretbarem Aufwand parallel zur Softwareentwicklung aktuell halten. Werkzeuge wie Tessy bieten im Gegensatz dazu spezielle Unterstützung um geänderte Schnittstellen aufzuspüren, und weitestgehend automatisch zu adaptieren. Derartigen Hilfen sind die Voraussetzung, die erstellten Testscripts mit vertretbarem Aufwand zu Pflegen und aktuell zu halten. Das erst macht den Regressionstest wirklich effizient.... Ah Sie sind noch da, Sie lesen noch, das freut mich, dann war der Artikel interessant genug um Sie bei der Stange zu halten. Ich bedanke mich für Ihr Interesse und wünsche Ihnen noch viel erfolg beim Debugging Ihrer Applikationen. Andreas WIllert Debugging von Embedded Systemen Seite 11 von 11