Programmgesteuerte Einheiten wie Mikroprozessoren, Mikrocon- troller, Signalprozessoren etc. sind seit vielen Jahren in unzähligen Ausführungsformen bekannt.

Ein bekanntes Problem von programmgesteuerten Einheiten be- steht darin, daß darin auftretende Fehler häufig nicht ohne weiteres lokalisierbar und/oder behebbar sind.

Die Lokalisierung und Behebung von in programmgesteuerten Einheiten auftretenden Fehlern erfolgte früher und teilweise auch jetzt noch unter Verwendung spezieller Bond-Out-Versio- nen der zu untersuchenden programmgesteuerten Einheiten.

Bond-Out-Versionen von programmgesteuerten Einheiten unter- scheiden sich von den in Massenprodukten eingesetzten Stan- dard-Versionen der betreffenden programmgesteuerten Einheiten dadurch, daß sie mehr Ein-und/oder Ausgabeanschlüsse aufwei- sen, wobei die zusätzlichen Ein-und/oder Ausgabeanschlüsse mit in der Standard-Version der programmgesteuerten Einheit nicht frei zugänglichen Stellen der programmgesteuerten Ein- heit verbunden sind. Dadurch können Informationen über in- terne Zustände oder Vorgänge, genauer gesagt normalerweise nicht ausgegebene Adressen, Daten und/oder Steuersignale wie beispielsweise, aber bei weitem nicht ausschließlich der je- weils aktuelle Stand des Program Counter, aus der programm- gesteuerten Einheit ausgegeben und außerhalb der programm- gesteuerten Einheit ausgewertet werden. Durch die Auswertung der Informationen läßt sich der Verlauf der innerhalb der programmgesteuerten Einheit ablaufenden Vorgänge verfolgen, wodurch in der programmgesteuerten Einheit auftretende Fehler lokalisiert und behoben werden können.

Die Verwendung von Bond-Out-Versionen ist jedoch mit einer Reihe von Nachteilen verbunden. Insbesondere sind die Bond- Out-Versionen von programmgesteuerten Einheiten größer und teurer als die Standard-Versionen, und, was noch wichtiger ist, verhalten sich die Bond-Out-Versionen in der Regel nicht exakt so wie die Standard-Versionen.

Man ist daher teilweise dazu übergegangen, programmgesteuerte Einheiten mit Debug-Ressourcen auszustatten, welche aus der programmgesteuerten Einheit zur Fehlerlokalisierung und Feh- lerbehebung benötigte Informationen extrahieren und über eine nur wenige Pins umfassende und teilweise auch für andere Zwecke benutzbare Schnittstelle aus der programmgesteuerten Einheit ausgeben oder in dieser speichern.

Eine solche programmgesteuerte Einheit ist in Figur 2 darge- stellt.

Die in der Figur 2 gezeigte programmgesteuerte Einheit ist ein Mikrocontroller und enthält einen Core C, über einen er- sten Bus BUS1 mit dem Core C verbundene Peripherieeinheiten P1, P2, P3, über einen zweiten Bus BUS2 mit dem Core C ver- bundene Speichereinrichtungen S1, S2, S3, mit dem Core C in Verbindung stehende Debug-Ressourcen DR, und eine den Debug- Ressourcen DR zugeordnete Schnittstelle SS, über welche die Debug-Ressourcen DR an eine externe Einrichtung auszugebende Daten ausgeben, und über welche die Debug-Ressourcen DR von der externen Einrichtung gesteuert werden.

Die Peripherieeinheiten P1 bis P3 sind beispielsweise ein A/D-Wandler, ein Timer, ein Codierer, eine Komprimierungs- einrichtung, eine CAN-Schnittstelle, oder sonstige in Mikro- controller integrierbare Einheiten ; die Speichereinrichtungen sind beispielsweise ein RAM, ein ROM, und ein Flash-Speicher.

