Hardware Debugging

Das »täglich Brot« beim Entwickeln von Embedded Software

21. April 2022, 8:30 Uhr | Von Erol Simsek
Debugging
Debugging ist essenziell für Entwickler von Hard- und Software.
© iSystem

Halbleiter werden immer kleiner und leistungsfähiger, die Anforderungen an die Applikation höher, die Software komplexer: Hardware-Debugging-Tools von iSystem unterstützen Entwickler dabei, funktionsfähigen und sicheren Code zu erstellen. Der Hardware-Debugger wird dabei zunehmend zum Prozess-Tool.

In den 1990er-Jahren existierten für das Debugging von Embedded Software auf einer realen Hardware im Prinzip lediglich zwei Tools: Der Monitor-Debugger, also ein Stück Software, das im Speicher des Embedded-Systems programmiert war und auf Anfragen einer Debugger Software von außen reagierte. Außerdem der In-Circuit Emulator, eine Hardware, die grundsätzlich den in der Zielhardware befindlichen Mikrocontroller bzw. Prozessor durch Adaption ersetzte und emulierte (Bild 1).

Ersteres Tool war günstig und erfüllte grundlegende Funktionen des Debuggings, zweiteres war sehr teuer, kompliziert zu bedienen und die Adaption oft wackelig und fehleranfällig. Dafür erhielt der Entwickler volle Transparenz und Zugriff auf alle Busse des Prozessors. Zeitmessungen und Analysen zur Codeabdeckung waren bereits sehr gut möglich. Halbleiterhersteller mussten für den Zweck allerdings einen speziellen, sogenannten Emulations-Chip mit zusätzlich herausgeführten Pins entwickeln – ein nicht unerheblicher Kostenfaktor für alle Beteiligten.

Mit der zunehmenden Miniaturisierung der Halbleiter und dem Implementieren von On-Chip-Debug-Schnittstellen veränderte sich ebenfalls der Debugger als Werkzeug. Mehr und mehr Funktionen, die vorher in Hardware gegossen waren, wurden über Software realisiert. So wurden die Entwicklungsumgebungen und die Debugger Software mächtiger, die Hardware kleiner bei steigender Leistungsfähigkeit in Bezug auf Bandbreite und Geschwindigkeit. Allerdings sind die grundlegenden Use Cases des Debugging heute noch dieselben.

Anbieter zum Thema

zu Matchmaker+
iSystem
Bild 1: In-Circuit Emulation Ende der 80iger Jahre.
© iSystem

Entwickeln mit Hardware Debugger

Von »printf« über »just«-Flash bis hin zu Breakpoints, Real Time Watches und Step Over, so könnte man Debugging kurz beschreiben. Prinzipiell setzen Entwickler Debugging zum Entwickeln und zur Fehlersuche beim Entwickeln von Treibern, Board/Hardware Bring-up, Boot-Prozessen und vielem mehr als Standardmethode für Low-Level-, also hardwarenahem Entwickeln ein.

So eignet sich ein Debugger zum Beispiel, um

  • die Software auf eine Hardware zu flashen und auszuführen oder an einer bestimmten Stelle im Code mittels Breakpoint zu stoppen,
  • Speicherbereiche und Register zu überprüfen oder zum Testen zu manipulieren und
  • den Call Stack auszulesen.

Wunsch ist, dass der Debugger einfach anzuwenden, verständlich und im Prinzip das ist, was das Gros der Entwickler unter Debugging versteht. Meist hat man nicht mehr Zeit, um sich mit dem Debugger selbst intensiv zu beschäftigen, um eventuell das ein oder andere zusätzliche Feature zu entdecken, das letztendlich viel Zeit bei der Fehlersuche einsparen könnte.

Eine bislang unterschätzte Technik ist zum Beispiel Tracing. Es gibt Einblicke in den Ablauf der Software, ohne das Laufzeitverhalten zu beeinträchtigen. Der Entwickler bekommt so ein reales Abbild der Software auf der Hardware. Sporadisch auftretende Fehler und Flaschenhälse in der Software lassen sich so aufdecken.

iSystem
Bild 2: Der »winIDEA Analyzer« von iSystem, links die aufgezeichneten Objekte und rechts deren zeitliche Korrelation
© iSystem

Mikrocontroller, Prozessoren und SoCs

Die Evolution des Debugging geht einher mit der Miniaturisierung der Halbleiter, deren zunehmender Komplexität und Geschwindigkeit. In den letzten 15 Jahren hat die Embedded- und insbesondere die Automobilindustrie viele zusätzliche Funktionen in ihre Produkte eingeführt. Hiermit schafft sie es, die heutigen und zukünftigen Umweltvorschriften zu erfüllen und die Anzahl der Autounfälle im Allgemeinen zu reduzieren. Die Autos werden effizienter entwickelt und produziert, indem Funktionen auf mehrere elektronische Steuergeräte (ECUs) verteilt werden, anstatt ein dediziertes Steuergerät nach Funktion zu entwickeln. Mit neuen Funktionen heben sich die Hersteller auch von der Konkurrenz ab. Um all das zu erreichen, benötigt die Automobilindustrie die Halbleiterhersteller, um ihrer Anfrage nachzukommen und kompaktere und schnellere Mikrocontroller zu entwickeln und herzustellen.

