MessageSender/DataDisplay2 does not work as intended

[CapitanoPedro]

I just started playing with the NMEA 2000 libraries. Great work especially from Timo ... thanks!
At first I connected two Arduino Megas (with MCP2515) as desicribed. I.e. One is running MessageSender and the other is running DataDisplay2. Did not get any packet on the receiver side.
After that, I connected an NMEA-Multiplexer (ShipModule) => all is fine, I could see the packets. With that, the transmitter (MessageSender) seems to work.
With some debugging in DataDisplay2 I discovered, that with setting "DEBUG_RXANY (1)" in MCP_CAN.cpp all is fine.
In the default way MCP is programmed to use filtering but no filters are set. And consequently, no message appears in the buffers.
There is a good chance, that I have not got all details (I am new with that technology), but simply putting together MessageSender//DataDisplay2 does not work instantly.
Any idea?

[ttlappalainen]

I run my Mega board with mcp_can ( under my repository) default settings so DEBUG_RXANY undefined and it works fine. First thing comes again in to my mind that do you have terminal resistors connected? You need at least one 120 ohm resistor on small test system (short wires), but you can have two as in real CAN bus implementation.

[CapitanoPedro]

Hi Timo,
of course I installed 2x120 resistors and the line is very short (20cm).
As written, it works fine as long as the filters are disabled. The (relevant) registers are ...
default compilation #define DEBUG_RXANY (1)
Register 0x60 = 0x06 0x60 = 0x66
Register 0x70 = 0x00 0x70 = 0x60
As far as I understand the datasheet it meens that RXF0 is activated, but it seems that nobody makes a write to the filter banks (MCP_CAN::init_Filt).

I added following lines to mcp_can.cpp:

byte MCP_CAN::init_Filt(byte num, byte ext, unsigned long ulData)
{
byte res = MCP2515_OK;
//pw
Serial.print("*** Somebody writes to filters *****\r\n");
while(1);
.......
This printout does not occur. I.e. ... the routine is not invoked.

FYI ... I also checked polling mode and interrupt mode for the RX. No difference.
I am somewhat shure, that there not a HW-problem, but something is strange with the SW.

[ttlappalainen]

The filters are not in use. You need them, if you want to catch just specific frames. Here we catch all. And please do not be so sure. This code has been used by several users and I also have Mega on my test bed and I have never had any problems. Did you really download mcp_can from my repository and deleted all others - if installed. Compiler should warn you, if you have multiple of same libraries installed.

Have you checked that your interrupt pin is same as set on my samples? If not, you have to set that with #define N2k_CAN_INT_PIN xx.

MessageSender seem to be as default non interrupt mode = no definition for N2k_CAN_INT_PIN

[CapitanoPedro]

Hi Timo, problem is solved.
I figured out that even though the two filter masks (RXM0, RXM1) are 0x00000000 no message came through.
Have measured everything (SPI, CAN, VCC etc) ... all is within spec.

With lots of internet research I discovered, that such problems exist also with other users and the final help came from following thread ...
http://www.microchip.com/forums/m703449.aspx
It seems, there is a mysterious misbehaviour in MCP2015 if the EXIDE bits in the filters are cleared.
Dont't ask me why ... I am only a human.

I solved all this with adding following code to MCP_CAN::mcp2515_init ...
.....
if ( res == MCP2515_OK ) {
//
// Peter Wieninger, Feb 5th 2018, start of insertion
//
// There is a problem with some MCP2515 where even with all mask bits cleared
// no message will be accepted by the chip.
// The original code in the lib worked only if the filtering was totally disabled with
// (DEBUG_RXANY==1) and it did not work in the standard mode.
// Such problems are described in http://www.microchip.com/forums/m703449.aspx
// and here, the magic setting of EXIDE was found as a solution.
// Yes ... this works :-)
//
byte buff[4] = {0,0,0,0};
mcp2515_setRegisterS(MCP_RXM0SIDH, buff, 4); // ... to be safe, clear mask #0
mcp2515_setRegisterS(MCP_RXM1SIDH, buff, 4); // ... to be safe, clear mask #1
buff[1] = 0x08; // set EXIDE bit in RXFn (other bits are 0)
mcp2515_setRegisterS(MCP_RXF0SIDH, buff, 4); // make defined state for RXF0
mcp2515_setRegisterS(MCP_RXF1SIDH, buff, 4); // make defined state for RXF1
mcp2515_setRegisterS(MCP_RXF2SIDH, buff, 4); // make defined state for RXF2
mcp2515_setRegisterS(MCP_RXF3SIDH, buff, 4); // make defined state for RXF3
mcp2515_setRegisterS(MCP_RXF4SIDH, buff, 4); // make defined state for RXF4
mcp2515_setRegisterS(MCP_RXF5SIDH, buff, 4); // make defined state for RXF5
//
// Peter Wieninger, Feb 5th 2018, end of insertion
//

After that, everything is fine and messages are received and parsed.

Interestingly this fix even helps (for a while !!!) if the code is removed later.
It seems, that the MCP holds the stored values for a while even if VCC is removed.

Hope my findings are helpful for others.

[ttlappalainen]

So does that mean that I have been just lucky on not having any problems with mcp_can?

Does the fix effect enything for the use mcp_can with or without extended? If not, you could make PR for mcp_can.

[CapitanoPedro]

The error is odd, because it depends on the (uninitialized) content of the six filter registers.
Some people are happy, and others get mad (see also the thread in my comment, above).

You may do following checks ..
a) print the contents of the mask registers directly after mcp2515_init. You might observe, that these registers report a random are random content.
b) fill the 6 registers with 0x00000000L. I think at this point you might see, that the lib does not work anymore. None of the EXIDE bits is set, and with that the filtering will block the messages.
c) Now, load the filters with 0x00080000L and you might see, everthing is working well.

For whatever reason, the filters are not part of the chip internal RESET sequence, and some customers might have problems and others not.

I am convinced (ok ok ok ... NOT shure :-), that mcp_can should have an improvement similar to my solution. I also think that filling registers after reset with defined values is a good way. Note, that the datasheet of MCP2515 does NOT denote a reset state for these registers (only for the control registers).
Also, filling the registers with my solution is at least better, than leaving uninitialized. Best would be, if the developers of mcp_can have a closer look to this.

Could you pls. give me the correct link to the mcp_can guys. For me it is not clear where this lib originates, just took it from you repository. I would get in touch with them foir further discussion.

Thanks and greetings

[ttlappalainen]

If I read everything right, Seed_studio (https://github.com/Seeed-Studio/CAN_BUS_Shield) same version as I have, except someone has enabled debug definition. So you could try if they answers.

By the way you should see the link where is has been originally forket under repository name.

[nyinyinyanlin]

Thank you so much CapitanoPedro!!!

I had the same issue. Arduino Mega2560 <-> MCP2515 TJA1050 <-> Garmin Intelliducer N2K Depth Sounder

My oscilloscope showed me that the transducer has been transmitting two message frames at regular intervals and the differential signal is clean. I have also checked TJA1050 CAN Transceiver RX and the differential signal is properly being converted to logic level signal.

I couldn't figure out what was happening with the CAN Controller as everything ahead of it is running properly in receiving side. And I tried sender example and the device is transmitting properly on the CAN Bus.

I have found your issue and gave it a try, and I'm now receiving depth data from my Intelliducer properly.

And Timo, thank you so much for your amazing work. I wouldn't have the capability to integrate NMEA2000 devices in my project without your hard work.

Thanks and greetings to all.