Corrupt bus messages

In my working career I was in charge of several different groups of software
developers (large banking data networks).  One thing I told them was that,
when debugging a difficult problem, after they had spent a reasonable time
diagnosing it themselves, they should ask someone to sit next to them while
they verbally described the problem and go through the relevant section of
code describing what it  was supposed to do and how it accomplished it.  In
my experience, while doing this, the developer would stop in mid-sentence
and say "thanks, I've got it", and the bug would be corrected.  In most
cases the 'observer' never had to say anything.  Just the process of
verbalizing what the code was 'supposed' to do and reading what it was
'actually' doing forced the developer to see the difference.

 

Why do I mention this?

 

I have been having a vexing problem with my large outdoor railroad CAN bus
where the symptoms indicated that the MAC2515 CAN bus controller was passing
corrupt messages to the firmware - or - the firmware itself was sending
corrupt messages - or - the firmware was corrupting the messages after
receipt.

 

I knew that CRC and other error recovery done by the MCP2515 hardware should
prevent passing corrupt bus messages to the firmware so I spent a lot of
time checking and re-checking the firmware to no avail.

 

So . I started a (long) email to this group in which I: a) defined the
environment, b) gave a list of the ways I thought a message could be
corrupted, and c) addressed each item in the list describing how the
firmware addressed that situation.

 

(Background: in my network I receive ALL CAN messages, i.e.: filters are not
used)

 

In addressing an item in the list having to do with message reception by the
MCP2515 I was re-reading the datasheet for the 100th time and I read:

 

(receive buffer control)

 

bit 6-5 RXM: Receive Buffer Operating Mode bits

11 = Turn mask/filters off; receive any message

10 = Receive only valid messages with extended identifiers that meet filter
criteria

01 = Receive only valid messages with standard identifiers that meet filter
criteria

00 = Receive all valid messages using either standard or extended
identifiers that meet filter criteria

 

Now, recall that I want to receive ALL messages (i.e.: not use the filters),
so, I selected a setting of "11".

 

Elsewhere in the datasheet: 

 

"RXM BITS: The RXBnCTRL.RXM bits set special receive modes.  Normally, these
bits are cleared to 00 to enable

reception of all valid messages as determined by the appropriate acceptance
filters. ..  If the RXBnCTRL.RXM bits are set to 11, the buffer will receive
all messages, regardless of the values of the acceptance filters. "

 

(me: . ok, so "11" will disable the use of the filters, thus I do not have
to bother initializing them, good, that's what I want .)

 

BUT, further down:

 

"Also, if a message has an error before the EOF, that portion of the message
assembled in the MAB before the error frame will be loaded into the
(receive) buffer. .."

 

OOPS, What? . upon rereading the initial RXM bit description:

 

"RXM BITS: The RXBnCTRL.RXM bits set special receive modes.  Normally, these
bits are cleared to 00 to enable

reception of all valid messages as determined by the appropriate acceptance
filters. ..  If the RXBnCTRL.RXM bits are set to 11, the buffer will receive
all messages, regardless of the values of the acceptance filters. "

 

OOPS: "00" -> "all valid" messages, "11" -> "all <even invalid>" messages
!!!

 

It goes on to say "This mode (11) has some value in debugging a CAN system
and would not be used in an actual system

environment." . which should have been another clue to me that I should not
have selected "11".

 

So, I want to thank the group for listening (even though I discarded the
long message I had initially prepared J) and use this as a lesson for me and
others to re-re-re-re-read the datasheet and read what it is ACTUALLY
saying, not what we think it is saying J