2017/03/26 17:48:18
Fabián Inostroza
I made a board with this controller/transceiver thinking that it is just an mcp2515 and a mcp2551 glued with a logic converter.
After the boards arrived I was reading the datasheet for this chip where sec 2.6 says:
In Listen-Only mode, both valid and invalid messages will be received regardless of filters and masks or RXM<1:0> bits in the RXBxCTRL registers.
To me that means that filters are ignored in listen-only mode. I though WTF, if you don't want to use filters you just disable them.
Then I made some tests and concluded that filter settings are respected in listen-only mode.
Is this an error in documentation? Did I interpreted wrong the datasheet?, silicon bug not following datasheet?
2018/09/10 14:09:02
Initially, I found this description a little misleading as well. I believe what they are trying to describe is that in Listen-Only mode, it is possible to receive invalid messages even when filters are enabled. Unlike Normal mode, where filters would prevent invalid messages from being received.
2020/10/22 00:14:56
I am having the exact same Problem. From my test setup I found out the hard way, that invalid messages seem to be comming through on a unregular basis in listen only mode. In my set up there the MCP is (in certain wanted conditions) initialized to a fixed Baud rate (125k) and listen only mode, whilste the Baud rate on the connected CAN bus is a totally different one (100k). In theory the MCP2515 should just receive no (valid) messages because there cant be a valid message and also aliasing should be detected (due to incorrect CRC). But instead it "detects" all kinds of messages (std, ext, etc.) with different length and data because it seems to simply also disable CRC checking. That is a problem for me because it handles interrupt pin and flag registers (CANINTF=01) as if it was a valid message that is acutally not there. Also these "invalid" messages come in at a lower rate than acual messages on the bus (for every 7-16 real messages on the bus it detects one unreal messages with bullshit ID and data). I strongly suspect this is aliasing in sampling and interpretation without CRC cecking.
1. inconsistant statements in Data sheet DS20001801J-page 59:
10.3 Listen-Only Mode
Listen-Only mode provides a means for the MCP2515 to
receive all messages (including messages with errors)
by configuring the RXM[1:0] bits (RXBnCTRL[6:5]). This
mode can be used for bus monitor applications or for
detecting the baud rate in ‘hot plugging’ situations.
For Auto-Baud Detection (ABD), it is necessary that at
least two other nodes are communicating with each
other. The baud rate can be detected empirically by
testing different values until valid messages are
Listen-Only mode is a silent mode, meaning no
messages will be transmitted while in this mode
(including error flags or Acknowledge signals). In
Listen-Only mode, both valid and invalid messages will
be received, regardless of filters and masks or the
Receive Buffer Operating Mode bits, RXMn. The error
counters are reset and deactivated in this state. The
Listen-Only mode is activated by setting the Request
Operation Mode bits (REQOP[2:0]) in the CANCTRL
I feel like in listen only mode it not only doesnt do filters but also doesnt do CRC (also invalid msg) and therefore pics up the alias sampling (100k vs. 125k) as data. So data sheet is wrong in the first statement. 
How to solve the issue, I want listen only because I am not allowed to influence the CAN bus (by Errorframes or anything = Listen only) and if connected to the wrong Bus (different boud rate) do nothing.
Currently I do Baudrate detection that fails on the first invalid message for a baudrate, which works 95% of the time to thow out the wrong baudrate. But if real baudrate is not among the rates I check for it gets initialized with a default (or a wrongly detected 5%) and then this aliasing problem occours. My work around is to detect as many possible rates (95%) and then deliberately do nothing in endless loop. But in 5% the device will detect a baudrate I am looking for, even though it is not really there. That error case I can't catch.
2020/10/22 09:50:00
Based on the O.P. and my experience, in listen-only mode there is no error checking but it does respect the filters. So it is certainly possible to receive garbage as a message if the ID it generated happens to match on your filter while in listen-only mode.

For my system, I disable low-priority interrupts (rxb1) while in listen-only mode and have specific id's in the high-priority filters (rxb0) that can wake it up. Potentially you could reduce the number of garbage messages you have to look in this way. If you can perform your own validation on the message data, then you might be able to determine if you're at the right bus speed. BTW, I imagine SJW should be 1.
© 2021 APG vNext Commercial Version 4.5

Use My Existing Forum Account