Gast
#256101
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.