Die Debug-Ressourcen DR sind vorzugsweise in der Lage, soge- nannte Trace-Informationen auszugeben. Hierzu wird durch die Debug-Ressourcen DR das Auftreten von von außerhalb der pro- grammgesteuerten Einheit vorgebbaren Bedingungen innerhalb des Core der programmgesteuerten Einheit überwacht, und je- desmal, wenn die Bedingung oder eine der Bedingungen erfüllt ist, ohne eine Unterbrechung des Betriebes der programm- gesteuerten Einheit von außerhalb der programmgesteuerten Einheit vorgebbare Adressen, Daten und/oder Steuersignale aus der programmgesteuerten Einheit ausgegeben. Dadurch ist es beispielsweise, aber bei weitem nicht ausschließlich möglich, daß die Debug-Ressourcen DR jedesmal, wenn der Core Daten von einer bestimmten Adresse oder einem bestimmten Adreßbereich lesen möchte, die dem Core daraufhin zugeführten Daten aus der programmgesteuerten Einheit ausgeben.

Im allgemeinen führen die Debug-Ressourcen DR darüber hinaus auch noch weitere Aktionen aus, die für die Lokalisierung und Behebung von in der programmgesteuerten Einheit auftretenden Fehlern notwendig oder hilfreich sind. So sind die Debug- Ressourcen DR beispielsweise in der Lage, die programmge- steuerte Einheit beim Auftreten bestimmter Bedingungen, bei- spielsweise bei Erreichen eines bestimmten Program-Counter- Standes anzuhalten und die Inhalte von interessierenden Re- gistern auszulesen oder zu verändern.

Solche, auch als OCDS-Module bezeichneten Debug-Ressourcen sind bekannt, so daß auf die Beschreibung weiterer Einzelhei- ten verzichtet wird.

Aufgrund der zunehmenden Bedeutung des Vorsehens von Debug Ressourcen in programmgesteuerten Einheiten wurde von der IEEE Industry Standards and Technology Organization (IEEE- ISTO) in 1999 ein als"The Nexus 5001 Forum Standard for a Global Embedded Processor Debug Interface"bezeichneter Stan- dard für das Interface (die Schnittstelle SS) definiert, über welches die Debug-Ressourcen mit einer außerhalb der pro- grammgesteuerten Einheit vorgesehenen Einrichtung, beispiels- weise mit einer Debug-oder Emulations-Steuereinheit, oder mit einem Meßgerät wie etwa einem Logikanalysator auf beson- ders effiziente Art und Weise Daten austauschen können.

Die Debug-Ressourcen und das NEXUS-Interface ermöglichen es mit einem verhältnismäßig geringen Aufwand, in programm- gesteuerten Einheiten auftretende Fehler zu erkennen und zu beheben.

Nichtdestotrotz können der Aufbau und der Betrieb der Debug- Ressourcen DR vor allem bei komplexeren programmgesteuerten Einheiten, beispielsweise bei programmgesteuerten Einheiten mit mehreren Cores sehr aufwendig und kompliziert werden.

Problematisch ist hierbei insbesondere die Beschaffung und Ausgabe der Trace-Infomationen : es kann erforderlich sein, daß eine sehr große Menge an Trace-Informationen aus der pro- grammgesteuerten Einheit ausgegeben werden muß, um in der programmgesteuerten Einheit auftretende Fehler zu lokalisie- ren und zu beheben zu können, und darüber hinaus kann sich auch die Definition der Bedingungen, auf deren Auftreten hin Trace-Informationen auszugeben sind, als sehr kompliziert oder ganz unmöglich erweisen.

Der vorliegenden Erfindung liegt daher die Aufgabe zugrunde, eine Möglichkeit zu finden, durch welche die Menge der Trace- Informationen, die ausgegeben werden müssen, um in der pro- grammgesteuerten Einheit auftretende Fehler zu lokalisieren und zu beheben zu können, gering gehalten werden kann.

Diese Aufgabe wird erfindungsgemäß durch die in Patent- anspruch 1 beanspruchte programmgesteuerte Einheit gelöst.

Die erfindungsgemäße programmgesteuerte Einheit zeichnet sich dadurch aus, daß die auszugebenden oder zu speichernden Trace-Informationen und/oder der Zeitpunkt der Ausgabe oder der Speicherung der Trace-Informationen zumindest teilweise durch das von der programmgesteuerten Einheit ausgeführte Programm bestimmt werden.

