Ermittlung der interrupt vector nr im ISR default handler

[Andreas K. (andrz)]

Hallo zusammen,

ich arbeite mit dem ATXmega256 und versuche zu debug Zwecken einen
nicht implementierten Interrupt abzufangen und die Info auszugeben.

// catch unexpected interrupt
ISR(__vector_default) 
{
  // todo: eval vector nr ? 
  int vecNr = ...?

  // debug output via uart on hyperterminal
  logText( "Error: Vector Source: %d", vectNr );

  while( 1 ); // stop
}

Ich würde gerne die interrupt vector table nr des Verursachers 
ermitteln.
Kann man feststellen um welchen interrupt es sich handelt?

Mfg,
Andy

[Peter II (Gast)]

Andreas K. schrieb:
> Kann man feststellen um welchen interrupt es sich handelt?

nein, dafür gibt es meines wissens im AVR keine möglichkeit.

Warum nicht einfach für jeden ISR eine funktion schreiben, dann gibt es 
auch keine unbekannten ISR mehr.

[Falk B. (falk)]

Alternativ: Alles IRQ Bits abklappern und speichern/ausgeben. Aber exakt 
ist das nicht, wenn zeitnah zwei Interrupts aktiv werden.

[Jörg W. (dl8dtl) (Moderator)]

Dafür benutzt man den Befehl COME FROM. :-)

Nein, standardmäßig geht das nicht.  Entweder mit einem kleinen
Script alle unbelegten Vektoren ermitteln und dann kleine Stubs
schreiben lassen, die die Vektornummer in einer globalen Variablen
hinterlegen.

Alternativ eine Kopie von gcrt1.S ziehen und in dein Projekt mit
einbinden.  In dieser Kopie machst du einen CALL statt eines JUMP,
und in der gerufenen Routine ermittels du die Rückkehradresse auf
dem Stack.

[Stefan E. (sternst)]

Falk Brunner schrieb:
> Alternativ: Alles IRQ Bits abklappern und speichern/ausgeben.

Was soll das bringen? Bei den meisten Interrupts ist das Flag zu dem 
Zeitpunkt bereits wieder gelöscht.

[Karl H. (kbuchegg)]

... und im Regelfall auch nicht notwendig.

Denn man schreibt sowieso kein Programm als monolithischen Klotz, der 
das erste mal getestet wird, wenn die 5000 Zeile Marke erreicht ist.

Arbeitet man sich sukzessive von 0 weg die Leiter hinauf, in dem man 
Modul um Modul hinzufügt und möglichst bald mit Testen anfängt, dann ist 
der nicht behandelte Interrupt praktisch immer im Zusammenhang mit der 
zuletzt hinzugefügten Komponente in Verbindung zu bringen. D.h. in der 
Praxis ist es nicht so schlimm, wie es zuerst scheint. Man weiß schon 
ziemlich genau, welche Interrupts für den Fehler in Frage kommen.

[Falk B. (falk)]

@  Stefan Ernst (sternst)

>> Alternativ: Alles IRQ Bits abklappern und speichern/ausgeben.

>Was soll das bringen? Bei den meisten Interrupts ist das Flag zu dem
>Zeitpunkt bereits wieder gelöscht.

Oh, stimmt! :-0

[Andreas K. (andrz)]

Es geht mir nur um die Möglichkeit einer weiteren Debug Information.

Es könnte vom Nutzen sein, z.B. falls zwei grössere Projekt-branches 
ge-merded werden müssen und es dabei zu Fehlern kommt, die zur laufzeit 
auftreten. Dafür sollte es eine generische Lösung geben, ohne jeden 
vector handler zu definieren.

Vor allem aber wollte ich einfach erfahren, ob der XMega grundsätzlich 
die Möglichkeit bietet. In der Spec habe ich nichts gefunden :-(
Eigentlich bin ich davon Ausgegangen, dass die vector nr info in einem 
Register abgelegt ist.

[Frank W. (Firma: DB1FW) (frankw)]

Nur so eine Idee. Ich kenne den Prozessor nicht.

Wie ist das beim ATXmega256 ?

Kann man in der Interrupt Tabelle statt JMP __vector_default  ein
CALL __vector_default  eintragen ?
Dann steht im Stack wo er herkommt ?

[Route_66 H. (route_66)]

Andreas K. schrieb:
> ge-merded

Lustiger Schreibfehler
merge (engl.) verschmelzen
merde (franz.) .....

[Ralf G. (ralg)]

Route 66 schrieb:
> Andreas K. schrieb:
>> ge-merded
>
> Lustiger Schreibfehler
> merge (engl.) verschmelzen
> merde (franz.) .....

Vielleicht setzt sich das ja durch? Klingt vornehmer, als 
'verscheißert'. :-)

[Bronco (Gast)]

Andreas K. schrieb:
> Ich würde gerne die interrupt vector table nr des Verursachers
> ermitteln.
> Kann man feststellen um welchen interrupt es sich handelt?

Gegenfrage: Wer sollte diesen Interrupt freigeben?

Mein Ansatz wäre:
Das IEN (Interrupt Enable) in einer Methode kapseln.
Die Methode und die zugehörige ISR (Interrupt Service Routine) gehören 
in ein Modul, welches die HW-Funktion (UART, SPI, Timer etc.) kapselt.
-> Ohne Modul kein IEN
-> Mit Modul hat's auch immer die ISR

Ausnahme:
Traps und Non Maskable Interrupt (NMI)
-> Diese immer implementieren