user4215: I got 2 boards with an ATMEGA328 microcontroller and MCP2515 CAN Controller and I'm trying to get them communicate with each other. 
To shortcut the programming a little bit I'm using the Sparkfun CAN BUS Library, but I am not using ther CanbusClass(), I'm directly using the included mcp2515.c/h
The MCP2515 drives a MCP2551. CAN_H and CAN_L of both boards are connected with each other, the line has a 120Ohm termination resistor.


Both Microcontrollers share the same code:
#include <mcp2515.h>
#include <global.h>
#include <mcp2515_defs.h>
#include <defaults.h>
#define CANSPEED_125    7
const uint8_t PIN_LED_RED = 6;
const uint8_t PIN_LED_GREEN = 7;

void setup()
{   
  Serial.begin(9600);
  pinMode(PIN_LED_GREEN, OUTPUT);   
  pinMode(PIN_LED_RED, OUTPUT);
  unsigned long now=micros();
  unsigned long init = 0;
  if(mcp2515_init(CANSPEED_125)) {
    init=micros();
    Serial.println("CAN Init ok");  
    digitalWrite(PIN_LED_GREEN, HIGH);
    delay(500);
    digitalWrite(PIN_LED_GREEN, LOW);
  } else {
    init = micros();
    Serial.println("Can't init CAN");
    digitalWrite(PIN_LED_RED, HIGH);
    delay(1000);
    digitalWrite(PIN_LED_RED, LOW);
  }
  Serial.print("Time for init: ");
  Serial.println (init-now);
  delay(1000);
  mcp2515_bit_modify(CANCTRL, (1<<REQOP2)|(1<<REQOP1)|(1<<REQOP0), 0); 
  Serial.println("-------------------------");
  Serial.println("1. CAN - MSG1");
  Serial.println("-------------------------");
}

void loop()
{   
  tCAN CANmessage;
  unsigned long tnow;
  unsigned long tsend;
  if (Serial.available() > 0) {
    char incomingByte = Serial.read();
    switch (incomingByte) {
        case '1':
            Serial.println("1. CAN - MSG1");
            tsend=micros();
            CANmessage.id = 0x01;
            CANmessage.header.rtr = 0;
            CANmessage.header.length = 8;
            CANmessage.data[0] = B01010101;
            CANmessage.data[1] = B11001100;
            CANmessage.data[2] = B11100011;
            mcp2515_bit_modify(CANCTRL, (1<<REQOP2)|(1<<REQOP1)|(1<<REQOP0), 0);
            mcp2515_send_message(&CANmessage);
            tnow=micros();
            Serial.print("Message send in time: ");
            Serial.println(tnow-tsend);
            break;
    }
  }
  checkCANBus();
}

void checkCANBus() {
  if (mcp2515_check_message()) {
    tCAN CANmessage;
    PORTD ^= _BV(7);
    Serial.println("Has message");
    if (mcp2515_get_message(&CANmessage)) 
    {
        Serial.print("Message receivced: ");
        Serial.print(CANmessage.id);
        Serial.print(", ");
        Serial.print(CANmessage.data[0], BIN);
        Serial.print(", ");
        Serial.print(CANmessage.data[1], BIN);
        Serial.print(", ");
        Serial.print(CANmessage.data[2], BIN);
        Serial.print("end ");
        if (CANmessage.id==0x01) {
            Serial.println("MSG ID1 received");
            PORTD ^= _BV(6);
        }               
    }
  }
}

On Serial port of both boards I get on startup:

CAN Init ok
  Time for init: 250
  1. CAN - MSG1  

When I send a byte on the Serial port of one baord ('1') I get on the Serial: 

Message send in time: 212

On the receiver side I only get 

Has message 

and the green LED on PIN7 is turned on (means mcp2515_check_message() returns that the MCP2515 has set the receive interrupt signal). 
After that the program crashes in the routine mcp2515_get_message().
By toggling the LED's I figured out that the program crashes directly at the beginning of mcp2515_get_message() in the line mcp2515_read_status(SPI_RX_STATUS);
So the problem lies in mcp2515_read_status().
int8_t mcp2515_get_message(tCAN *message)
{
  // read status
  uint8_t status = mcp2515_read_status(SPI_RX_STATUS);
  ...
  ...
}

uint8_t mcp2515_read_status(uint8_t type)
{
    uint8_t data;
    RESET(MCP2515_CS);
    spi_putc(type);
    data = spi_putc(0xff);
    SET(MCP2515_CS);
    return data;
}

uint8_t spi_putc( uint8_t data )
{
  SPDR = data;
  while( !( SPSR & (1<<SPIF) ) )
    ;
  return SPDR;
}

