CAN-Bus Filtern klappt nicht - MCP2515/PIC18F

[Ingo F. (ingof)]

Hallo,

ich habe Problem mit meinem PIC18F2680. Das Versenden und Empfangen von 
Nachrichten klappt problemlos.

Jetzt wollte ich mich an den Filter machen. Nach dem Datenblatt bestimmt 
das Maskenbit darüber ob das ID-Bit geprüft wird oder nicht. Wenn das 
also auf "1" steht wird überprüft ob das Filter-Bit und das ID-Bit in 
der Adresse übereinstimmt.

Also wenn ich in den Filter-Bytes das selbe stehen habe wie im der 
Empfangenden ID könnte ich alle Maskenbits auf "1" setzen.

Seltsamerweise klappt das aber nicht.

;; RX filter 0    
;#define  CAN_RXF0SIDH  b'00000001'  ;0x01
;#define  CAN_RXF0SIDL  b'00100011'  ;0x23
;#define  CAN_RXF0EIDH  b'00000101'  ;0x05
;#define  CAN_RXF0EIDL  b'00000000'  ;0x00

; RX mask 0  
;#define  CAN_RXM0SIDH  b'11111111'
;#define  CAN_RXM0SIDL  b'11100011'         ;irgnore SRR, EXIDE and unimplemented Bit
;#define  CAN_RXM0EIDH  b'11111111'
;#define  CAN_RXM0EIDL  b'11111100'         ;ignore lowest two Bits for GET/Put and Command/Data
#define    CAN_RXM0SIDH  b'11100010'
#define    CAN_RXM0SIDL  b'00000000'         ;irgnore SRR, EXIDE and unimplemented Bit
#define    CAN_RXM0EIDH  b'11111011'
#define    CAN_RXM0EIDL  b'00111100'         ;ignore lowest two Bits for GET/Put and Command/Data

der ober auskommentierte Block ist die Filtermaske die ich gerne hätte.
Die drei Nullen in RXM0SIDL sind das Extendet-ID-Bit und zwei unbenutze 
Bits. In RXM0EIDL die letzten beiden Bits werden zur Adressierung der 
Daten benutzt. Das ist der CAN-Bootloader AN247 von Microchip.

seltsamerweise kann ich höchsten die Maske benutzen die im nicht 
auskommentierten Block darunter ist. Sobald ich eine "1" mehr in der 
Maske setze werden die Nachrichten trotzdem herausgefiltert.

Habe auch mal mitgetraced. Die Standart-ID und Extended-ID werden auch 
so auf den Bus gesendet wie sie sollen.

Die Register für zum Senden und Filtern habe ich mit 0x01230500 
beschrieben. Wenn ich die Standard-ID wegen der EXID und andern zwei 
anderen unbenutzten Bits nach rechts schiebe entspricht das der 
"Adresse" 0x00270500. Diese Adresse wir auch auf dem CAN-Bus mitgeloggt.

Auf der Empfangseite lass ich mir auch vorher noch mal die jeweiligen 
Register über die Serielle Schnittstelle ausgeben. Die haben auch die 
selben Werte wie die Register der gesendeten IDs.

Hat jemand eine Erklärung dafür warum die Filterung nicht wie erwartet 
funktioniert?

Gruß
Ingo

[Stefan R. (kroko)]

Hallo Ingo,

hier fehlen noch einige Angaben um genaueres zu sagen.
(z.B.: welcher Mode des CAN Moduls wird verwendet)
Aber soweit ich das sehe:
Bei dir ist EXIDE/EXIDEN immer auf 0

Wenn du Mode 0 verwendest:
Wird EXIDEN in RXM0 nicht berücksichtigt
EXIDEN in RXF0 ist 0 und daher werden nur Standard IDs akzeptiert
Beim Sender das selbe, also wird eine Standard ID gesendet
         SIDH      SIDL
Sender   00000001  00100011
RXM0     11100010  00000000
RXF0     00000001  00100011

auskommentierte Maske:
         SIDH      SIDL
Sender   00000001  00100011
RXM0     11111111  11100011
RXF0     00000001  00100011