Dies erweist sich in zweifacher Hinsicht als vorteilhaft : Einerseits können dadurch Trace-Informationen erhalten wer- den, die mangels Vorliegen von diese repräsentierenden Adres- sen, Daten und/oder Steuersignalen im Core oder mangels Zu- griffsmöglichkeiten darauf durch die bekannten Debug-Ressour- cen nicht ausgegeben werden könnten, und, wenn überhaupt, durch eine Auswertung von von den Debug-Ressourcen ausgegebe- nen Trace-Informationen ermittelt werden könnten, wobei die hierfür bereitzustellenden und auszuwertenden Trace-Informa- tionen einen beträchtlichen Umfang annehmen können. Beispiele für solche Informationen sind Zwischenergebnisse, oder die Anzahl der Durchläufe von keinen Schleifenzähler aufweisenden Schleifen, die Anzahl der Aufrufe eines bestimmten Unterpro- grammes etc.

Andererseits kann bei einer durch Befehle veranlaßten Ausgabe oder Speicherung von Trace-Informationen erreicht werden, daß Trace-Informationen ausschließlich während der Ausführung von Programmabschnitten ausgegeben oder gespeichert werden, in welchen der zu lokalisierende und zu behebende Fehler vermu- tet wird.

Durch die genannten Punkte kann erreicht werden, daß nur wirklich interessierende Trace-Informationen, und mithin auch nur die unbedingt erforderliche Menge an Trace-Informationen aus der programmgesteuerten Einheit ausgegeben oder in dieser gespeichert werden.

Die herkömmlichen oder sonstige Debug-Ressourcen können, müs- sen aber nicht zusätzlich vorgesehen werden. Wenn sie vorge- sehen sind, können sie einfacher aufgebaut sein und bedient werden als es bisher der Fall ist, da ja noch weitere Mög- lichkeiten bestehen, die Ausgabe oder Speicherung von Trace- Informationen zu veranlassen.

Vorteilhafte Weiterbildungen der Erfindung sind den Unter- ansprüchen, der folgenden Beschreibung und den Figuren ent- nehmbar.

Die Erfindung wird nachfolgend anhand von Ausführungsbeispie- len unter Bezugnahme auf die Figuren näher erläutert. Es zei- gen Figur 1 den Aufbau der im folgenden näher beschriebenen pro- grammgesteuerten Einheit, und Figur 2 den Aufbau der eingangs beschriebenen herkömmlichen programmgesteuerten Einheit.

Bei der im folgenden beschriebenen programmgesteuerten Ein- heit handelt es sich um einen Mikrocontroller. Die nachfol- gend beschriebenen Besonderheiten des Mikrocontrollers, ge- nauer gesagt die nachfolgend beschriebenen Besonderheiten der darin vorgesehenen Debug-Ressourcen lassen sich jedoch auch bei beliebigen anderen programmgesteuerten Einheiten ein- setzen.

Die im folgenden beschriebene programmgesteuerte Einheit ist schematisch in Figur 1 dargestellt. Der Vollständigkeit hal- ber sei darauf hingewiesen, daß nur die vorliegend besonders interessierenden Komponenten der programmgesteuerten Einheit gezeigt sind und beschrieben werden.

Die in der Figur 1 gezeigte programmgesteuerte Einheit ent- spricht nahezu vollständig der in der Figur 2 gezeigten pro- grammgesteuerten Einheit. Mit den gleichen Bezugszeichen be- zeichnete Komponenten sind identische oder einander entspre- chende Komponenten.

Der Vollständigkeit halber sei angemerkt, daß die Schnitt- stelle SS eine nach dem eingangs erwähnten NEXUS-Standard aufgebaute Schnittstelle ist. Es könnte sich jedoch auch um eine beliebige andere Schnittstelle handeln, beispielsweise um eine JTAG-Schnittstelle.

