Suchen

Debugging und Laufzeitbeobachtungen beim Design von High-End-SoCs

Autor / Redakteur: basierend auf Material von PLS / Sebastian Gerstl

Es gibt diverse Faktoren, welche die Beobachtung von Datenströmen bei Applikationstests erschweren. Dazu zählen Hardware-Neuerungen wie Networks-onChips (NoCs), Echtzeitbetriebssysteme oder der Einsatz externer Prüfgeräte. Wie lassen sich hier Laufzeiten verlässlich im Blick behalten?

Firmen zum Thema

Die Universal Debug Engine (UDE) von PLS wartet in Version 5.2 mit einigen gänzlich neuen Funktionen diverser Optimierungen für komfortables und effizientes Debugging auf.
Die Universal Debug Engine (UDE) von PLS wartet in Version 5.2 mit einigen gänzlich neuen Funktionen diverser Optimierungen für komfortables und effizientes Debugging auf.
(Bild: PLS)

Quellcode allein gibt nicht das vollständige Bild einer eingebetteten Anwendung wieder: Um das dynamische Verhalten und die Interaktion zwischen Anwendungscode und Hardware zu erfassen, muss man in der Lage sein zu sehen, was während der Laufzeit passiert. Nur so können Entwickler in der Test- und Debug-Phase eines Systems nachvollziehen, ob die Applikation wie gewünscht läuft, oder an welcher Stelle Fehler oder Schwachstellen auftreten.

Software-Tracing ist eine Methode, die sich hier bereits seit Jahren etabliert oder bewährt hat. Doch reichen herkömmliche Tracing-Tools gerade bei modernen Bauteilen oft nicht aus, wenn es darum geht, das Laufzeitverhalten auf dem gesamten Chip zu überblicken. Allein der Einsatz eines Echtzeitbetriebssystems kann das Laufzeitverhalten enorm verändern. Hinzu kommen neuere Entwicklungen, die Chip-Hardware leistungsfähiger machen, aber herkömmliche Testmethoden vor neue Herausforderungen stellen.

Beobachtung des Datenstroms über Networks-on-Chip

Immer mehr moderne Mikrocontroller und SoCs verfügen über sogenannte Networks-on-Chip oder NoCs. Diese auf dem Chip selbst integrierten Netzwerke kommen zunehmend zum Einsatz, wenn es darum geht, in hochkomplexen High-End-Mikrocontrollersystemen eine effiziente und flexible Datenübertragung auf dem Mikrocontroller, Prozessor oder SoC bzw. zwischen den einzelnen Kernen eines Multi- oder Manycore-Systems sicherzustellen.

Um zu gewährleisten, dass diese Datentransfers zwischen den Kernen störungsfrei und mit geringst möglicher Latenz ablaufen, ist es essentiell, diesen beim Testen und Debugging der Chips zu visualisiern, um sie genauer unter die Lupe nehmen zu können. Dies gestaltet sich aber oft schwerer als gedacht.

Um etwa die Leistung der Verbindung optimieren zu können, ist ein NoC in der Regel mit komplexen Komponenten und erweiterten Funktionen ausgestattet. Zusammen mit der Zunahme an Komplexität und Größe der Bausteine kann die Sicherstellung der funktionalen Korrektheit des NoCs eine besondere Herausforderung darstellen.

Um diese Vorgänge vernünftig testen und debuggen zu können, müssen Tools eingesetzt werden, deren Trace-Funktionalität auch diese Interconnects mit einschließt. UDE 5.2 erlaubt erstmals auch Datentransfers über Networks-on-Chip (NoC) zu beobachten. Parallel dazu kann selbstverständlich auch ein herkömmlicher Code-Trace eines oder mehrerer Cores durchgeführt werden. Damit erlaubt die UDE erstmalig die Bewertung des Gesamtsystemverhaltens dieser MCUs.

Für den Core-Trace kommt zudem eine speziell für die Arm CoreSight ETM v4 optimierte Trace-Analyse zum Einsatz, die eine intelligente Korrelation von zusammengehörendem Daten- und Instruktions-Trace bietet. Damit wird die folgende Auswertung der aufgezeichneten Trace-Daten durch den Anwender stark vereinfacht. Darüber hinaus stehen speziell für die Stellar-Familie nun auch die Trace-Funktionen für das Bosch Generic Timer Module (GTM) zur Verfügung.

RTOS-Tracing – nicht nur fürs High-End essentiell

