DIY CAN MCP2515/2551 Setup w/Nano - MCP2515 keeps sleeping

Projects Networking, Protocols, and Devices
1

Revisiting a project of mine after a while, since I have finally found the time to return to this circuit.
I'm using the same circuit recommended by this library: GitHub - autowp/arduino-mcp2515: Arduino MCP2515 CAN interface library.

I'm using the "CAN_write" sketch in that library with no modification. I don't have another device listening to it yet, I just want to see something, anything at all coming out of the MCP2551 (e.g. onto the CAN bus). Right now the issue actually seems to be further upstream in the MCP2515 though, since it's never sending anything to the 2551.

Here's the "DIY" circuit image included in that library. It's very similar to the Seeed Studio CAN bus shield diagram, and in either case it's exactly the setup I have:

969×535 14.7 KB

I mean, I can all but assure you that circuit and mine are identical. I've checked it over probably twenty times, no exaggeration. The ground/5v rails are commonized as they should be, I beep tested it all, the works. Even so... be it with this library or the Seeed Shield library, the MCP2515 keeps going to sleep right after startup! Or at least it seems like that's the case - it properly blasts the 16MHz clock on its CLKOUT pin for a very brief window right after powering on, then falls silent.

So, I'm wondering why this keeps going to sleep. I see data constantly streaming into the thing from my library code on pins 13,14,15,16 (though I can't exactly parse the meaning). Is there any other pin or setting I need to be observing to get this darn thing to talk with the MCP2551?

Thanks,

2

Put the MCP2515 into internal loopback mode and check to see if returns the packets that you send.

3

EmptySet:
I mean, I can all but assure you that circuit and mine are identical. I've checked it over probably twenty times, no exaggeration. The ground/5v rails are commonized as they should be, I beep tested it all, the works. Even so... be it with this library or the Seeed Shield library, the MCP2515 keeps going to sleep right after startup! Or at least it seems like that's the case - it properly blasts the 16MHz clock on its CLKOUT pin for a very brief window right after powering on, then falls silent.

either your schematic is wrong or your used parts different to your schematic. Therefore:

  • it is essential that you provide HIGH QUALITY pictures from your building where we can identify each wiring and part on the pcb/breadboard
  • a clickable link to the CAN library you are using (you only mentioned that you were using the schematic from a library)
  • provide the EXACT sketch in code-tags you are using
4

Does the MCP2515 package have 18 or 20 pins?

5

mikb55:
Does the MCP2515 package have 18 or 20 pins?

18, same as the image.

noiasca:
either your schematic is wrong or your used parts different to your schematic. Therefore:

  • it is essential that you provide HIGH QUALITY pictures from your building where we can identify each wiring and part on the pcb/breadboard
  • a clickable link to the CAN library you are using (you only mentioned that you were using the schematic from a library)
  • provide the EXACT sketch in code-tags you are using

The library link is also in the OP, please check.
The exact sketch is called out in the OP, and I also mentioned it is unmodified.

I'll see about taking some images of the physical breadboard. EDIT: I may also make a second circuit on proto-board as well and test, in case the noise I've been seeing on breadboard causes issues for the 2515. So once that's done I'll share...

6

So, I did end up putting the whole circuit on proto-board. And it ended up "working" the same way - the MCP2515 goes to sleep almost right away, again!

I'll attach an image of my breadboard layout, because I used a much-too-small proto board and it ended up being a routing mess. The breadboard layout isn't great either, but it's easier to follow for sure. You'll have to give me some slack, the circuit's been re-assembled several times throughout troubleshooting... :confused:

2016×1512 427 KB

I added the "dots" near pin 1 on the ICs in case orientation wasn't clear. The clock is an AC0 16MHz, link and datasheet: here.

So besides the somewhat sloppy wiring, does anything look off? To re-state the problem, basically there looks to be some data at pins 13,14,15,16 of the MCP2515 (four yellow wires) but it never, ever transmits anything on pin 1 or 2 (white and green wires going to the 2551).

7

So, I've made some headway while simultaneously creating more mysteries! :slight_smile:

I started to suspect that maybe the sample code wasn't pulling its own weight, and I also wanted to test loopback like mikb55 mentioned. Therefore I created an amalgam of the read and write example sketches to get something that turns on loopback, talks every 100ms, listens to itself and puts the feedback onto serial.

#include <SPI.h>
#include <mcp2515.h>
 
struct can_frame canMsg;
MCP2515 mcp2515(10);
unsigned long lastFrame = 0;

struct can_frame canMsgRx;
struct can_frame canMsgTx;
 