Die programmgesteuerte Einheit gemäß Figur 1 weist gegenüber der programmgesteuerten Einheit gemäß Figur 2 einen sehr we- sentlichen Unterschied auf. Dieser Unterschied besteht darin, daß die programmgesteuerte Einheit gemäß Figur 1 eine Verbin- dung zwischen dem Core C und der Schnittstelle SS aufweist.

Diese Verbindung ermöglicht es, daß der Core C der Schnitt- stelle SS Daten zuführen kann, die von der Schnittstelle SS wie von den Debug-Ressourcen DR an die Schnittstelle SS aus- gegebenen Daten behandelt werden, also in NEXUS-Messages um- gesetzt und aus der programmgesteuerten Einheit ausgegeben werden.

Die Datentransfers vom Core C zur Schnittstelle SS werden im betrachteten Beispiel durch entsprechende Befehle veranlaßt, die in das zu debuggende Programm (in das während der Unter- suchung der programmgesteuerten Einheit auszuführende Pro- gramm) eingefügt sind.

Die eingefügten Befehle können"normale"mov-Befehle, oder speziell für diesen Zweck vorgesehene Befehle sein.

Die Informationen, die durch diese Befehle zur Schnittstelle SS und von dieser weiter an eine außerhalb der programm- gesteuerten Einheit vorgesehene Einrichtung übertragen wer- den, können beliebige Informationen sein, die für das Erken- nen, Lokalisieren und/oder Beheben von in der programm- gesteuerten Einheit auftretenden Fehlern nützlich sind, also beispielsweise die Werte von bestimmten Variablen, oder Er- gebnisse oder Zwischenergebnisse von Berechnungen.

Die Messages, die durch die Schnittstelle SS aus den vom Core C zur Schnittstelle SS übertragenen Daten generiert und aus der programmgesteuerten Einheit ausgegeben werden, sind so aufgebaut, daß ihnen entnehmbar ist, welche Information die jeweiligen Daten repräsentieren, also beispielsweise ob die Daten den Wert einer Variablen A darstellen, oder eine be- stimmte Eigenschaft einer Variablen B, oder die Anzahl der Durchläufe einer Schleife, oder das wievielte Mal gerade ein bestimmtes Unterprogramm ausgeführt wird, usw.

Dies geschieht dadurch, daß die eigentlich auszugebenden Da- ten zusammen mit einem Code übertragen werden, der angibt, um welche Art von Daten es sich jeweils handelt. Im betrachteten Beispiel ist der Code 4 Bits lang ; er kann aber selbstver- ständlich auch länger oder kürzer sein.

Durch den 4 Bits umfassenden Code kann dem Empfänger der Message signalisiert werden, welche Bedeutung die eigentlich zu übertragenden Daten haben. Hierzu muß nur eine eindeutige Zuordnung zwischen den (im betrachteten Beispiel insgesamt 16 verschiedenen) Codes und der Bedeutung der zusammen mit die- sen Codes übertragenen Daten existieren. D. h., es muß bei- spielsweise festgelegt sein, - daß die Daten, die zusammen mit dem Code 0000 übertragen werden, den Wert einer Variable A darstellen, - daß die Daten, die zusammen mit dem Code 0001 übertragen werden, angeben, ob eine Variable B größer oder kleiner als ein bestimmter Schwellenwert ist, - daß die Daten, die zusammen mit dem Code 0010 übertragen werden, angeben, zum wievielten Mal gerade eine bestimmte Schleife durchlaufen wird, usw.

Mit welchem Code die der Schnittstelle SS vom Core C zuge- führten Daten aus der programmgesteuerten Einheit zusammen ausgegeben werden wird letztlich durch den Core C, genauer gesagt, durch den darin ausgeführten Befehl bestimmt, der den Datentransfer zu Schnittstelle SS veranlaßt.

Hierzu existieren zwei Möglichkeiten. Die erste Möglichkeit besteht darin, daß der Core C die eigentlich auszugebenden Daten zusammen mit einem die Bedeutung der Daten spezifizie- renden Code zur Schnittstelle SS überträgt, wobei der Code der selbe Code wie oder ein anderer Code als der Code sein kann, der den aus der programmgesteuerten Einheit ausgegebe- nen Daten beigefügt wird.

