Probleme mit INT0 und Mega644

Hallo Stefan,

vielen Dank für den Hinweis. Bei der Migration zum 644 hatte ich das mit 
den symbolischen Bitnamen bedacht. Seit einiger Zeit habe ich noch eine 
Debug-Routine mit eingebaut, die mir die relevanten Register des 644 und 
auch des MCP auf dem eDip ausgibt. Selbst im Falle des "nicht zurück 
gesetzten INT0" sind die Inhalte der Register wie erwartet. Mir ist 
klar, dass die Ausgabe auf dem Display nicht unbedingt den 
Registerinhalt zum Zeitpunkt des "nicht zurücksetzens" beinhaltet (ich 
lese die Register zyklisch aus). Wenn ich nur eine Möglichkeit finden 
würde das Verhalten zu stimulieren oder wenigstens darauf zu triggern, 
dann könnte ich mit dem Logic auf die Signale losgehen.

Viele Grüße

Volker

Hallo Stefan,

>1/ Der MCP2515 ist mit seinem /INT Ausgang dem Eingang INT0 vom
>Atmega644 verbunden. Pullups? Pulldowns? Der '644 nutzt die INT0 ISR für
>eine SPI Kommunikation zum MCP um über den MCP eine CAN Kommunikation
>abzuwickeln.

Das ist soweit richtig. Ich verwende den internen Pullup des 644, einen 
externen hatte ich schon versucht, brachte aber keine Änderung

>2/ Der '644 reagiert auf Level LOW (richtig)? Flanke-DOWN?

Der INT0 ist als edge triggerd (low) konfiguriert

>3/ Es kommt vor, dass die CAN Kommunikation ausfällt. In diesem Fall
>wird beobachtet, dass die MCP---644 Leitung LOW ist.

Das ist so richtig

>4/ Obwohl die MCP---644 Leitung LOW ist, ist das INTF0 Flag in EIFR 0,
>d.h. es ist kein Interrupt aufgetreten.
>Heisst das in 2/ ist INT0 auf Level LOW getriggert und die INT0 ISR wird
>seltsamerweise nicht angesprungen?
>Oder heisst das in 2/ ist INT0 auf Flanke getriggert und die INT0 ISR
>wird bei Dauer-LOW ganz zu recht nicht angesprungen?

Ich vermute, dass die ISR angesprungen wird, die Interrupt-Leitung aber 
nicht mehr frei gegeben wird. In diesem Fall würde etwas mit dem 
Rücksetzen des Interruptbits im MCP schief gehen. Das würde zumindes das 
Verhalten erklären, dass ich von dem Zeitpunkt an keine weiteren CAN 
Botschaften über den MCP empfangen kann.

>5/ Das Setzen der MCP---644 Leitung ist Aufgabe des MCP. Das Versagen
>des MCP kann nicht aus den MCP-Registern erschlossen werden

Ich kann dadurch immerhin ausschliessen, dass es sich um einen bus-off 
handelt. Das CANINTF Register des MCP zeigt mir zu diesem Zeitpunkt auch 
nicht an, dass ein Interrupt noch pending ist. => Kapitel 7.7 "Once an 
interrupt flag is set by the device, the flag cannot be reset by the MCU 
until the interrupt condition is removed."

>6/ Ein manueller HIGH seitens des '644 bringt den MCP zurück ins Spiel.
>Wurde bereits ein Pullup an der Leitung getestet?

Ja, leider ohne Erfolg. Der Aufbau mit dem Mega32 nutzt auch keinen 
externen Pullup.

>7/ /INT wird vom MCP beim Senden in zwei Fällen benutzt (Figure 3-1) und
>beim Empfangen in drei Fällen (Figure 4-3). Teilweise hängen die Fälle
>von der Konfiguration des MCP und teils von erfolgreichem
>Senden/Empfangen ab.
>Ändert sich die Situation, wenn der MCP anders konfiguriert wird (nur
>/INT beim erfolgreichen Senden (genauer: Sendepuffer leer!)/Empfangen)?

Ich gehe davon aus, dass ich die Sendeseite nicht weiter betrachten 
muss, da diese nicht mit Interrupts arbeitet. Der Versand von 
Nachrichten funktioniert auch weiterhin wie gewohnt.

Meine Empfangsroutinen habe ich bislang nicht umkonfiguriert. Der MCP 
nutzt keine Filter, roll-over von RXB0 nach RXB1 ist erlaubt. Eine 
Änderung der Routinen auf Polling habe ich noch nicht getestet.

>8/ Wenn der MCP einen /INT ausgelöst hat, müssen die dazugehörigen
>Interruptbits gelöscht werden "INT pin is driven low by the MCP2515 and
>will remain low until the interrupt is cleared by the MCU"
>(Beitrag "CAN mit ATMega128 und MCP2515")
>Vielleicht einen Fall aus 7/ vergessen?

Wahrscheinlich habe ich irgend etwas vergessen, übersehen, nur ins Auge 
springen mag es mir noch nicht. Wenn beispielsweise ein roll-over von 
RBX0 nach RBX1 stattfindet und bereits ein Interrupt ausgelöst, die 
Botschaft aber noch nicht abgeholt wurde, dann würde der Interrupt 
"stehen" bleiben, solange bis RBX0 und RBX1 ausgelesen sind und die 
beiden Flags im Register zurück gesetzt wurden. Diesen Fall habe ich 
bedacht. Es muss die Kombination aus mehreren Ereignissen sein, die in 
einem sehr kleinen Zeitfenster zusammentreffen müssen... und irgendwie 
spielt da die SPI Kommunikation zum eDIP auch eine Rolle. Es gibt 
zyklische Ausgaben auf dem eDIP, die natürlich dann auch immer die SPI 
belegen...

Soweit mal für heute, (oder doch schon gestern??) :)

viele Grüße

Volker

Hallo Stefan,

nochmals vielen Dank für Deine Antwort. Besonders der Hinweis mit dem 
ICOD hat mich vielleicht auf eine Spur gebracht. Ich werde am nahenden 
Wochenende nochmals meinen CAN Treiber reviewen.

Ich geb Dir dann Bescheid!

Viele Grüße

Volker