Mikroprozessor-Debugging: 1980–2016 – Eine umfassende Geschichte

Seit Anbeginn des Elektronik-Designs sind Bugs unvermeidlich, und Debugging ist die essenzielle Disziplin, um Fehler und Irrtümer zu ringen und zu bestimmen, wer obsiegt – und wie gründlich.

Debugging-Technologie hat sich so faszinierend entwickelt wie die Designs, die sie unterstützt. Von einfachen Stimulus-Response-Observe-Ansätzen bis zu heutigen hochentwickelten Tools, Equipment und Methodologien ist das Feld im Tandem mit zunehmend komplexen Systemen gewachsen. 2017 begann eine neue Ära mit der Einführung von Debug über funktionale I/O, die noch größere Effizienz und Fähigkeiten verspricht.

Nach Jahrzehnten globaler Innovation bin ich seit 1984 im Debugging involviert. Um den Paradigmenwechsel zu würdigen, den wir jetzt erleben, ist es nützlich, die Meilensteine zu revisitieren, die die Industrie prägten.

1970er–1980er

Systemdesign unterschied sich damals markant von heute. Ein typisches Board bestand aus CPU, (EP)ROM, RAM und Peripherie-ICs wie PICs, UARTs, DMA-Controllern, Timern und I/O-Geräten, jeweils auf separaten Chips implementiert.

1980er Single-Board-Computer (SBC)
(Quelle: https://oldcomputers.net/ampro-little-board.html)

Entwickler schrieben Code in Assembler oder C, kompilierten, linkten und produzierten eine HEX-Datei für das ROM-Image. Der Prozess involvierte manuelles Löschen von EPROMs mit UV-Eraser, Programmierung via serieller oder paralleler Schnittstelle und Wiedereinbau der Chips auf dem Board. Wenn das Programm sich nicht wie erwartet verhielt, standen diverse Debugging-Techniken zur Verfügung.

Code-Inspektion: Der fundamentalste Ansatz, noch immer von vielen genutzt, involviert mentales Durchschreiten des Codes oder mit Texteditor – eine Fähigkeit, die wertvoll bleibt, wenn Tools unavailable oder zu kostspielig sind.

LEDs: Eine klassische Methode nutzt On-Board-LEDs oder andere Indikatoren, um Programmzustand zu signalisieren. Durch Einfügen von LED-Toggles an Schlüsselstellen können Entwickler Execution Flow visuell verfolgen. Wenn zusätzliche I/O-Pins und ein Logic Analyzer verfügbar sind, wird Echtzeit-State-Tracing möglich.

On-Target Monitor: Boards mit seriellen Port und ausreichend Memory konnten ein kleines Monitor-Programm hosten. Durch Sprung in diesen Monitor konnte ein Entwickler durch Assembler steppen, Register und Memory via RS-232-Commands wie s (step) oder m 83C4,16 (display memory) inspizieren.

In-Circuit Emulator (ICE): Für die, die es sich leisten konnten, war der ICE der ultimative Debugger. Er ersetzte die CPU durch einen Emulations-Circuit, der interne Signale beobachten und kontrollieren konnte. Obwohl groß und teuer – oft Tausende Dollar kostend – boten ICEs advanced Breakpoints, Trace und die Fähigkeit, EPROMs mit Emulations-RAM zu tauschen, was das Löschen und Re-Flashen während der Entwicklung eliminierte.

Motorola Exorciser ICE
(Quelle: https://www.exorciser.net/personal/exorciser/Original%20Files/exorciser.jpg)

Intel MDS ICE
(Quelle: https://www.computinghistory.org.uk/userdata/images/large/PRODPIC-731.jpg)

1982–1990

Drei Schlüsseländerungen emergierten für Embedded-Entwickler:

• Integrierte ICs: CPUs begannen Peripherie zu inkludieren – z. B. Intel 80186/80188 (Evolution des 8086/8088), Zilog Z180 (vom Z80), und Motorola CPU32-Familie (z. B. 68302) vom 68000.
• Erschwingliche ICEs: Hersteller produzierten kostengünstigere ICEs ohne Bond-out-Chips, reduzierten Preis auf unter $10.000 für einen 80186 ICE.
• Taktfrequenz-Herausforderungen: Steigende CPU-Geschwindigkeiten belasteten ICE-Kabel und Control-Logic. Die Lösung war On-Chip-Debug-Circuitry (OCD), die Single-Step, Registerzugriff und Breakpoints bei voller CPU-Geschwindigkeit bot, wenngleich frühe Implementierungen vollständiges Trace-Feature fehlten.

OCD-Zugriff nutzte typischerweise proprietäre Interfaces wie Background Debug Mode (BDM) oder das gängigere JTAG, traditionell für Production Test genutzt. Während einige Tools Memory-Zugriff während laufender CPU erlaubten, konnten andere nicht, was zu Variation across Implementierungen führte.

1990–2000

Externes Trace wurde durch hohe Taktraten und interne Caches unpraktisch. Stattdessen führten Hersteller komprimierte Core-Trace-Daten ein – Erfassung nur nicht-sequentieller Program-Counter-Änderungen und Kompression für Off-Chip-Transport. Dies erlaubte dem Debugger, Execution Paths mithilfe des Wissens über das laufende Programm zu rekonstruieren. Schlüsselarchitekturen umfassten IBMs PowerPC, Motorolas ColdFire und ARMs 7TDMI-Cores.

2000–2010

Komprimierte Trace-Datasets ermöglichten On-Chip-Trace-Buffer wie ARMs Embedded Trace Buffer (ETB), zugänglich via JTAG. Die Buffer-Größe war konfigurierbar, balancierend Silicon Area gegen Trace-Performance. Multi-Core SoCs führten neue Herausforderungen ein: JTAG Scan Chains verschwanden, wenn Cores powered down. ARMs CoreSight-Architektur löste dies, indem sie einen einzelnen JTAG-basierten Debug Access Port bereitstellte, der alle Memory-Mapped CoreSight-Komponenten erreichen konnte, inklusive mehrerer Cores, die unabhängig power-cyclen konnten.

2010–Gegenwart

Mit dem Aufstieg 64-Bit-Cores und verbreiteter Linux/Android-Nutzung gewann On-Device-Debug an Traktion. Kernel-Treiber exponieren nun CoreSight-Komponenten, was On-Target-Trace-Capture via perf-Subsystem ermöglicht. Der ARM Embedded Logic Analyzer (ELA) bringt den Reichtum früher ICEs zurück, bietet komplexe Breakpoints, Trigger und interne SoC-Signalzugriffe – alles innerhalb des Siliciums.

Nach 40 Jahren unermüdlicher Innovation steht das Feld am Anfang eines neuen Kapitels: Debugging und Tracing über existierende funktionale I/O. Dieser Shift verspricht leanere Lösungen, die Entwicklungszeit und -kosten reduzieren bei gleichzeitig gesteigerter Fähigkeit, den langen Krieg gegen Bugs fortzusetzen.