How Do You Add CAN Bus Support with the MCP2515 SPI CAN Controller?

Detailed Explanation

Many MCUs, including most Arduino boards, a large share of general-purpose Cortex-M parts, and any MCU whose on-chip CAN peripheral pins are already committed to another function, have no built-in CAN controller at all. The MCP2515 solves this by implementing the entire CAN controller function, message framing, bit-stuffing, arbitration, and the error-active/error-passive/bus-off state machine described in what is CAN bus?, inside a standalone IC that the host MCU talks to over SPI instead of a dedicated CAN peripheral bus.

From the host MCU's perspective, the MCP2515 looks like any other SPI peripheral: the MCU writes outgoing CAN frames into one of the MCP2515's three transmit buffers over SPI, and reads incoming frames out of one of its two receive buffers the same way. The MCP2515 itself handles everything CAN-specific, including retransmission on arbitration loss and the error-counter state machine, without further MCU involvement until a frame is ready to send or has arrived.

Hardware Interface and Wiring

A typical MCP2515 circuit has three distinct pieces: the SPI connection to the host MCU, an external crystal (commonly 8 MHz or 16 MHz depending on the specific breakout board), and a separate CAN transceiver feeding the physical CAN_H/CAN_L bus pair. Most off-the-shelf MCP2515 breakout boards bundle a TJA1050 transceiver on the same small PCB, so in practice the board exposes SPI pins (SCK, MOSI, MISO, CS), an interrupt output (INT), and the two-wire CAN_H/CAN_L bus connection, hiding the crystal and transceiver wiring from the user.

The bit timing registers (CNF1/CNF2/CNF3) must be configured against the crystal frequency actually populated on the specific board, not assumed from a datasheet example. Two boards that look identical can ship with different crystal frequencies from different manufacturing runs, and a bit-timing configuration calculated for the wrong crystal frequency produces a bus that appears to initialise correctly but fails to communicate reliably, or at all, once a second node is present.

The INT pin should be wired to an MCU interrupt-capable input and used to drive message handling, rather than polling the MCP2515's status registers on a fixed timer. Because SPI transactions take longer than typical CAN bit times at higher bus speeds, polling too infrequently risks a receive buffer overflow if two messages for the device arrive close together, silently dropping the second message.

MCP2515 vs a Built-In CAN Peripheral vs MCP2518FD

Reaching for an external SPI CAN controller only makes sense when the host MCU cannot provide native CAN itself; an MCU with a built-in CAN or FDCAN peripheral, such as those covered in how to configure the STM32 FDCAN peripheral, doesn't need the added SPI transaction overhead, board area, or crystal that an external controller requires.

Message Filtering and Buffers

The MCP2515 implements two acceptance mask registers and six acceptance filter registers in hardware, applied to its two receive buffers. Configuring these correctly means the controller only interrupts the host MCU for CAN IDs the application actually cares about, offloading ID filtering from software entirely, which matters on the smaller MCUs the MCP2515 is typically paired with. Leaving the filters in their default pass-everything state works for early bring-up and low-traffic buses, but on a busy bus it wastes SPI bandwidth and MCU cycles servicing interrupts for messages the application discards immediately after reading.

Design Considerations

• Confirm the crystal frequency on the specific board revision before calculating bit timing. Different MCP2515 breakout board vendors, and different revisions from the same vendor, are not guaranteed to use the same crystal.
• Use the INT pin and interrupt-driven handling rather than polling, particularly at higher bus loads, to avoid missing or overflowing the two-message receive buffer capacity.
• Configure acceptance filters for the application's actual ID set once bring-up is complete, rather than leaving the default pass-all configuration in a production design.
• Budget SPI bus time realistically. Every CAN frame the MCP2515 sends or receives requires an SPI transaction to move it to or from the host MCU; on a busy bus, this can become the actual throughput bottleneck rather than the CAN bus itself, especially if the SPI clock is set conservatively low.
• Decide early whether classic CAN is sufficient, since the MCP2515's CAN 2.0B-only limitation cannot be worked around in firmware; a design that might need CAN FD in the future should evaluate the MCP2518FD instead of planning to upgrade the same board later.
• Zeus Design's firmware team integrates external communication controllers like the MCP2515 into products built around MCUs that lack native CAN, including driver development and bus-loading analysis. Learn more about our software development services.

Common Mistakes

• Assuming a specific crystal frequency without checking the actual board, producing bit timing that silently fails or works unreliably.
• Polling the MCP2515 on a fixed timer instead of using its INT pin, risking dropped messages under load.
• Leaving acceptance filters in the default pass-all state in a production design on a busy bus, wasting SPI and MCU capacity.
• Assuming the MCP2515 supports CAN FD because a project description says "CAN" without specifying the variant, then discovering the limitation late in development.
• Forgetting that a physical CAN bus still needs correct 120Ω termination at both physical ends regardless of which controller IC is used; this is a bus wiring requirement, not something the MCP2515 or its transceiver compensates for.