Worauf es in der Praxis ankommt
On-Chip-Infrastrukturen für Debugging und Test
Fortsetzung des Artikels von Teil 1
Funktionale Schnittstellen – die bessere Lösung?
Um Kosten zu sparen, gibt es seit einigen Jahren neben den beschriebenen Lösungsansätzen zudem Bestrebungen, dedizierte Debug-Interfaces aus Kostengründen möglichst ganz zu vermeiden. Stattdessen sollen funktionale Schnittstellen wie beispielsweise CAN, Ethernet oder USB für das Debugging genutzt werden, da diese größtenteils ohnehin auf dem Chip vorhanden sind.
Für den Datentransfer über den CAN-Bus eignet sich beispielsweise das bereits erwähnte Single-Pin-DAP, was zur Entwicklung des DXCPL (DAP over CAN Physical Layer) geführt hat. Allerdings liegen die Übertragungsraten mit lediglich 10 bis 40 KByte/s um ein Vielfaches unter denen mit klassischem DAP realisierbaren, weil CAN als Übertragungsmedium nur eine vergleichsweise geringe Bandbreite bietet. DXCPL wird deshalb vor allem für das Debugging im Feld genutzt, also wenn die Debug-Schnittstelle durch das Gehäuse eines Steuergerätes nicht mehr zugänglich ist.
Eine weitere interessante Alternative könnte die Benutzung standardisierter Schnittstellen z.B. aus dem Calibration-Bereich werden. So verfolgt eine Arbeitsgruppe der ASAM gegenwärtig das Ziel, dass XCP Protokoll, das bisher ausschließlich für die Verbindung von Kalibrier-Tools mit Steuergeräten Verwendung fand, auch für das Debugging zu benutzen. Dieser Vorstoß soll zukünftig das Debuggen von Steuergerätesoftware unter realen und sogar extremen Bedingungen ermöglichen.
Wesentlich weiter geht ARMs SoC-600-Spezifikation, denen zufolge Debugging künftig über quasi beliebige funktionale Interfaces möglich werden soll. Die Vorteile: Debugging wäre dann auch im Feld möglich, wenn traditionelle Debug-Interfaces nicht mehr zugänglich sind. Und teure spezialisierte Hardwarelösungen für den Debug-Zugang auf dem Target und den Tools könnten durch preiswerte Standardkomponenten und IP-Blöcke, die eh bereits vorhanden sind, abgelöst werden. Die Nachteile: Für die eigentliche Applikation stehen möglicherweise weniger Interfaces zur Verfügung. Außerdem muss die Applikation selbst die Initialisierung übernehmen, um die funktionalen Interfaces für den Debug-Kanal zu öffnen.
Alles unter Kontrolle – On-Chip-Debug-Systeme
Eigentlich noch wichtiger als die Debug-Schnittstellen ist das Debug-System auf dem Chip. Denn damit stehen und fallen die Möglichkeiten der Systembeobachtung und -kontrolle, also das, was die Debugger-Software auf dem PC leisten kann. Die Debug-Infrastruktur, oft auch als On-Chip-Debug-System bezeichnet, hat im Wesentlichen zwei Aufgaben:
- Das Bereitstellen von Target-Informationen wie Speicher- und Registerinhalte oder den Status. Zusätzlich soll natürlich auch deren Manipulation durch den Entwickler möglich sein.
- Die Kontrolle der Programmausführung auf dem Target. Diese umfasst sowohl das Anhalten – getriggert vom Debugger – und wieder loslaufen lassen als auch den Single-Step-Betrieb und Breakpoints.
Wie die Schnittstellen ist auch die Debug-Infrastruktur stark hersteller- und architekturspezifisch. Der Debugger sorgt letztlich dafür, dass sich der Entwickler aber darum kaum kümmern muss.
Als einziger wirklicher Standard ist hier lediglich Nexus (IEEE-ISTO 5001™) hervorzuheben. Abgekoppelt von der tatsächlichen Hardware-Realisierung werden darin vier aufeinander aufbauende Compliance Classes, jede mit einem festgelegten Satz von Debug-Funktionen, definiert /Tabelle). Um die Konformität zu einer bestimmten Klasse sicher zu stellen, muss der Chiphersteller mindestens die dort geforderten Debug-Funktionen implementieren, wobei die oben beschriebenen grundlegenden Aufgaben bereits durch die Nexus Class 1-Kriterien abgedeckt sind. Nexus-konforme Implementierungen findet man vor allem bei Controllern von NXP und STMicroelectronics, die auf der Power Architecture basieren. Aber auch bei Renesas wurde für einige der RH850-Bausteine auf Nexus zurückgegriffen.
Jobangebote+ passend zum Thema
| Class 1 | Class 2 | Class 3 | Class 4 | |
|---|---|---|---|---|
| STATIC DEVELOPMENT FEATURES | ||||
Read or write user registers and memory in debug mode | x | x | x | x |
| Single-step instruction in user mode and re-enter debug mode | x | x | x | x |
| Enter / exit a debug mode from / to user mode | x | x | x | x |
| Stop program execution on instruction/data breakpoint and enter debug mode (minimum 2 breakpoints) | x | x | x | x |
| DYNAMIC DEVELOPMENT FEATURES | ||||
| Ability to set breakpoint or watchpoint | x | x | x | x |
| Read or write memory locations while program runs in real time | - | - | x | x |
Auszug aus den Nexus Compliance Classes. Static Development Features stehen während angehaltenem Target, Dynamic Development Features auch bei laufendem Target zur Verfügung.
- On-Chip-Infrastrukturen für Debugging und Test
- Funktionale Schnittstellen – die bessere Lösung?
- Komplette Debug-IP: ARM CoreSight
- Spurensuche – Systembeobachtung durch Trace
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Systemdesign / Debug & Trace
Universalwerkbank für Mikrocontroller
DESIGN&ELEKTRONIK TechTalk
MCUs werden immer komplexer, was tun?
Debugging für Profis
Branch Coverage für optimierten Code