Die zweite Möglichkeit besteht darin, daß es von der Bedeu- tung der vom Core C an die Schnittstelle SS übertragenen Daten abhängig gemacht wird, an welche Stelle innerhalb der Schnittstelle SS die betreffenden Daten geschrieben werden.

In diesem Fall veranlaßt das Programm beispielsweise, - daß Daten, deren Inhalt der Wert einer Variable A ist, in ein Register XO der Schnittstelle SS transferiert werden, - daß Daten, deren Inhalt angibt, ob eine Variable B größer ist als ein bestimmter Schwellenwert, in ein Register X1 der Schnittstelle transferiert werden, usw.

Dann kann die Schnittstelle SS den Code bestimmen, der zusam- men mit den aus der programmgesteuerten Einheit auszugebenden Daten ausgegeben werden muß. Beispielsweise kann - den Daten, die im Register XO stehen, der Code 0000 beige- fügt werden, - den Daten, die im Register X1 stehen, der Code 0001 beige- fügt werden, usw.

Die Verwendung von Registern als Puffer für die vom Core C ausgegebenen Trace-Informationen erweist sich als vorteil- haft, weil dadurch keine zusätzlichen Datentransfers über die Systembusse BUS1 und BUS2 erfolgen müssen. Prinzipiell kann die Zwischenspeicherung der Trace-Informationen auch in einer beliebigen anderen Speichereinrichtung erfolgen, wobei diese Speichereinrichtung nicht zwangsläufig Bestandteil der Schnittstelle SS ist.

Die Messages, die die Schnittstelle SS aus den vom Core C er- haltenen Daten generiert und ausgibt, ist eine sogenannte vendor defined message, wobei im (6 Bits umfassenden) Header der Message festgelegt ist, um welche Art von Message es sich handelt, und wobei im Datenteil der Message die vom Core er- haltenen Daten und der die Bedeutung der betreffenden Daten angebende Code enthalten sind.

Durch die zumindest teilweise Festlegung der auszugebenden Trace-Informationen durch das von der programmgesteuerten Einheit ausgeführte Programm kann die Menge an Trace-Infor- mationen, die ausgegeben werden muß, um auftretende Fehler lokalisieren und beheben zu können, minimiert werden. Durch herkömmliche Debug-Ressourcen ist es entweder überhaupt nicht oder nur mit einem immensen Aufwand möglich, die ausgegebenen Trace-Informationen auf die Trace-Informationen zu beschrän- ken, deren Ausgabe bei der vorliegend beschriebenen programm- gesteuerten Einheit durch den Core C veranlaßt wird.

Darüber hinaus können die Bedingungen, unter welchen der Core C Trace-Informationen an die Schnittstelle SS übermittelt, beliebig komplex sein ; bei herkömmlichen programmgesteuerten Einheiten ist die Komplexität der Bedingungen, unter welchen aus der programmgesteuerten Einheit Trace-Informationen aus- gegeben werden, durch die Anzahl und die Verschaltung der in den Debug-Ressourcen vorhandenen Komparatoren und Vergleichs- masken beschränkt.

Unabhängig hiervon ermöglicht es die Trace-Informations-Gene- rierung durch den Core C, die Debug-Ressourcen zu vereinfa- chen. Insbesondere kann die Anzahl der für Adreß-, Daten-, und Steuersignalvergleich vorzusehenden Komparatoren und Ver- gleichsmasken reduziert werden. Sofern die Ausgabe von Trace- Informationen von komplexeren Bedingungen abhängig gemacht werden soll, kann die Trace-Informations-Generierung ja durch das von der programmgesteuerten Einheit ausgeführte Programm erfolgen.

Die Befehle, durch welche veranlaßt wird, daß während des Debuggens Trace-Informationen zur Schnittstelle SS übertragen werden, sind vorzugsweise auch in dem Programm enthalten, das auf der programmgesteuerten Einheit ausgeführt wird, wenn kein Debug-Vorgang stattfindet. D. h., das während des De- buggens ausgeführte Programm ist vorzugsweise genau das Pro- gramm, das auch im normalen Betrieb der programmgesteuerten Einheit ausgeführt wird. Dadurch kann erreicht werden, daß sich die programmgesteuerte Einheit während des Debuggens exakt so verhält wie es sonst der Fall ist.