Der Einsatz eines Echtzeitbetriebssystems (Real-Time Operating System; RTOS) fügt bestimmte neue Objekte zu Ihrer Entwicklung hinzu: Dazu zählen z.B. Tasks, Semaphores, Mutexes, Message Queues oder Timer. Um den Zustand des Systems während einer Debug-Sitzung zu verstehen, müssen Entwickler in der Lage sein, diese Objekte zu sehen. Nur so können sie nachvollziehen, was in dem System während der RTOS-Ausführung vor sich geht – ohne Visualisierung debuggen sie quasi im Blindflug.

Bild 2: In einem Echtzeitbetriebssystem wie FreeRTOS konkurrieren mehrere parallel laufende Tasks um vorhandene Ressourcen. Daraus resultierende Konflikte sind allein aus dem Quellcode nicht ablesbar, was Visualisierung unverzichtbar macht.
Bild 2: In einem Echtzeitbetriebssystem wie FreeRTOS konkurrieren mehrere parallel laufende Tasks um vorhandene Ressourcen. Daraus resultierende Konflikte sind allein aus dem Quellcode nicht ablesbar, was Visualisierung unverzichtbar macht.
(Bild: PLS)

Gerade kostengünstige Lösungen, die ein RTOS benötigen, greifen mittlerweile gerne auf FreeRTOS zurück. Das quelloffene Echtzeitbetriebssystem ist seit Kurzem auch für ARM-Cortex-basierte Mikrocontroller verfügbar, was die Open-source-Lösung für Entwürfe auf Basis der energieffizienten Architektur noch attraktiver gemacht hat. Für die Entwicklung von echtzeitkritischen Applikationen unter der Kontrolle von Echtzeitbetriebssystemen können in die UDE darüber hinaus Add-Ins für die RTOS-Awareness der aktuellen FreeRTOS- und SafeRTOS-Betriebssystemversionen eingebunden werden. Damit stehen Entwicklern alle notwendigen Informationen der Betriebssysteme in übersichtlicher Form zur Verfügung.

Automotive-Anwendungen ohne Gerätewechsel testen

Bei der Entwicklung von Automotive-Anwendungen, besonders bei Applikationen im Antriebsstrang, stehen Tester oft vor besonderen Herausforderungen. Neben den Debuggern für die Hardware-Plattformen kommen zusätzliche Mess- und Kalibrierungsgeräte zum Einsatz. Da diese Geräte sich in der Regel derselben Kanäle bedienen, stören oder behindern sich die Test- und Messgeräte in der Kommunikation und verfälschen die jeweiligen Ergebnisse. Das hat zur Folge, dass im Test- und Debug-Prozess oft mehrere Geräte abwechselnd zum Einsatz kommen, was Zeit und Ressourcen frisst.

Eine Lösung verspricht das „Universal Measurement and Calibration Protocol“ (XCP), das mittlerweile in Version 1.5 vorliegt und durch die „Association for Standardization of Automation and Measuring Systems“ (ASAM) als Associated Standard definiert wurde. Für die Entwicklung von Automotive-Anwendungen im Antriebsstrang bietet dieser Debug-Kanal den großen Vorteil, dass sowohl die UDE, als auch Mess- und Kalibrier-Werkzeuge ohne zusätzlichen Hardware-Aufwand gleichzeitig mit dem Steuergerät konfliktfrei kommunizieren können. Das zeitraubende Wechseln der Tools, die sonst auf dieselbe Debug-Schnittstelle am Steuergerät angewiesen waren, entfällt.

UDE 5.2: Welche MCU-Familien werden unterstützt?

Die Universal Debug Engine (UDE) von PLS hat in Version 5.2 die Unterstützung für eine Reihe neuer Hochleistungs-Mikrocontroller hinzugefügt. So werden beispielsweise für die Automotive-Multicore-MCUs der Stellar-Familie von STMicroelectronics nun auch Trace-Funktionen für Datentransfers zwischen den sechs Arm Cortex-R52 Cores, Spezial-CPUs und Peripherals unterstützt, die deutlich über das bisher verfügbare Arm CoreSight Debug- und Trace-System hinausgehen.

Ebenso besteht Support für weitere aktuelle Mikrocontroller. Dazu zählen unter anderem die neuen AURIX-Bausteine TC33 und TC36 von Infineon, die Hochleistungs-MCU STM32H7 und die neuesten Bausteine der SPC58 E-Linie Automotive Multicore Mikrocontroller von STMicroelectronics sowie neue Controller der RH850-Familie und der R-Car H3 SoC von Renesas sowie die gängigsten ARM-Cores.

(ID:46305572)