Wenn Mode größer 0 (1 oder 2):
EXIDEN in RXM0, Standard und Extended werden akzeptiert
EXIDEN in RXF0, bei EXIDEN 0 in RXM0 egal
Beim Sender wie Mode 0

Obwohl beim Sender EXIDE auf 0 mit Extended Bits
         SIDH      SIDL      EIDH      EIDL
Sender   00000001  00100011  00000101  00000000
RXM0     11100010  00000000  11111011  00111100
RXF0     00000001  00100011  00000101  00000000

auskommentierte Maske:
         SIDH      SIDL      EIDH      EIDL
Sender   00000001  00100011  00000101  00000000
RXM0     11111111  11100011  11111111  11111100
RXF0     00000001  00100011  00000101  00000000


Wenn ich mich nicht täusche, sieht das eigentlich recht gut aus.
Interessant wären die Register (RXM0, RXF0, betroffene Empfangsbuffer) 
und auch auf der Senderseite die Register mit Debugger oder per 
Serielle, vielleicht passiert da irgendwas.

Mfg Stefan

[IngoF (Gast)]

Hallo Stefan

hatte den Fehler gestern gefunden.

Ich verwende den Mode 0 weil der Bootloader auch schon den Mode 0 
verwendet.

Die Masken sind alle OK. Jetzt läuft es.

Es waren natürlich mehrere Fehler.....

Die Bootloaderfirmware hatte ich damals auf einen 18F258 gebrannt und 
fehlerfrei getestet.
Jetzt habe ich den selben Quellcode auf einen 18F2680 gebrannt und es 
gibt nur Probleme.

Die ganzen Zugriffe wurden über MOVWF RXM0SIDH gemacht und es werden 
seltsamerweise die falschen Werte gelesen. Die Register liegen im RAM 
von 0x00 bis 0x12 und sollten somit in der AccessBank liegen. Habe dann 
nochmal explizit die Accessbank bei MOVWF eingefügt (MOVWF 
RXM0SIDH,ACCESS). Das hat allerdings auch nicht gebracht.
Erst das Ändern auf MOVFF WREG,RXM0SIDH schaffte abhilfe.
Dummerweise gibt es noch ein paar BTFSS-Befehle die nicht funktionieren.

Also hilft es nur noch den Fehler zu finden/verstehen warum MOVWF nicht 
funktioniert oder eben den Quellcode umschreiben.

Vorher habe ich den Extended-Mode vom PIC verwendet. Das könnte eine 
Erklärung sein. Allerdings verlief der Test mit dem Standart-Befehlssatz 
vom PIC genauso in die Hose....

Gruß
Ingo

[Stefan R. (kroko)]

IngoF schrieb:
> Die ganzen Zugriffe wurden über MOVWF RXM0SIDH gemacht und es werden
> seltsamerweise die falschen Werte gelesen. Die Register liegen im RAM
> von 0x00 bis 0x12 und sollten somit in der AccessBank liegen. Habe dann
> nochmal explizit die Accessbank bei MOVWF eingefügt (MOVWF
> RXM0SIDH,ACCESS). Das hat allerdings auch nicht gebracht.
> Erst das Ändern auf MOVFF WREG,RXM0SIDH schaffte abhilfe.
> Dummerweise gibt es noch ein paar BTFSS-Befehle die nicht funktionieren.

Das sollte aber keine Probleme machen.
Welche Register liegen von 0x00 bis 0x12 im RAM?
Ist MOVFF nicht für das Kopieren von einer RAM-Zelle in die andere 
gedacht und nicht vom WREG in eine RAM-Zelle?

[IngoF (Gast)]

So, Fehler gefunden.

Es ist der Extended Mode gewesen.
Irgendwo im Quelltext wurde das XTINS-Bit zusätzlich gesetzt.

Das hat man davon wenn man den Quelltext aus anderen Projekten klaut.

Verstehe nur nicht warum der MOVWF Befehl nicht mehr funktioniert.
Habe mal testweise FSR2 auf 0 gesetzt. Demnach müsste ich ja wieder auf 
dem richtigen SFR liegen.

Gruß
Ingo