By further toggling I figured that the last line correctly executed is spi_putc(type);
The line data = spi_putc(0xff); freezes the microcontoller! Which means the while loop in spi_putc() is endless running as the SPIF bit is not cleared.
Here is what I think I figured out so far:

The SPI bus connection is clearly working as the initialization is working!
As the mcp2515_check_message() returns on the receiver board that MCP2515_INT is set so I assume the CAN communication is working (otherwise, why would controller set the MCP2515_INT). 

SPI_RX_STATUS is defined as 0xB0(original as in library). 
The Datasheet of the MCP2515 controller states on page 66

The RX STATUS instruction (Figure 12-9) is used to
  quickly determine which filter matched the message
  and message type (standard, extended, remote). After
  the command byte is sent, the controller will return
  8 bits of data that contain the status data. If more clocks
  are sent after the eight bits are transmitted, the
  controller will continue to output the same status bits as
  long as the CS pin stays low and clocks are provided.

Which it clearly doesn't! But what I cant figure out is why :) 

user23841: There is one huge pitfall in Master Mode in this ATMega - Select Slave pin (/SS - active low). If it's configured as input, SPI is switched to Slave Mode by low level on this pin. And /SS is on pin PB2 (used as CAN_INT).
In the library defaults I can see: #define    MCP2515_INT D,2. PD2 is also INT0 external interrupt pin, so it does make sense to be here and it can be used with attachInterrupt. PB2 is used as an output for selecting slave device, so it's ok too.
Schematics corresponds with that defaults:

In OPs schematics there are slight changes. Interrupt request CAN_INT is located on /SS pin (PB2, arduino pin 10). CAN_CS was moved from PB2 to PB1 (arduino pin 10 -> pin 9)
And in Mega328 datasheet is section: 19.2 SS Pin Functionality:

19.3.2 Master Mode
  When the SPI is configured as a Master (MSTR in SPCR is set), the user can determine the direction of the /SS
  pin.
  If /SS is configured as an output, the pin is a general output pin which does not affect the SPI system. Typically,
  the pin will be driving the SS pin of the SPI Slave.
If /SS is configured as an input, it must be held high to ensure Master SPI operation. If the /SS pin is driven low by
  peripheral circuitry when the SPI is configured as a Master with the /SS pin defined as an input, the SPI system
  interprets this as another master selecting the SPI as a slave and starting to send data to it. To avoid bus
  contention, the SPI system takes the following actions:
  1. The MSTR bit in SPCR is cleared and the SPI system becomes a Slave. As a result of the SPI becoming a Slave, the MOSI and SCK pins become inputs.
  2. The SPIF Flag in SPSR is set, and if the SPI interrupt is enabled, and the I-bit in SREG is set, the interrupt
  routine will be executed.
  Thus, when interrupt-driven SPI transmission is used in Master mode, and there exists a possibility that SS is
  driven low, the interrupt should always check that the MSTR bit is still set. If the MSTR bit has been cleared by
  a slave select, it must be set by the user to re-enable SPI Master mode.

Conclusion: If you are using HW SPI in master mode, you can't just use pin 10 (PB2) as general input.

4215: <p>I got 2 boards with an <a href="http://www.atmel.com/images/Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet_Complete.pdf" rel="nofollow noreferrer">ATMEGA328</a> microcontroller and <a href="http://www.farnell.com/datasheets/1669372.pdf" rel="nofollow noreferrer">MCP2515</a> CAN Controller and I'm trying to get them communicate with each other. </p>

<p>To shortcut the programming a little bit I'm using the <a href="https://github.com/sparkfun/SparkFun_CAN-Bus_Arduino_Library" rel="nofollow noreferrer">Sparkfun CAN BUS Library</a>, but I am not using ther <a href="https://github.com/sparkfun/SparkFun_CAN-Bus_Arduino_Library/blob/master/src/Canbus.h" rel="nofollow noreferrer">CanbusClass()</a>, I'm directly using the included <a href="https://github.com/sparkfun/SparkFun_CAN-Bus_Arduino_Library/blob/master/src/mcp2515.c" rel="nofollow noreferrer">mcp2515.c/h</a></p>

<p>The MCP2515 drives a <a href="http://ww1.microchip.com/downloads/en/DeviceDoc/21667f.pdf" rel="nofollow noreferrer">MCP2551</a>. CAN_H and CAN_L of both boards are connected with each other, the line has a <a href="https://electronics.stackexchange.com/questions/55389/why-does-the-can-bus-use-a-120-ohm-resistor-as-the-terminating-resistor-and-not">120Ohm</a> termination resistor.</p>