Zusätzlich oder alternativ ist es auch möglich, daß durch das von der programmgesteuerten Einheit ausgeführte Programm "nur"die Bedingungen überprüft werden, unter welchen Trace- Informationen auszugeben oder zu speichern sind, und daß dann, wenn bei der Ausführung der die Bedingung überprüfenden Befehle festgestellt wird, daß die Bedingung erfüllt ist, die Debug-Ressourcen DR zur Ausgebe der in diesem Fall auszuge- benden Trace-Information veranlaßt werden.

Es ist ferner möglich, daß das vom Core C ausgeführte Pro- gramm"nur"festlegt, welche Trace-Informationen beim Eintre- ten einer bestimmten Bedingung auszugeben oder zu speichern sind, und daß die Debug-Ressourcen DR zur Ausgabe dieser In- formationen veranlaßt werden. Dabei kann die Überprüfung der Bedingung, unter welcher die Ausgabe dieser Trace-Information zu erfolgen hat, entweder durch die Debug-Ressourcen DR oder durch das vom Core C ausgeführte Programm (oder durch eine sonstige Einrichtung) erfolgen.

Vorzugsweise ist der Core C so aufgebaut, daß für die Ausfüh- rung der Befehle, die die Übertragung von Trace-Informationen zur Schnittstelle SS veranlassen, keinen eigenen Taktzyklus benötigen. Dies kann beispielsweise dadurch geschehen, daß für diese Befehle eine eigene Ausführungseinheit reserviert ist.

Als vorteilhaft kann es sich auch erweisen, wenn in der Schnittstelle SS überwacht wird, ob die Speichereinrichtun- gen, in welche der Core C und/oder die Debug-Ressourcen die aus der programmgesteuerten Einheit auszugebenden Trace- Informationen schreiben, überlaufen (ob noch nicht ausgege- bene Trace-Informationen durch neue Trace-Informationen über- schrieben werden oder neue Trace-Informationen mangels Mög- lichkeiten zur Speicherung nicht angenommen werden können.

Wenn festgestellt wird, daß dies geschieht oder zu geschehen droht, werden vorzugsweise Maßnahmen ergriffen, die dies ver- hindern oder die externe Einrichtung, an welche die Trace- Informationen (die diese enthaltenden Messages) ausgegeben werden hiervon in Kenntnis setzen. Dies kann beispielsweise dadurch geschehen, - daß der Core angehalten wird, wenn die besagten Speicher- einrichtungen nicht mehr aufnahmefähig sind, oder - daß an die externe Einrichtung eine Fehlermeldung ausgege- ben wird, durch welche signalisiert wird, daß Trace-Infor- mationen verloren gegangen sind.

Im letztgenannten Fall könnte vorgesehen werden, der exteren Einrichtung die Anzahl und die Art der Trace-Informationen mitzuteilen, die verloren gegangen sind.

Die programmgesteuerte Trace-Informations-Generierung erfor- dert es nicht, daß zusätzlich Debug-Ressourcen DR vorhanden sind. Gleichwohl wird es sich jedoch im allgemeinen als vor- teilhaft erweisen, wenn die programmgesteuerte Einheit Debug- Ressourcen enthält. Diese Debug-Ressourcen können aber ein- facher und kleiner aufgebaut werden als Debug-Ressourcen in herkömmlichen programmgesteuerten Einheiten (ohne programm- gesteuerte Trace-Informations-Generierung).

Durch die programmgesteuerte Trace-Informations-Generierung ist es unabhängig von den Einzelheiten der praktischen Reali- sierung mit geringem Aufwand möglich, die Menge der Trace- Informationen, die ausgegeben werden muß, um in der programm- gesteuerten Einheit auftretende Fehler zu lokalisieren und zu beheben zu können, gering zu halten.

Bezugszeichenliste C Core DR Debug-Ressourcen Px Peripherieeinheiten SS, Schnittstelle Sx Speichereinrichtungen