So waren die eingebetteten Multicore-Mikrocontroller, Controller mit zwei oder mehr Kernen, geboren. Der Wechsel von Single- zu Multicore-Architekturen in Steuergeräten brachte neue Herausforderungen für alle Beteiligten mit sich. Zudem wurden die Anbieter von Embedded Software Tools mit neuen Fragen konfrontiert, angefangen bei dem einfachen Zugriff auf alle Kerne eines Multicore-Steuergeräts bis hin zum Verteilen von Embedded und Legacy Software auf verschiedenen Kernen, die effizient und gleichzeitig mit hoher Leistung ausgeführt werden. Somit war die traditionelle Art des Entwickelns von Embedded Software bereits zu diesem Zeitpunkt zu hinterfragen.

Mit der Einführung von High-Perfomance-Plattformen bzw. -Computing und Many-Core-Systemen finden Prozessorarchitekturen Einzug in die Entwicklung, deren Komplexität alles bisher Gesehene weit überschreitet. Welche Rolle spielt hier noch das Debugging? Im Prinzip bleibt es bei den Basics. Hinzu kommen externe Flash-Bausteine, die zu bedienen sind. Debugger helfen zunächst, den Boot-Prozess zu kontrollieren, um dann im nächsten Schritt einzelne Teile und Kerne der Prozessoren und die darauf laufende Software näher zu untersuchen. Neben Standard-Debugging-Funktionen und aufgrund der steigenden Komplexität der Software-Systeme nutzen Entwickler zunehmend Analysemöglichkeiten wie die Timing-Analyse, Funktions-Profiling oder CPU-Load-Messung (Bild 2).

Voraussetzungen hierfür sind die Verfügbarkeit von Trace-Schnittstellen auf dem eingesetzten Halbleiter und ein entsprechender Debugger, dessen Software solche Funktionen umsetzt. Die technischen Weiterentwicklungen am Halbleitermarkt verändern den Software-Entstehungsprozess und somit wiederum den Debugger als grundlegendes Werkzeug hin zum Prozesswerkzeug.

Software-Entwicklungsprozesse und Standards

Verteilte Entwicklungsteams, eine zunehmend komplexe Codebasis, wachsende funktionale Anforderungen, Standardisierung und wenig Zeit: Auch beim Entwickeln von Embedded Software können die Ingenieure dem Druck, ein zuverlässiges und sicheres Produkt in möglichst kurzer Zeit zur Marktreife zu bringen, nur mit einem hohen Maß an Abstraktion und Automatisierung begegnen.

Werkzeuge im klassischen Sinne müssen deshalb heute vielseitiger einsetzbar sein denn je. Früher ausschließlich von Mikrocontroller-Experten als ein hardwarenahes Entwicklungswerkzeug eingesetzt, findet man einen Debugger heute zunehmend in unterschiedlichen Situationen einer Software-Entwicklung wieder. Hierbei verbindet der Debugger nach wie vor die eigentliche Zielhardware über Standard-Debug-Schnittstellen mit dem Zweck, Embedded Software so nah wie möglich auf der eigentlichen Hardware zu entwickeln und zu testen. Neben der einfachen Schnittstellenfunktion zur Zielhardware stellen Debugger schon lange Funktionen zur professionellen Fehlersuche und somit zum Testen einer Software bereit.

Hierbei haben die Entwickler die Möglichkeit, das Ausführen der laufenden Software nachzuverfolgen. Sie können den Programmzustand inspizieren sowie das Ausführen des Programms unter bestimmten Bedingungen anhalten. Das geschieht mit minimaler oder komplett ohne Beeinflussung der untersuchten Software. Professionelle Debug-Werkzeuge ermöglichen zusätzlich das Aufzeichnen von Abläufen in der Software in Echtzeit (Tracing), das Protokollieren von Ausführungszeiten im Bereich von Taktzyklen sowie das für das Testen relevante Beurteilen der abgearbeiteten Teile der Software (Code Coverage).

iSystem
Bild 3: Debugger bieten heute Schnittstellen an, die Entwicklungs- und Testprozesse mit fließenden und automatisierten Werkzeugübergängen realisieren.
© iSystem

