Startseite > Automotive > Software + Tools > Multi-Core-MCUs effizient debuggen

Aufbruch in eine neue Debug-Dimension

Multi-Core-MCUs effizient debuggen

25. Mai 2012, 13:25 Uhr | Von Jens Braunes

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 2

Kein übergreifender Zeitbezug für Multi-Core-Systeme

Treten solche Fehlerbilder auf, kommt der Debugger ins Spiel. Der Entwickler will sehen, mit welchen Speicherinhalten die Tasks arbeiten oder was welche CPU gerade ausführt. Konkret geht es in beiden Fällen darum, den Zustand des Gesamtsystems bzw. der beteiligten Tasks zu einem bestimmten Zeitpunkt zu betrachten. Doch hier liegt das Problem: Für ein Multi-Core-System gibt es in der Regel keinen allübergreifenden Zeitbezug.

Da jeder Prozessorkern mit unterschiedlicher Taktung laufen kann, ist es mehr als fraglich, ob das Anhalten aller CPUs – Grundlage des traditionellen Stop-&-go-Debuggings – ausreichend synchron ist. Der Zeitversatz, mit dem zwei oder mehr CPUs den Halt-Zustand erreichen, hängt nämlich von den verfügbaren Möglichkeiten der Core-übergreifenden Signalisierung ab (Bild 3). Je nachdem, wo die Signalisierung angestoßen wird, können für manche Anwendung inakzeptable Latenzzeiten entstehen. Im Falle eines gesetzten Breakpoints in einem Prozessorkern und der Signalisierung entweder durch den Debugger oder im Access Device kann unter Umständen die Systemsicht nach Erreichen des Halt-Zustandes aller Prozessorkerne komplett aus dem Kontext des Breakpoints gelaufen sein. Einzig eine spezielle Debug-Hardware auf dem Chip, die ein sogenanntes Cross-Triggering zwischen allen CPUs zulässt, ermöglicht ein nahezu synchrones Anhalten. In den neuen Multi-Core-Controllern von Infineon wurde deshalb die bereits aus den anderen TriCore-Controllern bekannte OCDS-Einheit (On-Chip Debug System) um einen neuen Trigger-Switch erweitert, der genau das tut. Abhängig von den eingestellten Taktraten der einzelnen CPUs kann so die Ausführung auf den einzelnen TriCore-Kernen bzw. dem Timer-Modul taktsynchron oder mit nur wenigen Takten Verzögerung unterbrochen werden.

Abgesehen von der Synchronität des Stop-&-go-Debuggings in einem Multi-Core-System stellt sich noch eine ganz andere Frage: Was erwartet der Entwickler eigentlich, wenn er einen Breakpoint setzt oder einen Single-Step ausführt? Bisher gab es dazu keinen Diskussionsbedarf. Bei mehreren Prozessorkernen und mehreren nebenläufigen Tasks hingegen ist es schon wichtig zu wissen, wie sich ein Break oder Single-Step auswirken soll. Beim Debugging eines einzelnen Tasks kann es nützlich sein, wenn beim Breakpoint nicht das komplette System, sondern nur die jeweilige CPU anhält. Mitunter ist es aber auch vorteilhafter, wenn alle Prozessorkerne oder eine bestimmten Gruppe angehalten werden. Stehen dann mehrere CPUs und man will einen Single-Step auf einem Prozessorkern ausführen, ist obendrein unklar, was dieser Single-Step für die anderen Kerne bedeutet. Heterogene CPUs mit verschiedenen Taktfrequenzen oder Pipeline-Architektur benötigen für die Ausführung jeweils eines Befehls durchaus unterschiedlich lange. Damit besteht also die Gefahr, die Synchronität zu verlieren. Der Debugger muss also entsprechende Vorkehrungen treffen und dem Anwender die Möglichkeit bieten, sowohl einen einzelnen Prozessorkern als auch mehrere Kerne in einer Gruppe zu debuggen.

Die Firma PLS hat sich dieser Herausforderung angenommen und ein spezielles Multi-Core-Run-Control-Mangement in ihre Universal Debug Engine (UDE) integriert. Mit Hilfe dieser Funktionseinheit ist es möglich, einzelne CPUs zu sogenannten Core-Gruppen zusammenzufassen und synchron zu steuern. Der Anwender kann das Verhalten bei einem Break, Go oder Single-Step der CPUs in der jeweiligen Gruppe präzise festlegen, so dass immer eine synchrone Ablaufsteuerung garantiert ist.