void setup() {
  Serial.begin(115200);
  SPI.begin();

  canMsgTx.can_id  = 0x0F6;
  canMsgTx.can_dlc = 8;
  canMsgTx.data[0] = 0x8E;
  canMsgTx.data[1] = 0x87;
  canMsgTx.data[2] = 0x32;
  canMsgTx.data[3] = 0xFA;
  canMsgTx.data[4] = 0x26;
  canMsgTx.data[5] = 0x8E;
  canMsgTx.data[6] = 0xBE;
  canMsgTx.data[7] = 0x86;
 
  mcp2515.reset();
  mcp2515.setBitrate(CAN_125KBPS);
  mcp2515.setLoopbackMode();
 
  Serial.println("Loopback");
}
 
void loop() {

  // Write something every 100ms
  if ( ( millis() - lastFrame ) >= 100 ) {
    mcp2515.sendMessage(&canMsgTx);
    lastFrame = millis();
  }
  
  // Check if there's anything to read
  if (mcp2515.readMessage(&canMsgRx) == MCP2515::ERROR_OK) {
      
    Serial.print(canMsgRx.can_id, HEX); // print ID
    Serial.print(" "); 
    Serial.print(canMsgRx.can_dlc, HEX); // print DLC
    Serial.print(" ");
    
    for (int i = 0; i<canMsgRx.can_dlc; i++)  {  // print the data
        
      Serial.print(canMsgRx.data[i],HEX);
      Serial.print(" ");

    }

    Serial.println();      
  }
 
}

And that worked! I saw back exactly the messages I expected on Serial Monitor, e.g.

Loopback
F6 8 8E 87 32 FA 26 8E BE 86 
F6 8 8E 87 32 FA 26 8E BE 86 
F6 8 8E 87 32 FA 26 8E BE 86 
...

So that's nice, but even with this working the CLKOUT pin (pin 3 of the 2515) doesn't seem to be always present. I see a single pulse on that pin very sporadically. No specific frequency there, but often repeating within 1s. This was all observed with the loopback actively working, so maybe it's just a configuration problem and I should stop looking to CLKOUT as definitive proof that the device is asleep or not.

Anyway, I took this sketch and made no changes other than altering the line

mcp2515.setLoopbackMode();

to

mcp2515.setNormalMode();

because that's what I want to do in the end, after all.

And with this sketch things look a little better! I see what looks like CAN data coming out of pin 1 of the 2515 (TXCAN - makes sense). CLKOUT is still not doing anything sane though, but the device is clearly working.

Anyway, that all goes into the 2551 and... nothing comes out of CANH/CANL still.

So now my beef is with the 2551. What does that IC need to play nice?

8

Is the supply voltage always above 4v? Check with a multimeter and then an oscilloscope.
The MCP2551 has a brownout protection circuit that disables the output if it detects the supply going below the 'VPORL' threshold.

9

mikb55:
Is the supply voltage always above 4v? Check with a multimeter and then an oscilloscope.
The MCP2551 has a brownout protection circuit that disables the output if it detects the supply going below the 'VPORL' threshold.

It is noisy, but I scoped it out and used a measure tool to find the min of the MCP2551's Vdd waveform over a 50s exposure window and it resulted in 4.12V.

I noticed in the datasheet that it also has a "VPORH" value set at 4.3V that it needs to clear to activate the CAN outputs in the first place. So if I'm reading this right, it's supposed to be some hysteresis between the enable range and the disable range (4.0-4.3V)?

Anyway the noise on the signal goes both ways and I saw a max voltage of around 5.25V, so clearing this threshold shouldn't be a problem.

But is the low end close enough to be a problem?

10

I would expect the loopback mode to draw less current and therefore be kinder to the power supply rail. In normal mode the termination resistor is going to increase the current demand and therefore cause the rail to sag.

Also in a single MCP2515 situation there are no ACKs from other nodes to signify a successful transmission so the MCP2515/2551 will make multiple attempts to send each packet which will again load the power rail. Perhaps add some decoupling caps close to both chips.

11

I hooked up the circuit to an external power supply instead of powering through the Arduino, and even tried playing with the supply's setting to see if this loading could be an issue (values slightly over 5V, like 5.25). The result was nothing out of the ordinary though, and the same issues seemed to persist.

Are there any issues beyond the power to the 2551 that I should look into? Maybe I should share the exact data waveform I'm feeding to it in case it's too noisy or doesn't have the right data content? Right now I do see some noise from other circuits like the clock riding on top of that input, but I wouldn't suspect that to be singularly disqualifying unless this IC is known for being especially picky.

12

Test the MCP2551 in isolation. Disconnect it from the MCP2515. Put a 20KHz signal into the MCP2551 Tx pin.

13

mikb55:
Test the MCP2551 in isolation. Disconnect it from the MCP2515. Put a 20KHz signal into the MCP2551 Tx pin.

I did just that and noticed something very odd... the MCP2551 alone was pulling 140mA and not doing much of anything. I noticed that after a while, it was also getting hot. So yeah, at some point in time I must've busted it without noticing.

I replaced the 2551 and the test circuit seemed to work fine, then I moved it back to the main circuit and it also worked fine!

Thanks for the help. Next time I'll remember to troubleshoot my ICs in isolation...