<p><a href="https://i.stack.imgur.com/F4U8A.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/F4U8A.png" alt="enter image description here"></a>
<a href="https://i.stack.imgur.com/cVAIP.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/cVAIP.png" alt="enter image description here"></a>
Both Microcontrollers share the same code:</p>

<pre><code>#include &lt;mcp2515.h&gt;
#include &lt;global.h&gt;
#include &lt;mcp2515_defs.h&gt;
#include &lt;defaults.h&gt;
#define CANSPEED_125    7
const uint8_t PIN_LED_RED = 6;
const uint8_t PIN_LED_GREEN = 7;

void setup()
{   
  Serial.begin(9600);
  pinMode(PIN_LED_GREEN, OUTPUT);   
  pinMode(PIN_LED_RED, OUTPUT);
  unsigned long now=micros();
  unsigned long init = 0;
  if(mcp2515_init(CANSPEED_125)) {
    init=micros();
    Serial.println("CAN Init ok");  
    digitalWrite(PIN_LED_GREEN, HIGH);
    delay(500);
    digitalWrite(PIN_LED_GREEN, LOW);
  } else {
    init = micros();
    Serial.println("Can't init CAN");
    digitalWrite(PIN_LED_RED, HIGH);
    delay(1000);
    digitalWrite(PIN_LED_RED, LOW);
  }
  Serial.print("Time for init: ");
  Serial.println (init-now);
  delay(1000);
  mcp2515_bit_modify(CANCTRL, (1&lt;&lt;REQOP2)|(1&lt;&lt;REQOP1)|(1&lt;&lt;REQOP0), 0); 
  Serial.println("-------------------------");
  Serial.println("1. CAN - MSG1");
  Serial.println("-------------------------");
}

void loop()
{   
  tCAN CANmessage;
  unsigned long tnow;
  unsigned long tsend;
  if (Serial.available() &gt; 0) {
    char incomingByte = Serial.read();
    switch (incomingByte) {
        case '1':
            Serial.println("1. CAN - MSG1");
            tsend=micros();
            CANmessage.id = 0x01;
            CANmessage.header.rtr = 0;
            CANmessage.header.length = 8;
            CANmessage.data[0] = B01010101;
            CANmessage.data[1] = B11001100;
            CANmessage.data[2] = B11100011;
            mcp2515_bit_modify(CANCTRL, (1&lt;&lt;REQOP2)|(1&lt;&lt;REQOP1)|(1&lt;&lt;REQOP0), 0);
            mcp2515_send_message(&amp;CANmessage);
            tnow=micros();
            Serial.print("Message send in time: ");
            Serial.println(tnow-tsend);
            break;
    }
  }
  checkCANBus();
}

void checkCANBus() {
  if (mcp2515_check_message()) {
    tCAN CANmessage;
    PORTD ^= _BV(7);
    Serial.println("Has message");
    if (mcp2515_get_message(&amp;CANmessage)) 
    {
        Serial.print("Message receivced: ");
        Serial.print(CANmessage.id);
        Serial.print(", ");
        Serial.print(CANmessage.data[0], BIN);
        Serial.print(", ");
        Serial.print(CANmessage.data[1], BIN);
        Serial.print(", ");
        Serial.print(CANmessage.data[2], BIN);
        Serial.print("end ");
        if (CANmessage.id==0x01) {
            Serial.println("MSG ID1 received");
            PORTD ^= _BV(6);
        }               
    }
  }
}
</code></pre>

<p>On Serial port of both boards I get on startup:</p>

<blockquote>
  <p>CAN Init ok<br>
  Time for init: 250<br>
  1. CAN - MSG1  </p>
</blockquote>

<p>When I send a byte on the Serial port of one baord ('1') I get on the Serial: </p>

<blockquote>
  <p>Message send in time: 212</p>
</blockquote>

<p>On the receiver side I only get </p>

<blockquote>
  <p>Has message </p>
</blockquote>

<p>and the green LED on PIN7 is turned on (means mcp2515_check_message() returns that the MCP2515 has set the receive interrupt signal). </p>

<p>After that the program crashes in the routine mcp2515_get_message().</p>

<p>By toggling the LED's I figured out that the program crashes directly at the beginning of mcp2515_get_message() in the line mcp2515_read_status(SPI_RX_STATUS);
So the problem lies in mcp2515_read_status().</p>

<pre><code>int8_t mcp2515_get_message(tCAN *message)
{
  // read status
  uint8_t status = mcp2515_read_status(SPI_RX_STATUS);
  ...
  ...
}

