|
Anzeige
|
Ermittlung der interrupt vector nr im ISR default handlerHallo zusammen, ich arbeite mit dem ATXmega256 und versuche zu debug Zwecken einen nicht implementierten Interrupt abzufangen und die Info auszugeben.
Ich würde gerne die interrupt vector table nr des Verursachers ermitteln. Kann man feststellen um welchen interrupt es sich handelt? Mfg, Andy
Gast
#3014182
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. Alternativ: Alles IRQ Bits abklappern und speichern/ausgeben. Aber exakt ist das nicht, wenn zeitnah zwei Interrupts aktiv werden. 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. 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. ... 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. @ 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 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. 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 ? Andreas K. schrieb: > ge-merded Lustiger Schreibfehler merge (engl.) verschmelzen merde (franz.) ..... 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'. :-)
Gast
#3015698
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 Antwort schreiben |
Anzeige
|
