LPC2138 Interrupt Problem

[roty (Gast)]

Hallo,

Ich habe ein Problem mit dem Interrupt des LPC2138.

Ich benutze den LPC2138 zusammen mit einem Wiznet NM7010A ETH-Modul
in einem größeren Projekt.

Mein Problem hängt mit der Interruptverarbeitung des LPC2138 zusammen.
Es äussert sich so, dass die Ethernet-Kommunikation minutenlang ohne
Problemem läuft, jedoch hängt sich das ganze System ganz sporadisch auf
.

Ich habe herausgefunden, dass der NM7010A Interrupt, der am EXTINT0 am
LPC2138 angeschlossen ist, dann nicht mehr funktioniert, wenn er in der
Umgebung der Instruction

VICIntEnClear = INT_EXT0;          // disable interrupt

oder einer verwandten Instruktion auftritt. Das äussert sich dann so,
dass der LPC2138 den Interrupt irgendwie schon noch einmal annimmt,
aber anscheinend irgend etwas anders ausführt als er soll (was ich aber
nicht ermitteln kann). Nach einigen hundert Microsekunden wird dann
irgendwie in meine Application zurückgekehrt und verstellt
unkontrolliert das Interface zum MN7010A, sodass dieser den Interrupt
nicht mehr rücksetzen kann.

Ich konnte das mit Hilfe eines Timinganalyzers und der
Instrumentaliserung des Programm zu diesem Zweck, eindeutig dem LPC2138
zuordnen.

Kann es sich jemand erklären wie das zustande kommt, was der LPC2138 in
der unkontrollierten Zeit nach Annahme des besagten Interrupts macht und
hat jemand eine Idee dazu wie man das verhindern kann ?

Ich habe zwar etwas über "Spurious Interrupts" im Datenblatt des
LPC2138 gelesen, weiss aber nicht ob das in diesem Fall zutrifft.
Einen Spurious Interrupt Vector gibt es ja nicht beim LPC2138 im
Gegensatz zu anderen ARM7 Derivaten. Das Sperren des globalen
Interrupts vor dem Sperren des spezifischen Interrupts (und umgekehrt)
habe ich schon probiert, hilft aber nix.

Hat jemand schon ähnliche Erfahrungen gemacht und ggf. eine Lösung
dafür ?

Jeder sachdienliche Hinweis ist willkommen.

Vielen Dank.

[A.K. (Gast)]

"Einen Spurious Interrupt Vector gibt es ja nicht beim LPC2138 im
Gegensatz zu anderen ARM7 Derivaten."

Deine Beschreibung passt exakt zu dem erwähnten Thema "Spurious
interrupts" im Philips Manual. Der Prozessor kriegt einen IRQ ab, aber
noch bevor er den VIC fragt, ist dort der betreffende Interrupt schon
abgeschaltet. Folge: der VIC liefert den VicDefVectAddr. Das ist
irgendwie auch der von dir gesuchte Spurious Interrupt Vector.

[roty (Gast)]

@A.K.

Danke für den Hinweis. Das wusste ich gar nicht dass VicDefVecAdr
sozusagen als Sammelinterrupt auch für Spurious Interrupts fungiert.
Erste Versuche zeigen, dass es anscheined der richtige Hinweis war.
Muss es aber noch weiter untersuchen.

Danke jedenfalls nochmals.

[mthomas (Gast)]

Falls nicht ohnehin schon so gemacht: Moeglicherweise ist die
Initialisierung des ext.-Int. als "FIQ" eine Loesung. Im
Exceptions-Vector dann die Adresse der "ext.-Int.-ISR" eintragen.
Keine weitere Quelle als FIQ, nur der Modul-Int. Falls es damit
funktioniert, spart dies die Rechenzeit zur zusaetzlichen Auswertung
der Interruptursache in einer default-ISR.