Worauf es in der Praxis ankommt On-Chip-Infrastrukturen für Debugging und Test

...Zweitens: Das Umkonfigurieren auf eine neue Aufgabe ist in der Regel zeitintensiv. Daher hat sich der Einsatz von Robotern in der Smartphone-Fertigung lange Zeit nicht gelohnt, denn die Roboter hätten jeweils nach wenigen Monaten auf die Fertigung eines anderen Modells umkonfiguriert werden müssen.
Die Produktivität bei der Fehlersuche hängt maßgeblich von den Debugging-Infrastrukturen der SoCs ab.

Je komplexer die Embedded-Applikation, desto aufwendiger gestalten sich in der Regel die Fehlersuche und der Test des kompletten Systems. Wie effizient das geht, hängt maßgeblich von der internen Debug-Infrastruktur der jeweiligen Chips ab. Wir haben die gängigsten Architekturen für Sie verglichen

Bei kostengünstigen Standardsystemen wird seitens der Chiphersteller erfahrungsgemäß nach wie vor eher wenig in die Debug-Infrastruktur investiert. Ganz anders sieht es im Automotive- und Industrial-Umfeld aus, wo immer häufiger äußerst leistungsfähige Multicore-Controller zum Einsatz kommen. Hier werden hinsichtlich der Software-Entwicklung sehr viele höhere Forderungen an das Debugging und die Beobachtbarkeit der Systeme gestellt, was ich nicht zuletzt  auch in den verfügbaren Schnittstellen sowie  in den On-Chip-Debug- und Trace-Funktionen niederschlägt.

Fenster zum System – die Debug-Schnittstelle

Das Debugging und der Test auf realer Hardware stehen und fallen mit einem leistungsfähigen Zugang zum System und der Möglichkeit, den Systemzustand von außen zu beobachten.  Im einfachsten Fall meldet die Software selber ihren aktuellen Zustand nach außen. Dies kann direkt in textueller Form auf einer Konsole oder beispielsweise auch über eine serielle Schnittstelle erfolgen. Landläufig ist dieses Verfahren als „printf“-Debugging bekannt und setzt natürlich entsprechende Erweiterungen im Code voraus.

Dedizierte Debug-Schnittstellen erlauben hier einen weitaus effizienteren und komfortableren Zugang. Dieser ist allerdings nicht umsonst zu haben. Über alle Controller-Architekturen und -Hersteller hinweg am verbreitetsten ist nach wie vor sicherlich die in der IEEE 1149.1 standardisierte JTAG (Joint Test Action Group)-Schnittstelle. Eigentlich für den Test von integrierten Schaltungen entwickelt, übernimmt sie bis dato immer noch die Rolle des De-Facto-Standards für den Debug-Zugang. Allerdings gestaltet sich die JTAG-Implementierung durch den Mindestbedarf von fünf Pins (TDI, TDO, TCK, TMS, TRST) vergleichsweise aufwändig.  Kommen noch weitere Signal-Leitungen für Target-Reset, Target-Referenzspannung und herstellerspezifische Signale für das On-Chip-Debug-System hinzu, sind die zusätzlichen Kosten für Endprodukte im mittleren oder niedrigen Preissegment kaum mehr akzeptabel. Zudem ist der klassische JTAG-Standard in punkto erreichbare Geschwindigkeit und Robustheit gegenüber Störungen mittlerweile fern dem aktuellen Stand der Technik.

Umso erfreulicher ist es, dass sich inzwischen aus den verschiedenen herstellerspezifischen Alternativen aufgrund der Marktdominanz einiger Mikrocontrollerarchitekturen einige neue Quasi-Industriestandards herausgebildet haben. An erster Stelle ist hier SWD (Serial Wire Debug) von ARM zu nennen, dass als Bestandteil von ARMs CoreSight Debug- und Trace IP (Intellectual Property) gerade einmal mit zwei Pins auskommt (bidirektionales Datensignal und Takt). Ein weiterer Vorteil ist die gegenüber JTAG doppelt so hohe Übertragungsgeschwindigkeit. Bei 50 MHz Taktfrequenz  lassen sich so Transferraten von bis zu 4 MByte/s realisieren. SWD nutzt dafür ein paketorientiertes Übertragungsprotokoll, das eine einfache Fehlererkennung zulässt und so die Robustheit gegenüber Störungen auf dem Debug-Kanal erhöht. Das neue,  mit den CoreSight SoC-600-Spezifikationen vorgestellte SDW-Protokoll Version 2 erlaubt es als sognannte Multi-Drop Architektur künftig sogar mehrere Prozessoren in einem Multi-Prozessor-System über ein einziges Debug-Interfaces anzusprechen.

Wer Bausteine von Infineon, beispielsweise Mitglieder der AURIX-Familie, einsetzt, wird schnell die Vorzüge des Device Access Ports (DAP) schätzen lernen (Bild 1).  Diese Schnittstelle kommt wie das SWD ebenfalls mit zwei Pins für den bidirektionalen Datentransfer und den Takt aus. Allerdings erfolgt hier zusätzlich eine zyklische Redundanzprüfung der Daten (CRC), wodurch eine weitere Steigerung der Fehlertoleranz erzielt wird. Von allen anderen Produkten unerreicht ist auch die Performance des DAP. Daten zwischen dem Debugger und dem Target lassen sich mit beindruckenden 160 MHz übertragen, was letztlich einer Datenrate von bis zu 15 Mbyte/s für Blocktransfers entspricht. Außerdem lässt sich der DAP in zwei weiteren Modi – Wide-Mode und SPD (Single Pin DAP) – betreiben. Der Wide-Mode erlaubt eine Erhöhung der Datenrate durch eine zusätzliche Datenleitung. SPD hingegen basiert auf einer Codierung des Taktes im Datensignal und kommt deshalb ohne separate Taktleitung aus. Letzteres  führt zwar zu geringeren Transfergeschwindigkeiten, dafür eignet sich SPD aber für die Übertragung der Debug-Signale über CAN.

Als echter Nachfolger von JTAG und von offizieller Seite standardisiert ist cJTAG (IEEE 1149.7). cJTAG findet bei einigen Bausteinen von NXP Verwendung. Für den Anwender am offensichtlichsten ist auch hier die Reduktion der Signalleitungen auf zwei Pins. Das zur JTAG-Standard-Debug-Schnittstelle abwärtskompatible cJTAG bietet jedoch noch einige weitere für Multicore und Multiprozessor-Systeme interessante Zusatzfunktionen wie die Unterstützung von mehreren Test Access Ports (TAPs) und für das Power-Management der Controller.

Renesas stellt für seine Mikrocontroller neben JTAG eine proprietäre Schnittstelle namens Low Pin Debug LPD zur Verfügung. LPD kann mit einer unterschiedlichen Anzahl von Pins benutzt werden, was durch den Anwender konfiguriert werden muss, und kommt ohne den Overhead von JTAG aus. Ein weiteres Merkmal von LPD ist das vergleichsweise sehr effiziente Protokoll, dank dem sich bei Tankfrequenzen von 10 MHz Blocktransferraten von bis 1 MByte/s realisieren lassen.