uint8_t mcp2515_read_status(uint8_t type)
{
    uint8_t data;
    RESET(MCP2515_CS);
    spi_putc(type);
    data = spi_putc(0xff);
    SET(MCP2515_CS);
    return data;
}

uint8_t spi_putc( uint8_t data )
{
  SPDR = data;
  while( !( SPSR &amp; (1&lt;&lt;SPIF) ) )
    ;
  return SPDR;
}
</code></pre>

<p>By further toggling I figured that the last line correctly executed is spi_putc(type);</p>

<p>The line data = spi_putc(0xff); freezes the microcontoller! Which means the while loop in spi_putc() is endless running as the SPIF bit is not cleared.</p>

<p>Here is what I think I figured out so far:</p>

<ul>
<li>The SPI bus connection is clearly working as the initialization is working!</li>
<li>As the mcp2515_check_message() returns on the receiver board that MCP2515_INT is set so I assume the CAN communication is working (otherwise, why would controller set the MCP2515_INT). </li>
</ul>

<p>SPI_RX_STATUS is defined as 0xB0(original as in library). 
The <a href="http://www.farnell.com/datasheets/1669372.pdf" rel="nofollow noreferrer">Datasheet</a> of the MCP2515 controller states on page 66</p>

<blockquote>
  <p>The RX STATUS instruction (Figure 12-9) is used to
  quickly determine which filter matched the message
  and message type (standard, extended, remote). After
  the command byte is sent, the controller will return
  8 bits of data that contain the status data. If more clocks
  are sent after the eight bits are transmitted, the
  controller will continue to output the same status bits as
  long as the CS pin stays low and clocks are provided.</p>
</blockquote>

<p>Which it clearly doesn't! But what I cant figure out is why :) </p>
 23841: <p>There is one huge pitfall in Master Mode in this ATMega - Select Slave pin (/SS - active low). If it's configured as input, SPI is switched to Slave Mode by low level on this pin. And /SS is on pin PB2 (used as CAN_INT).</p>

<p>In the <a href="https://github.com/sparkfun/SparkFun_CAN-Bus_Arduino_Library/blob/master/src/defaults.h" rel="nofollow noreferrer">library defaults</a> I can see: <code>#define    MCP2515_INT D,2</code>. PD2 is also INT0 external interrupt pin, so it does make sense to be here and it can be used with attachInterrupt. PB2 is used as an output for selecting slave device, so it's ok too.<br>
<a href="http://cdn.sparkfun.com/datasheets/Dev/Arduino/Shields/SparkFun_CAN-Bus_Shield_v13a.pdf" rel="nofollow noreferrer">Schematics</a> corresponds with that defaults:
<a href="https://i.stack.imgur.com/v6Zoo.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/v6Zoo.png" alt="shield interface"></a></p>

<p>In OPs schematics there are slight changes. Interrupt request CAN_INT is located on /SS pin (PB2, arduino pin 10). CAN_CS was moved from PB2 to PB1 (arduino pin 10 -> pin 9)</p>

<p>And in <a href="http://www.atmel.com/images/Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet_Complete.pdf" rel="nofollow noreferrer">Mega328</a> datasheet is section: 19.2 SS Pin Functionality:</p>

<blockquote>
  <p><strong>19.3.2 Master Mode</strong><br><br>
  When the SPI is configured as a Master (MSTR in SPCR is set), the user can determine the direction of the /SS
  pin.<br><br>
  If /SS is configured as an output, the pin is a general output pin which does not affect the SPI system. Typically,
  the pin will be driving the SS pin of the SPI Slave.<br><br>
  <strong>If /SS is configured as an input, it must be held high to ensure Master SPI operation. If the /SS pin is driven low by
  peripheral circuitry when the SPI is configured as a Master with the /SS pin defined as an input, the SPI system
  interprets this as another master selecting the SPI as a slave and starting to send data to it.</strong><br> To avoid bus
  contention, the SPI system takes the following actions:<br>
  1. The MSTR bit in SPCR is cleared and the SPI system becomes a Slave. As a result of the SPI becoming a Slave, the MOSI and SCK pins become inputs.<br>
  2. The SPIF Flag in SPSR is set, and if the SPI interrupt is enabled, and the I-bit in SREG is set, the interrupt
  routine will be executed.<br>
  Thus, when interrupt-driven SPI transmission is used in Master mode, and there exists a possibility that SS is
  driven low, the interrupt should always check that the MSTR bit is still set. If the MSTR bit has been cleared by
  a slave select, it must be set by the user to re-enable SPI Master mode.</p>
</blockquote>

<p><strong>Conclusion</strong>: If you are using HW SPI in master mode, you can't just use pin 10 (PB2) as general input.</p>
