CAN filtering: Error in reasoning?

Please read careful.

Hi guys,
I'm fiddling with the message IDs.

This example I used from the datasheet. It is actually a 29bit example but the situation is the same (really?):

Data goes from CAN 0 to CAN 1.

IDs to filter:
000100 0 11 00 ID0 = 0x08C
000100 0 11 01 ID1 = 0x08D
000100 0 11 10 ID2 = 0x08E
000100 0 11 11 ID3 = 0x08F
000100 1 11 00 ID4 = 0x09C
000100 1 11 01 ID5 = 0x09D
000100 1 11 10 ID6 = 0x09E
000100 1 11 11 ID7 = 0x09F

The cooking recipe from the datasheet:

The CAN_MIDx (Message ID Nr.x) and CAN_MAMx (message acceptance mask
Nr.x) of Mailbox x must be initialized to the corresponding values:
CAN_MIDx = 000 100 x 11 xx = 0x08C
CAN_MAMx = 111 111 0 11 00 = 0x7EC
Ok, got it.

Next:
If Mailbox x receives a message with ID6, then CAN_MIDx and CAN_MFIDx
are set:
CAN_MIDx = 000 100 1 11 10 = 0x09E //ID6
CAN_MFIDx = 000 000 0 01 10 = 0x006 //Family ID
Ok.

    /* Init CAN1 Mailbox 0 to Reception Mailbox. */    
    //  CAN_MIDx  = 000100 x 11 xx = 0x08C, message ID example no. 6
    //  CAN_MAMx  = 111111 0 11 00 = 0x7EC, message acceptance mask  
    //  CAN_MFIDx = 000000 0 01 10 = 0x006, family filter ID
    
    // lets roll
    reset_mailbox_conf(&can1_mailbox);
    can1_mailbox.ul_mb_idx = TEST7_CAN_COMM_MB_IDX; //Mailbox select : no.0
    can1_mailbox.uc_obj_type = CAN_MB_RX_MODE;
    can1_mailbox.ul_id_msk =  0x7EC;      // our new mask instead of default (all 1's): CAN_MAM_MIDvA_Msk | CAN_MAM_MIDvB_Msk; 
    can1_mailbox.ul_id = CAN_MID_MIDvA(0x08C); //  CAN_MID_MIDvA(TEST7_CAN_TRANSFER_ID);
    can1_mailbox.ul_fid = 0x006;      //Family filter ID
    can_mailbox_init(CAN1, &can1_mailbox);

Now something magic happen:
After each transmit (I do this with standard message IDs selected by a rotary encoder function)
the family ID changes. So every message - independent of the message ID is received - no filtering at all.
Peeking directly in the register with example ID 0x82 which must definitely denied from the receiver, yields:

Test7 passed
MID = 0x82
CAN1, receive, Mailbox 0, all results in 32bit HEX:
Dat Hi: MDH 55667788 : should not be received
Dat Lo: MDL 00000182 : should not be received
FAM ID: MFID 00000082 : ???
AccMsk: MAM 000007EC : ok

Any idea of what's going on here?

Well, off hand I'm not really sure. It certainly should be dropping that frame 0x82 because it doesn't match. 82 AND 7EC does not equal 8C. So, my guess is that the mailbox is in standard ID mode and you didn't use the proper macro to place the standard mask into the register. Do you see how you did use the macro for the ID:
CAN_MID_MIDvA(0x08C);

Try this:
can1_mailbox.ul_id_msk = CAN_MAM_MIDvA(0x7EC);

I know its a pain but you have to use the macros if you use standard ids because they've got to be offset in the register. Extended IDs do now have this problem but you've got to set a bit to indicate extended frames.

Collin, you're the man!
The prob hold me, I then thought about it and came to the same conclusion. Now it works perfectly. Thanks, anyway.

But one thing I do not understand. The Filter mask register is read-only. On my CAN PICs I also can write. It seems the message filtering on 8-bit PICs and the 8-bit AVRs work very similar. Maybe they even have (both from an external manufacturer e.g. Intel?) the same CAN protocol engine. But SAM8 is quite different. So this Filter-ID thing confused my for a while.

Something else:
Is there a free white paper (ISO Norm 15031?) available for CAN registers used by the automotive industry? Or wher can I find coded messages, e.g. motor rpm, battery voltage and so on?

There are standards for OBDII messages that all vehicles must implement. Every manufacturer then feels free to implement anything else they want and not tell a soul without large payments and NDAs.

That will give you the codes for the most common internal combustion engine codes. If you need codes for electric cars then you will have even more trouble. It's even less standard.

BTW, I'm pretty sure even the standard OBDII codes are covered by a SAE document or something and usually you have to pay for it. But, enough people have implemented OBDII readers that you can usually google for the PID codes if for some reason the wiki article doesn't have what you want.

I'm in great awe of your knowledge and experience. Thank you.