Damit ein Kunde all die Funktionen flexibel nutzen kann, stellen die Debugger-Hersteller generische Schnittstellen bereit, die die Integration der Werkzeuge in den Entwicklungs- und Testprozess (Bild 3) des Kunden ermöglichen. Die Schnittstellen müssen sich zum Lösen verschiedener Aufgaben eignen (Entwickeln, Testen, Verifizieren und Validieren von Software und Hardware). Hier ist der Standard die Unterstützung von Programmier- (C, C++, C#, Java etc.) und Scriptsprachen (Python etc.) zum Fernsteuern des Entwicklungs-Tools aus einer anderen (kundenspezifischen) Applikation. Im Prinzip sind dann Prozessteile sowohl während des Entwickelns als auch des Tests automatisierbar.

Des Weiteren stellen die Debugger von heute »Mini-HIL«-Funktionen (Hardware in the Loop, Mess- und Stimulimodule für Tests) bereit, um digitale und analoge Signale zu erzeugen oder zu messen. Hiermit ist es möglich, bereits während der Software-Entwicklung sehr nah an der Realität und so früh wie möglich zu testen. Wichtig hierbei ist, dies aus der gewohnten Umgebung heraus, quasi on-the-fly und ohne die Aneignung einer neuen Methodik zu realisieren.

Ein typischer Anwendungsfall der flexiblen Schnittstellen zur Testautomatisierung ist Continuous Integration (CI, Bild 4). CI sieht vor, dass jedes Teammitglied, das gemeinsam mit anderen an einer Software arbeitet, seinen geänderten oder neu erstellten Code in kurzen Abständen in ein mit dem Team geteilten Repository integriert. Hierfür gibt es eine Reihe von geeigneten Continuous Integration Servern wie Jenkins, GitLab, TeamCity, CircleCI oder GitHub Actions. Mit der Integration löst man über eine CI-Software, die man inhouse oder in der Cloud hostet, eine schnelle und automatisierte Reihe von Schritten – eine sogenannte Pipeline – aus. Sie umfasst in der Regel den Build, statische Analysen sowie Unit- und Systemtests.

iSystem
Bild 4: Die Pipeline einer Continuous-Integration-Infrastruktur mit Build, statischen Analysen, Unit-, Systemtests und letztendlich lieferfähigem Produkt
© iSystem

Somit wird der klassische Debugger zum Testwerkzeug für Tests auf der realen Hardware. Grundsätzlich kann ein Entwickler eine Software ebenfalls unabhängig von der Zielhardware umfangreichen Tests unterziehen. Dennoch werden in simulierten Umgebungen nicht alle potenziellen Fehler aufgedeckt: So ist die benötigte Hardware-Peripherie oft nicht verfügbar oder die Applikation verhält sich nicht exakt gleich wie auf realer Hardware, das Timing-Verhalten ist anders oder der Cross-Compiler generiert zielspezifischen Objektcode und damit nicht den gleichen Code wie der Compiler, den man für die Testumgebung verwendet. Aus dem Grund ist es sinnvoll, frühzeitig so nah wie möglich an der realen Hardware zu testen, um die korrekte Funktion des Endprodukts sowie das exakte Timing-Verhalten der Applikation zu gewährleisten.

Safety-Standards wie ISO 26262 und DO-178C beeinflussen zum einen den Funktionsumfang von Werkzeugen sowie das Erbringen eines Nachweises der Korrektheit der Funktionen beim Kunden selbst. Insbesondere Kunden aus der Luftfahrt – aber auch in jüngster Zeit aus der Automobilindustrie – fordern vom Tool-Hersteller eine Zusammenarbeit in puncto Tool-Qualifizierung. Hierzu müssen Tool-Hersteller Nachweismöglichkeiten der funktionalen Korrektheit der eingesetzten Werkzeuge bezogen auf bestimmte Use Cases schaffen. Das können organisatorische Maßnahmen sein, also zum Beispiel externe Audits des Entwicklungsprozesses oder Zertifizierungen der Werkzeuge durch unabhängige Dritte oder Referenz-Tool-Suiten, die Kunden beim Erstellen des Korrektheitsnachweises unterstützen. Oben dargestellte Methoden zum Automatisieren von Testabläufen mittels Debugger eignen sich sehr gut für solche Tool-Qualifizierungsvorgänge.

Simsek_Erol
Erol Simsek ist CEO von iSystem, einem privat geführten Unternehmen, das Tools und Lösungen für die Entwicklung und das Testen von Embedded Software entwickelt und herstellt.
© iSystem

Zusammenarbeit essenziell

Der Debugger ist zunehmend ein Prozesswerkzeug – die Basis-Funktionen eines Debuggers finden ihre gewohnte Anwendung und werden mit mächtigen Analysefunktionen ergänzt. Allerdings erhöhen die zunehmende Komplexität von Software, der Einsatz von immer mehr Soft- und Hardware Tools beim Entwickeln von Software selbst sowie deren Interdependenzen den Bedarf an Wissenstransfer und Beratungsservices zwischen Toolherstellern, Chiplieferanten und Kunden.

Eine kontinuierliche und offene Kommunikation zwischen allen Beteiligten ist der Schlüssel zum Erfolg. Schon heute wollen Entwickler keine Werkzeuge mehr kaufen, sie wollen sie nutzen, wann und wo immer sie sie benötigen. Neue Geschäftsmodelle für die Software-Entwicklung und -Test kommen dort zum Einsatz, wo Tools, Wissenstransfer und Beratung ein gemeinsames Produkt und letztendlich eine Dienstleistung sind. Wie in der Softwareindustrie ist für die globale Entwicklung und den Test von Embedded Software das Subscription-Business-Modell gut geeignet.


Das könnte Sie auch interessieren

Verwandte Artikel

iSystem AG