Suchen

Debugger Die neue Trace-Welt jenseits von Code- und Daten-Trace

| Autor / Redakteur: Jens Braunes * / Holger Heller

Code- und Daten-Trace alleine erlauben nur einen beschränkten Blick auf das Echtzeitverhalten aktueller Embedded-Systeme. Ein Signal-Trace der Peripherie hilft dabei.

Firmen zum Thema

Mikrocontroller der Qorivva MPC57xx-Familie: viel Peripherie und das GTM (Generic-Timer-Modul)
Mikrocontroller der Qorivva MPC57xx-Familie: viel Peripherie und das GTM (Generic-Timer-Modul)
(PLS)

Abseits aller Systembusse und Rechenkerne gibt es innerhalb komplexer Peripherie häufig spezielle Signale, die für Debugging, Test und eine umfassende Systemanalyse ebenfalls eine wichtige Rolle spielen können. Die Praxis zeigt inzwischen, dass komplexe Systeme mit mehreren CPUs und mächtiger Peripherie letztlich nur mittels neuer Trace-Technologien wirklich beherrschbar sind.

Mittlerweile hat sich On-Chip-Trace als Werkzeug für das reine Debugging und für umfangreiche Systemanalysen im Rahmen von Tests und Performance-Messungen etabliert. Kaum ein Controller wird heute noch ohne Trace-Hardware angeboten, und alle renommierten Debuggerhersteller werben mit umfangreicher Unterstützung für On-Chip-Trace.

Bildergalerie
Bildergalerie mit 6 Bildern

Landläufig versteht man unter dem Oberbegriff „On-Chip-Trace“ bislang die Aufzeichnung der Befehlsabarbeitung – den Instruction-Trace – und die Aufzeichnung der Datentransfers zwischen den CPUs und dem Speicher bzw. den Datentransfers über die Systembusse – den Data-Trace. Um dem Kundenwunsch nach möglichst hoher Systembeobachtbarkeit nachzukommen, haben die ersten großen Mikrocontroller-Hersteller nun begonnen, ihre Trace-Lösungen zusätzlich um Signal-Trace für Peripherals zu erweitern.

Neue Controller – neue Trace-Quellen

In den vergangenen Monaten wurden mit der Qorivva-MPC57xx-Familie von Freescale und der AURIX-Familie von Infineon zwei neue leistungsstarke Multicore-Automotive-Motorcontroller-Familien auf dem Markt eingeführt, die sich beide nicht nur durch hohe Rechenleistung, Sicherheitsfunktionen und eine umfangreiche Ausstattung an Peripherie auszeichnen. Gemeinsam ist ihnen auch die Integration des von Bosch entwickelten und von beiden Herstellern lizenzierten Generic Timer Moduls (GTM) [1].

Dieses Modul ermöglicht einerseits die Realisierung von flexiblen und hochkomplexen Zeitsteueralgorithmen, andererseits aber auch eine effiziente und parallele Verarbeitung von Signalen. Wirklich neuartig an dieser Einheit ist, dass sich das GTM selbst mit einem Mehrkernprozessor vergleichen lässt. Ebenso wie die Hauptkerne der MPC57xx- bzw. AURIX-Mikrocontroller lassen sich die Rechenkerne der GTM mittels eines RISC-artigen Befehlssatzes programmieren.

Die größte Herausforderung für beide Hardwarehersteller bestand vor allem darin, das GTM in das jeweilige für die beiden Controller-Familien etablierte Trace-System zu integrieren. Keine einfache Aufgabe, wenn für eine Laufzeitanalyse plötzlich zusätzlich zum Programm- und Datentrace des GTM auch eine Vielzahl von Einzel- oder Multi-Bit-Signalen relevant sind. Diese müssen auch in die aufzuzeichnenden Trace-Daten Eingang finden.

Allerdings handelt sich dabei um mehrere hundert Einzelsignale, die mit vertretbarem Hardwareaufwand unmöglich alle gleichzeitig dem Trace-System verfügbar gemacht werden können. Der einzige Ausweg aus diesem Dilemma ist eine konfigurierbare Vorauswahl, die auch durch die Lizenznehmer des GTM auf unterschiedliche Art und Weise realisiert wurde.

Trigger-Switch im On-Chip Debug System

Infineon hat zu diesem Zweck für die
AURIX-MCUs ihr On-Chip Debug System (OCDS) um einen Trigger-Switch erweitert (Bild 1), der es erlaubt, Signale von unterschiedlicher Peripherie oder auch vom GTM an verschiedene Senken des Debug-Systems weiterzuleiten. Eine dieser Senken ist die Multi-Core Debug Solution (MCDS), das von Infineon in den aktuellen Controllern verbaute Trace-System. Die Unmengen von anfallenden Signalen der Peripherie werden über MUX-Kaskaden vorausgewählt und bilden dann ein Trigger-Set.

Die Trigger-Sets werden wiederum über die OCDS-eigenen Trigger-Busse an das interne Trace-Interface weitergeleitet. Was am Trace-Interface allerdings ankommt, ist lediglich ein uninterpretiertes Datum und resultiert nur in einem allgemeinen Datentrace-Paket. Zur späteren Dekodierung im Debugger muss also zwingend die eingestellte Konfiguration der MUX-Kaskaden bekannt sein, um wieder auf den tatsächlichen Ursprung der Trace-Daten und letztlich deren Bedeutung rückschliessen zu können.

(ID:37541440)